There are plenty of books around covering techniques for gathering requirements; however, these tend to be focussed on a particular development method, such as RUP or plan-driven, 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 of the book 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 IEE-830 standard. This is in contrast to most 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 can either be written in the “shall” format described above or in a more compact way that the authors prefer. The authors propose an alternative that allows easier reading:
- User type – the type of user that benefits from the requirement
- End state – where the user wants to reach when the requirement successfully executes;
- Testability – the requirement 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 compare structures closely with “user stories” – a very lightweight requirement format used by agile methods such as XP and Scrum
As a [type of user]
I want to [perform some task]
so that I can [achieve some goal]
tested by [specified a test scenario]
As a [harried shopper]
I want to [locate a CD in the store]
so that I can [purchase it quickly, leave, and continue with my day].
<requirements in context – constraints, scope, additional information – toolset>
The authors define constraints as those types of requirement that limit the number of design solutions. These include those are usually called “non-functional” requirements, 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 the nothing 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.
Summary
This excellent book covers the sweet spot between agile and plan-driven projects and would be equally appropriate for systems and software engineering.
This book would be equally suitable for those practitioners experienced in agile projects who are looking for more rigour and formality and 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.
Modest in size but massively useful.