Requirements and Behaviours

Requirements are what’s wanted. Who wants them? The stakeholders—people and organisations with a stake in the system. These are the system’s owners, the funders of the development, regulatory agencies, people participating in the system behaviour in various roles, recipients of the system’s services, occupants of neighbouring facilities and amenities—and anyone else who may be affected for good or ill by the system's creation and its consequences. Each has a claim to contribute their demands, needs, purposes and desires to the bill of requirements to be satisfied.

For this blog the requirements of interest are behaviour-based: their satisfaction flows from—and depends on—the system behaviour in operation. This criterion excludes project requirements—choice of development techniques, team composition, and budget and schedule; but system functions, throughput and response times, usability, dependability, security, privacy and safety are all included. Also, because the same requirements can be satisfied by different behaviours, they should stipulate effects and consequences of the behaviour, not the behaviour itself. Putting the same point in a simple programming context: requirements should not describe the computation itself, but its desired result.

The IEEE Standard for SRS (Software Requirements Specifications) [1] seems broadly to agree: "... avoid placing either design or project requirements in the SRS". But it continues: "An SRS should be Correct, Unambiguous; Complete; Consistent; Ranked for Importance; Verifiable; Modifiable; and Traceable". The ambition is clear: requirements must state full necessary and sufficient conditions for acceptability of the system described. Scott Adams offers a wiser perspective. Dilbert asks his customer: "First, tell me your market requirements." The customer responds "No, you tell me everything you can design, then I'll tell you which one I like." Correct and complete requirements can make sense only when the desired product is already known and available: "I want an iPhone 11 Pro, Midnight Green, 64GB." In the absence of advance knowledge of the product, requirements and design must proceed together [2].

Confronted by the difficulties they pose, we are tempted to abandon the idea of requirements altogether. In place of requirements stakeholders are sometimes offered fragmented informal descriptions of what is hoped or believed to be a desirable system behaviour. For example: “When the driver presses the Resume button the car accelerates to the Target Speed,” or “If Hi-Power mode is not selected then Hi-Power mode shall be selected when the operator presses the Hi-Power button unless the battery charge indicator shows Low or Very Low.” This practice is misguided. A collection of stimulus-response fragments is a poor way to describe any behaviour: purposeful behaviour needs a text pointer, but a collection of fragments drawn from multiple unidentified constituent behaviours can have no text pointer.

Another approach relies on use-cases. But that's another story.

[1] IEEE Std 830-1998: Recommended Standard for Software Requirements Specifications; IEEE 1998(later superseded).
[2] Bashar Nuseibeh; Weaving together Requirements and Architectures; IEEE Computer 34,3, March 2001.

Links to other posts:
 → System Behaviour Complexity:  The component structure of system behaviour
 → The Text Pointer:  Why the program text pointer matters
 → Use Cases:  What are Use Cases for?