From 283ae80ba410c59caf193076b67eb63568ed8fed Mon Sep 17 00:00:00 2001 From: Alexander Lill Date: Thu, 23 Feb 2023 11:57:12 +0100 Subject: [PATCH 1/2] Improve readability of requirements --- chapters/requirements.bd | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/chapters/requirements.bd b/chapters/requirements.bd index e008c7a..9ad3e2a 100644 --- a/chapters/requirements.bd +++ b/chapters/requirements.bd @@ -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: -* 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 should be able to add to-do list items with a single click. +* 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. +* 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. \ No newline at end of file +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. From c3c8359c8ef884c5ca695df926913a4f8ff51721 Mon Sep 17 00:00:00 2001 From: Alexander Lill Date: Fri, 31 Mar 2023 15:04:16 +0200 Subject: [PATCH 2/2] Change should to must; leave design-choices open --- chapters/requirements.bd | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/chapters/requirements.bd b/chapters/requirements.bd index 9ad3e2a..a5d8487 100644 --- a/chapters/requirements.bd +++ b/chapters/requirements.bd @@ -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: