Miroirs/cooperative-software-development
1
0
Fork 0
mirror of https://github.com/amyjko/cooperative-software-development synced 2024-12-25 21:58:15 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

Merge pull request #154 from AlexanderLill/patch-1

Browse source 
Improve readability of requirements
This commit is contained in:
Amy J. Ko 2023-09-26 11:44:25 -07:00 committed by GitHub
commit 76d1a6884b
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 7 additions and 7 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
chapters/requirements.bd
View file

@ -16,12 +16,12 @@ There are some approaches to specifying requirements _formally_. These technique
Expressing requirements in natural language can mitigate these effects, at the expense of precision. They just have to be *complete*, *precise*, *non-conflicting*, and *verifiable*. For example, consider a design for a simple to do list application. Its requirements might be something like the following:
* Users must be able to add to do list items with a single action.
* To do list items must consist of text and a binary completed state.
* Users must be able to edit to do list item text.
* Users must be able to toggle the completed state.
* Users must be able to delete to do list items.
* All edits to do list item state must save without user intervention.
* Users must be able to add to-do list items with a single action.
* To-do list items must contain text and a binary completed state.
* Users must be able to edit the text of to-do list items.
* Users must be able to toggle the completed state of to-do list items.
* Users must be able to delete to-do list items.
* All changes made to the state of to-do list items must be saved automatically without user intervention.
Let's review these requirements against the criteria for good requirements that I listed above: