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

Change should to must; leave design-choices open

Browse source
This commit is contained in:
Alexander Lill 2023-03-31 15:04:16 +02:00 committed by GitHub
parent 283ae80ba4
commit c3c8359c8e
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 4 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
chapters/requirements.bd
View file

@ -16,11 +16,11 @@ 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. It's requirements might be something like the following:
* Users should be able to add to-do list items with a single click.
* 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 should be able to edit the text of to-do list items.
* Users should be able to toggle the completed state of to-do list items.
* Users should be able to delete to-do list items.
* 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: