go back to the blog

When Requirements turn bad.

  • 24/07/2011
  • no comments
  • Posted by EuroSTAR

The issue was that I was pressing the manager for a date by when all the code would be tested and all the big fixes checked. One of the frustrations that he was experiencing was that out requirements are subject to a large number of late Change Requests and a smaller number of ‘clarifications’. I hope my response was both firm and fair.

However it did make me stop and ponder, because I like to think I am pretty good at reviewing requirements and ensuring that they are absolute and testable where possible. Indeed I have often used and published the ( what must now be famous) Boeing guidelines found in Edward Kit’s book. (I will include them later in this post for reference).

Some of his frustration is based around our subjective requirements. A good example would be, ‘All links within the solution must be accessible and obvious.’ The requirement on the face of it is not specific enough, and because the system was developed without that requirement being further discussed and a design agreed it is now open to argument.

I had to think, was it fair for the supplier, late in the day to be complaining that he did not know what we wanted because it was open to personal interpretation? I concluded that it was.

When specifying the requirement, we did not know how the solution would address this issue. We simply expected that it would. With hindsight, I see now that I should have had a requirement attached to this one that required that a design be produced and agreed and that the design be applied consistently across the site. I don’t think it is all down to us as a customer, the supplier should have been pushing for the same thing I think, but bottom line, the requirement was bad and I should have spotted it.

So having discovered I am not as good as I like to think I am, I would like to lear how other’s do it. What’s the secret to good requirements I wonder.

The question I would like to pose to you is,

How do you ensure that you have good requirements?

What are the key things you look for?

What ‘trigger word’ raise an alarm bell in your head?

What process do you follow?

What tools do you use?

Just in case you have no answers, then I would like to share with you the Boeing guidelines I mentioned above.

1. Complete . All items needed to specify the solutions to the problem have been included.

2. Correct. Each item is free from error.

3. Precise, unambiguous , and clear. Each item is exact and not vague; there is a single interpretation; the meaning of each item is understood; the specification is easy to read.

4. Consistent. No item conflicts with another item in the specification.

5. Relevant.Each item is pertinent to the problem and its solution.

6. Testable.During program development and acceptance testing, it will be possible to determine whether the item has been satisfied.

7. Traceable.Each item can be traced to its origin in the problem environment.

8. Feasible.Each item can be implemented with the available techniques, tools, resources, and personnel, and within the specified cost and schedule constraints.

9 .Free of unwarranted design detail.The requirement specifications are a statement of the requirements that must be satisfied by the problem solution, and they are not obscured by proposed solutions to the problem.

10. Manageable.The requirements specification can be controlled in such a way that each item can be changed without excessive impact on other items.

Changes to the completed requirements specification can be controlled; each proposed change can be traced to an existing requirement; and the impact of the proposed change can be accessed.

Some methods of transforming specifications to reveal ambiguities, errors and/or misunderstandings:

1. Read the sentence several times, varying the stress pattern to reveal possible ambiguities.

2. When a term is defined explicitly somewhere, try substituting that definition in place of the term to see if the definition fits in this context

3. When a structure is described in words, try to sketch a picture of the structure being described. This is especially useful where hierarchical structures are being described.

4. When a picture describes a structure, see if redrawing the picture reveals different possible meanings

5. When there is an equation, try expressing the meaning of the equation in words.

6. When a calculation is specified or implied in words, try expressing it in an equation.

7. When a calculation is specified, work at least two examples by hand and give them as examples in the specifications.

8. Look for statements that in any way imply certainty and then look for proof. Words such as’always’, ‘every’, ‘all’, ‘none’ and ‘never’ are useful clues to indicate unproved certainty.

9.  When you are searching behind certainty statements, PUSH THE SEARCH BACK as many levels as are needed to achieve the kind of certainty a computer will need.

10. Be on the lookout for words that are supposed to be persuasive, such as CERTAINLY, THEREFORE, CLEARLY, OBVIOUSLY, or ‘AS ANY FOOL CAN PLAINLY SEE’. If its not obvious to you then there is a good chance that others will interpret it differently from the author’s intended meaning.

11. Watch for vague words, such as SOME, SOMETIMES, OFTEN, USUALLY, ORDINARILY, CUSTOMARILY, MOST, or MOSTLY. These must be backed by conditions that you can test (and the developers can code to)

12. When lists are given, but not completed, make sure that there is a complete understanding of the nature of the subsequent items. Watch out for ETC., AND SO FORTH, AND SO ON, or SUCH AS.

13. In attempting to clarify lists, as in (12), we sometimes state a rule. Be sure that the rule doesn’t contain unstated assumptions.

14. Look for lists without examples or examples that are too few or too similar to each other to explicate the rule.

15. Beware of vague verbs such as HANDLED, PROCESSED, REJECTED, SKIPPED, or ELIMINATED.

16. PASSIVE VOICE constructions are also traps. Since the passive voice does not name an actor, it’s easy to overlook who is doing the work. An example is ‘The log file is deleted later’. Who or what deletes the log file?

17. Be especially on the lookout for comparatives without referents.

18. Pronouns are often clear to the writer and not to the reader.

Please don’t forget to post your answers.

Tony Simms is the principal consultant at Roque Consulting ( ) and can be contacted via email; [email protected]

Blog post by

go back to the blog


Leave your blog link in the comments below.

EuroSTAR In Pictures

View image gallery