Requirements gathering has historically been one of the main problems in software development and poor requirements gathering has been one of the main causes of project failure. The traditional specification is too verbose, usually contains much duplication, often misses important requirements (particularly non-functional ones) and almost always contains premature design decisions.
The main part of the book describes a four-stage iterative process for requirements gathering, based on Use cases. It describes the iterations as Facade, Filled, Focused and Finished. The Facade iteration attempts to determine the scope of the proposed system, the actors and a list of use cases that may be required. At this stage the use cases are just placeholders. The Filled iteration elaborates each of the candidate use cases, identifying triggers, preconditions, the basic course of events, the business rules and the exception cases. It also collects and documents non-functional requirements, such as perform-ance, integrity, robustness and maintainability. At the end of this stage, you will have collected a large set of requirements for a system that would satisfy everybody - except the person who has to pay for it.
The third, Focused, iteration separates the essential from the nice-to-have. It prioritises the use cases and removes duplicate processes. It also attempts to identify use cases, or parts of use cases that do not fit well with the remainder of the system and which could be made a separate project. The final, Finished, iteration integrates the non-functional requirements, adds user interface requirements, prototyping the user interface if necessary, finalises the scope of the system and packages the use cases for design.
The real benefit of this book is not its coverage of UML notation, which is slender, nor in the details of its methodology, which is just one amongst many. It provides interesting discussions of subjects that are often ignored; How many iterations do I do? How fine-grained should a use case be? Why should the UI be left until last? It also has coverage of many of the classic mistakes of requirements analysis.
If I were preparing a reading list of books on requirements gathering, this would not be at the top. I would probably want a general methodology-independent book on the problems of requirements specification; Jerry Weinberg has written several excellent books on this subject. I would also want a reference book on whatever methodology I was using, such as Booch et al on UML/RUP. However, for those with time and money to spare, this book provides useful alternative insights into the requirements gathering process.
