This book, although small in size, is large in scope; namely, to provide a comprehensive reference for requirements activities in all sizes of software development projects. This sounds a tall order but the reader is in safe hands as the author succeeds handsomely.
The book assumes that the reader has some experience of requirements specification of software development: it would not be suitable for a complete novice as the information contained is not only densely packed but the sheer variety of techniques contained means that it would be inadvisable to apply them all on a single project. To be fair, the author provides some excellent guidance on which techniques are best suited to which types of project.
The book is split into the following sections:
- Stage Setting
- Elicitation
- Analysis
- Specification
- Validation
- Management
- Adapting Practices to Project Types.
Stage Setting gives a straightforward about aligning the project with the business's objectives and links to project governance areas such as risk management.
Elicitation gives a summary of how to define the requirements - starting by ensuring that all the stakeholders are identified prior to the requirements-gathering activity; missing stakeholders are a major cause of requirements being missed. The case study is especially useful here as the list of stakeholders is very comprehensive and would be a good checklist for potential missed stakeholders in your current project.
The author also describes a simple mechanism for ranking stakeholder influence/importance to give the appropriate level of involvement.
The elicitation chapter contains a succinct set of interview questions and details on how to run a focus group - information seldom seen in the popular requirements literature.
The chapter on Analysis is the meat of the book: this contains the techniques for creating requirements models such as use cases, context diagrams, process maps and state diagrams among others. Most importantly, the book suggests which are the most appropriate models to use, dependent on the project's circumstances; namely if you are:
- modelling the business;
- scoping the project;
- fleshing out the user requirements;
- negotiating requirements priorities.
The best parts of the chapter contain information that is hard to obtain in a single volume: namely, what kind of questions to ask the business community in order to derive a data model; the structure and documentation of business rules; and the role of business policies in shaping the requirements. The last category has recently become more important because of increasing legislative and regulatory compliance requirements such as SOX and Basel II.
In addition, there is a detailed section on how to engage the stakeholders in a requirements prioritisation exercise.
The chapter on Specification is interesting, especially for those from the "Agile" community who may be less familiar with the material. The author carefully distinguishes between business requirements, user requirements and software requirements, and then explains where these could be documented. She also gives a good rule of thumb for cross-referencing Use Cases with functional requirements statements. This is useful for those that prefer to start with a high-level Use Case approach but sometimes need to convert to a formal software requirements specification - something the current reviewer has had to do recently.
The Validation part of the book deals with the "play-back" of the requirements to the stakeholders to ensure that the specification is sufficiently complete for the project to continue. Techniques described are: peer review, user acceptance tests (UATs), model validation and prototyping. All are described briefly but well. The inclusion of UATs is interesting but it is not made clear that UATs are essential for the success of any project - not just an optional requirements technique.
After a brief description of the management of requirements through change control and trace mechanisms, the book goes on to describe which requirements practices are best suited to which types of software development project - perhaps the most important part of the book for less-experienced readers. The following types of project are discussed:
- new development;
- maintenance (sub-divided into enhancement, correction and adaption);
- commercial off-the-shelf (COTS).
For each, there are detailed guidelines on which requirements models to use and which documents to produce.
In addition, the author considers whether the project is risk-driven or change-driven.
Risk-driven projects are those that are developing software, the failure of which threatens life or business on a large scale. These types of project tend to have more stable requirements and teams that are geographically dispersed. The author's advice is to consider whether excluding a document set constitutes more risk than including it, and act accordingly.Change-driven projects are those that are less critical and more prone to requirements change, often owing to rapidly-moving commercial environments. In this case, the author suggests leaving out a document set unless it is absolutely necessary - for example, if it is required by an external agency. These types of projects are ideally suited to a more "Agile" approach.
The author concludes pragmatically that the correct amount of documentation is "just enough", but recognises that most projects will lie somewhere between these two and suggests ways of finding the "sweet-spot" between the two.
Once the mild surprise over the physical size of the book is overcome, then its true worth is rapidly apparent. Experienced practitioners may find a minor quibble or two in their areas of expertise but all will find this book a hugely useful summary of material that was until now only available across many volumes. In addition, the book provides a thumbnail case study to provide continuity between the chapters and the author is careful to provide synonyms for technical terms so that readers can orientate themselves. Thoroughly recommended to all but the most inexperienced, who may be better off starting with one of the standard texts.
