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

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. 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:
@ -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.
"
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>.