There are plenty of books around covering techniques for gathering requirements; however, these tend to be focussed on an agile or plan-driven development method, or focussed on a particular engineering discipline, such as software or systems engineering. Alexander and Stevens’ excellent book focuses simply on how to write better requirements - irrespective on what development method used or what product is under development.
After some solid definitions of commonly-used (and misused) terms within requirements engineering, the authors proceed to describe techniques for identifying the appropriate stakeholders and then how to elicit the requirements from them – elaborating interview, workshop and prototyping techniques.
The authors also describe other sources of requirements, for example:
old documentation;
existing and potential customers;
helpdesk staff;
competitors’ products;
contracts.
It is this section of the book is one that demonstrates the authors’ real-world experience – this reviewer has found many additional requirements and constraints while studying contractual documentation, for example.
The most interesting part from a practitioner’s viewpoint is the book’s approach to structuring requirements. Traditionally, most systems engineering projects have a structure that lists the requirements as a series of “shall statements” enshrined in the IEEE-830 standard. This is in contrast to many software engineering projects that commonly use a scenario-based structure. Scenarios are, in the words of the authors, a “time-sequenced series of activities to structure a set of requirements” - the most popular scenario format being the Use Case format.
The authors prefer to use a combined approach by firstly defining the goals that the system will meet and then creating scenarios that met that goal as a series of individual steps. These steps form the basis for the requirement set and are traditionally written in the future tense (“shall” format) with the following structure:
User type – the type of user that benefits from the requirement
End-state – the state the user wants to reach when the requirement successfully executes with the note that this end-state must be testable.
The authors emphasise that the text is only part of the requirement set; there are other attributes used as appropriate - such as the source of the requirement and its priority.
Interestingly, this structure compares closely with that of “user stories” – a very lightweight requirement format used by agile methods such as XP and Scrum in the following format: as a [type of user] I want to [perform some task] so that I can [achieve some goal] tested by [test scenario(s)].
In addition, the authors define “constraints” as those types of requirement that limit the number of design solutions. Therefore the authors' definition include those requirements are usually called “non-functional”, such as reliability, supportability and maintainability. The importance of this type of requirement is well-known in systems engineering projects; however, this requirement type is often overlooked in “traditional” software projects.
Finally, the authors recognise that no requirement is perfectly correct first time and emphasise the fact the requirements gathering is iterative. Successful projects rely on frequent user feedback – this applies in aspects of requirements elicitation, too.
This excellent book covers the sweet spot between agile and plan-driven projects and would be equally suitable for systems and software engineering projects. It would be equally suitable for those practitioners experienced in agile projects who are looking for more rigour and formality and also for those that are experienced in plan-driven projects who may be looking for a requirements structure that is more easily read by their stakeholders.
The authors’ systems engineering background is a valuable counterpoint to many requirements books that are focussed exclusively on software engineering. Many practitioners with experience in the latter will find their awareness sharpened by the precise definitions of such terms as “affordance”, “constraint” and the distinction between a user requirement and a system requirement.
There is a useful glossary and exercises throughout. Answers are provided, although some have no definitively-correct solutions – rather like the real world.
