Chapter 24. Technical Methods for Specifying Requirements

Key Points

Technical methods for specifying requirements are appropriate when the requirement description is too complex for natural language or if you cannot afford to have the specification misunderstood.
Technical methods include pseudocode, finite state machines, decision trees, activity diagrams, entity-relationship models, and many others.

Throughout this book, we have assumed that most requirements will be written in the team's natural language via the use-case method or in the context of a supplementary specification. We also suggested that requirements can readily be augmented with diagrams, tables, charts , or other techniques to help clarify the meaning. But as we described in the last chapter, there are cases in which the ambiguity of natural language is simply not tolerable, particularly when the requirements deal with life-and-death issues or when the erroneous behavior of a system could have extreme financial or legal consequences.

If the description of the requirement is too complex for natural language and if you cannot afford to have the specification misunderstood, you should consider writing or augmenting that portion of the requirements set with a "technical methods" approach.

You can choose from a variety of technical specification methods:

Pseudocode
Finite state machines
Decision tables and decision trees
Activity diagrams (flowcharts)
Entity-relationship models

And there are many others.

We won't attempt to teach you any of these techniques in detail since each is worthy of a book of its own. But we can provide a brief introduction to each so that you'll have a sense of what to use and when. All of these techniques were considered by the HOLIS project team members as they prepared the HOLIS requirements set. The first incarnation of the set is shown in the HOLIS artifacts found in Appendix A.

Where possible, only one of these technical methods should be used to augment natural language requirements specification for a system. This simplifies the nontechnical reviewers' task of reading and understanding these special elements. If all the systems developed by an organization fall into one application domain, such as telephone switching systems, perhaps the same technical method can be used for all the systems. But in most organizations it's unrealistic to mandate a single technique for all requirements in all systems. The requirements writers need to pick the approach that best suits the situation and help the users and reviewers understand how the technique expresses system behavior.

Let's look briefly at a few of the choices.