Difference between revisions of "Secrets of defining requirements"
(→Three magic words) |
(→Never say never) |
||
| Line 38: | Line 38: | ||
|- | |- | ||
|Users ''never'' want to see their email on the screen||Users do not want to see their email on the screen | |Users ''never'' want to see their email on the screen||Users do not want to see their email on the screen | ||
| + | |- | ||
| + | | . ||There is an implicit "at the moment" here, allowing us to be sure it is correct (at the time of writing). | ||
|} | |} | ||
Revision as of 09:27, 25 June 2019
Contents
Three magic words
These definitions are provided in RFC2199 that indicate requirement levels.
MUST
This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.
MUST NOT
This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.
SHOULD
This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
SHOULD NOT
This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behaviour is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behaviour described with this label.
MAY
This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)
Phrases and words
Never say never
The words never and always should not be used in requirements definitions. This is because it would take forever to prove the statement true or false, and is therefore impossible to be used as an axiom.
| Incorrect | Correct |
|---|---|
| Users never want to see their email on the screen | Users do not want to see their email on the screen |
| . | There is an implicit "at the moment" here, allowing us to be sure it is correct (at the time of writing). |
