1. Properties of Good Requirements Chapter 8

2. Understandable by end users End-users are not often software engineers. Terminology used must agree with end- user’s understanding (for instance, standard accounting terminology.) End-users understanding must agree with ours. Everyone must understand the same thing!

3. Non-prescriptive Non-presecriptive means that the requirement must stipulate what must be done, but not how it must be done. Requirements are “what”, and the design activity is “how” Data structures and algorithms belong in the design documents, not the requirements!

4. Correct Obviously, the behavior specified must be the proper behavior. Correct implies “completely correct”. For instance, the requirement must indicate the fullest possible conditions. While a requirement to support “at least 3” terminals can be considered correct, if the user expects to eventually expand to 300, the requirement should reflect it!

5. Complete Complete is a quality that can apply to both the individual requirement and the sum of the requirements. The requirements set should be considered complete only if it is not missing any requirements that would separate an acceptable system from one that isn’t acceptable!

6. Concise (succinct) Run-on requirements (and prose) can confuse the requirement reader. Requirements should consist of only the necessary information! William of Occam, the philosopher, said that argument should be made “without unnecessary ornament”, and that applies to requirements as well.

7. Precise The bounds of the requirement should be evident and unambiguous. In the case of numerical bounds, it ought to be evident whether the end- points are included or not. A great contributor to precise requirements is consistency in the means used to represent bounds. Words such as “inclusively” and “exclusively” should be used with care so they are consistent.

8. Clear This is the stumbling block for some mathematical specification methods because end-users are not always mathematically adept. However, even natural language specifications can be unclear if they use words with a ‘high level’ of abstraction.

9. Unambiguous Ambiguity is perhaps one of the greatest problems. To parody an old saying: “one word is sometimes worth a thousand pictures.” The “unspecified referent” is a great problem: when using words like “the”, “it”, “that”, readers can become confused about which “it” the writer is referring to!

10. Consistent Requirements should agree with each other: one requirement should not stipulate something that is in conflict with other requirements. In addition, writing requirements in the same ‘form’ provides the reader with a consistent appearance and (hopefully) understanding.

11. Traceable Ultimately code ought to be traceable to the requirement(s) that the code supports. We ought to be able to answer the question “why is this code here?” by tracing the code back through the design to a set of requirements. We ought to also be able to find the code that supports a requirement quickly, if the requirement should change late in the development cycle. Support for traceability starts during requirements specification. Each requirement should have a unique identifier.

12. Modifiable It’s a reality that requirements can change (sometimes frequently.) The form used to write requirements should support easy modification of the requirement. Avoid using “magic numbers” in the requirements. Instead specify “symbolic” values, and define the values elsewhere, very much like manifest constants in code (“ #define ” in C, for instance.)

13. Testable (verifiable) Requirements ought to be something that can be verified. In short, they ought to provide outputs that are measurable based on a given set of inputs. Sometimes, the testing process might impose requirements on the system that must be considered part of the requirements! This is called “design for testability”.

14. Feasible “When the start button is pressed, the system shall transmute an ounce of lead into a ton of gold”: This is a clear, unambiguous, testable, modifiable, and even correct requirement, but it is not feasible. Feasible means that the requirement has a sound basis for design. That is, we probably know at least one way to accomplish this. (If we aren’t sure, we have should be given an opportunity to prototype a solution to find out.)

15. Summary: how to write requirements? Requirements describe what outputs we should expect given a set of inputs. Our requirements could have a form that allows exactly that: If some set of values appear at the inputs Then some set of values appear at the outputs. For instance: If the student id number is negative Then an error message is printed at the console: “Student ID is out of bounds”