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

Improve readability of requirements

Browse source
This commit is contained in:
Alexander Lill 2023-02-23 11:57:12 +01:00 committed by GitHub
parent ff99de766b
commit 283ae80ba4
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

14
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. It's requirements might be something like the following: 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 must be able to add to do list items with a single action. * Users should be able to add to-do list items with a single click.
* To do list items must consist of text and a binary completed state. * To-do list items must contain text and a binary completed state.
* Users must be able to edit to do list item text. * Users should be able to edit the text of to-do list items.
* Users must be able to toggle the completed state. * Users should be able to toggle the completed state of to-do list items.
* Users must be able to delete to do list items. * Users should be able to delete to-do list items.
* All edits to do list item state must save without user intervention. * 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: Let's review these requirements against the criteria for good requirements that I listed above:
@ -38,4 +38,4 @@ Lastly, remember that requirements are translated from a design, and designs hav
No loan application with an applicant self-identified as a person of color should be approved. No loan application with an applicant self-identified as a person of color should be approved.
" "
That requirement is both precise and verifiable. In the 1980's, it was legal. But was it ethical or just? Absolutely not. Therefore, requirements, no matter how formally extracted from a design specification, no matter how consistent with law, and no matter how aligned with an organization's priorities, is free from racist ideas. Requirements are just one of many ways that such ideas are manifested, and ultimately hidden in code<benjamin19>. That requirement is both precise and verifiable. In the 1980's, it was legal. But was it ethical or just? Absolutely not. Therefore, requirements, no matter how formally extracted from a design specification, no matter how consistent with law, and no matter how aligned with an organization's priorities, is free from racist ideas. Requirements are just one of many ways that such ideas are manifested, and ultimately hidden in code<benjamin19>.