Requirements

William Newman

October 21, 2002

Copyright © 2002, William Newman

Software engineering

is unique in many ways as a design practice, not least for its concern with methods for analysing and specifying requirements.

In other engineering design disciplines,

the derivation of requirements is considered a routine matter; to the authors of engineering textbooks it is too straightforward and obvious to get even a mention. In the software world, however, things are different. Failure to sort out requirements is common, often the cause of costly over-runs. Methods for analysing and specifying requirements are always in demand.

In subsequent notes I will offer my own explanation for this peculiar concern with requirements. In the meantime, I want to try to explain what requirements really are, and how to deal with them.

What are requirements?

Requirements specify what a designed artefact must do. They are sometimes expressed in the future imperative tense, e.g., “The system shall provide a means of periodic backup of all files.” This is an example of a functional requirement, as distinct from a non-functional requirement that states quantitative and/or envionmental criteria that the design must meet, e.g., “The phone shall weigh no more than 100 grams.” The arcane future imperative style is usually abandoned in favour of something more familiar: “The system should provide…” or “The phone must weigh…” A complete set of such statements is usually called a requirements specification.

In the life-cycle of an artefact,

requirements define what capabilities or services are to be provided. Notwithstanding the mystique that has been constructed around them in recent years, requirements are as fundamental to creative work as design itself. Behind every design activity, however small, there are always requirements, either tacit or explicit. For the designer these requirements serve two basic purposes. First, they translate some external need into a requirement that can be met through design. Second, they offer a basis for testing the design as it takes shape. If the design is found to meet the requirements it may be assumed to address the need.

A basic model

This basic model underlies the specification and use of requirements in every software project. Diagrammatically it can be presented as shown in Figure 1. The stages of transformation of needs into a system implementation are shown progressing from left to right. However, the progression is never a straight sequence, and rather is made up of numerous iterations, often out of sequence. Changes in one representation (e.g., in the design) can lead to changes in others (e.g., in requirements or in the implementation) and these must be tested for consistency with the source of the change.

Figure 1. The model linking needs through requirements to the design and its implementation.

Does it all start with needs?

Ideally the process of system development should start with an expression of needs, or of some equivalent situation of concern (Checkland 1990); it should then proceed to the identification of requirements, and so on. In a technology-driven world, however, the inspiration for a new system can often arise from a technological advance. The technology is linked up with a putative need, probably very loosely specified, and a process commences of refining both needs and design, and of filling in requirements. During the last ten years the World Wide Web has had a similar inspiring effect on many designers. Recent advances – cameras in mobile phones, self-tracking pens, etc. – are likely to do the same, but perhaps on a smaller scale.

Where needs exist, and a technology can be found that appears to address them, a similar process of gradual “requirements infill” may take place. A celebrated instance was the genesis in 1954 of American Airlines’ Sabre reservation system, during a conversation between C. R. Smith, American Airlines CEO, and a senior IBM salesman, Blair Smith, on a flight from New York to Los Angeles (Goff 99). The first had a need to improve the efficiency of reservations, while the second was able to offer an idea for a design based on computing and communications technology. Completing the stages of the process took eight years; some of the system’s details and rationale have been described by Desmonde (1964).

Testing against requirements

I mentioned a second purpose of requirements, in testing the design. This is an essential part of tracking design progress and accepting the final implementation. In most domains of engineering – aeronautical, civil, mechanical, etc. – requirements play a dominant role as a basis for tests. In software design this role is less visible: testing is sometimes carried out against generic requirements such as usability criteria.

In cases where quantitative requirements have been specified, engineering and software design may adopt a common approach to empirical testing. For example, if a requirement exists that an operating system must boot up in under a minute, or that errors in text recognition should not exceed 1%, then the software is implemented and is put through a test in which the relevant measures are taken. If the software falls short, a further design iteration is undertaken.

This approach is not very popular with engineering designers because of the high cost and delay involved in implementing and testing a design.

The cost of testing components of spacecraft, for example, is a significant proportion of overall development costs: building a testbed may cost more than prototyping the component (Pinkus 97). Research engineers therefore develop analytical models capable of predicting the performance of designs while on the drawing board or in the CAD system. In software development, however, such models are relatively scarce, especially where user-level requirements are the issue. Equally scarce, for that matter, are quantitative requirements. So software testing is usually carried out empirically.

Requirements are necessary and sufficient

The distinction between requirements and design specifications is clear: requirements state what the system must do, designs describe what is to be built. However, this distinction can easily become blurred when requirements for user interfaces are being developed.   We might, for example, find ourselves drawn into specifying precise requirements for the functions in the menu of a Windows-based tool:

The system should provide, under the File heading, functions for creating, opening, closing, printing and print-previewing images, and for exiting from the system.

The system should provide, under the Edit heading, functions for undoing and repeating actions, for …

Or we might simply specify the list of functions to be provided: create, open, close, print, etc.; or just state the requirement that the system should support “the standard range of File and Edit functions.”

The ground-rule in specifying requirements is that they should be sufficient to ensure that the needs are met, but should constrain the design only as necessary. Obviously we don’t want to leave open the possibility that the system will fail to meet the needs. Less obviously, we should not over-constrain the designers, for we might then prevent them from using a particularly efficient or reliable design that we had overlooked. The first version of our File and Edit requirements could be considered over-constraining, for quite a lot of design expertise goes into choosing the layout and wording of these menus. The third version is insufficient, for it allows the designers to leave out functions that may be essential to users. The middle way – the list of functions to be provided – is probably the best option.

Knowing what’s technically feasible

One other danger is that the designers will be unable to meet the specified requirements. This is one of the major reasons why iteration is needed during requirements specification.

Suppose we specify the requirement that text recognition errors should not exceed 1 percent. The customer agrees the specification. When the system is implemented and tested, we learn that the error rate is 8 percent, and are faced with a serious problem. Here, even if the customer’s need was for a 1 percent error rate, we should have checked the feasibility of this before specifying it.

Technical advances often make possible corresponding improvements in the requirements we can offer customers. One such advance, achieved at Xerox PARC in the mid-1970s, was the discovery of a way to implement fast global reformatting of very long documents in a WYSIWYG text editor. Until then, the users of such editors knew that changing the margin settings or font size of a long document could result in minutes of thrashing while the position of every line break was recalculated. Butler Lampson and J Moore realised that only the text on the screen needed to be recalculated at the time, and they deviced a ‘piece table’ scheme that allowed recalculation of other parts of the document to be deferred until they were displayed or written out to file (Hiltzik 99). This permitted the requirement for speed of response to such reformatting commands to be improved from minutes to seconds.

Conclusion: How are needs identified?

This brief discussion of requirements has referred several times to the relationship between requirements and needs. In many respects this relationship mirrors that between designs and requirements. However, techniques for establishing needs are very different from those employed in other parts of the process. I will cover these techniques, and how they relate to the process as a whole, in my lext set of notes.

References

Checkland P. and Scholes J. (1990) Soft Systems Methodology in Action. Chichester: John Wiley.

Goff L. (1999) “1960: Sabre takes off.” See: http://www.cnn.com/TECH/computing/9906/29/1960.idg/

Hiltzik M. A. (1999) Dealers of Lightning: Xerox PARC and the Dawn of the Computer Age. New York: HarperCollins.

Pinkus R. L. B., Shuman L. J., Hummon N. P. and Wolfe H. (1997) Engineering Ethics: Balancing Cost, Schedule and Risk – Lessons Learned from the Space Shuttle. Cambridge: Cambridge University Press.