This second edition of the book is on how to gather and define requirements using a process based on use cases. The book outlines an iterative approach to using use cases and adapted and evolved based on real experience of using the approach. The book is well written, easy to read and very focused on practicality. I highly recommend the book for those interested in using use cases, in part because if focuses on business rules as atomic elements that are leveraged in use cases and reused across them. This helps keep use cases “cleaner” and more readable and identified a catalog of business rules that must be implemented. Business rules are not requirements, the authors say, and so should be managed separately.
They correctly identify that “The major difference between developing systems 20 years ago and doing it today is that change is much more pervasive now. Changes to business processes and rules, user personnel, and technology make application development seem like trying to land a Frisbee on the head of a wild dog.” They are also very anti the requirements list and argue it must be replaced by something with more structure - use cases, use case diagrams, and business rules. They point out that “Use cases…cannot portray all the subtleties of how a business is run. For this, we need business rules” and that a list of business rules is not the same thing as a list of requirements.