From c3c8359c8ef884c5ca695df926913a4f8ff51721 Mon Sep 17 00:00:00 2001 From: Alexander Lill Date: Fri, 31 Mar 2023 15:04:16 +0200 Subject: [PATCH] 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: