4 of 4 people found the following review helpful
Cuts to the core on how to find and document requirements.,
By A Customer
This review is from: Essential Systems Analysis (Paperback)
The lessons in this book pass the test of time and are still
useful in the Object-Oriented era. The authors clearly describe how to separate routine and expected requirements (aka. "custodial" processes for validation and security) from the data, processes, and rules that make up the baseline business process a client wishes to assist with software.
There are several books on how to *draw* requirements models (ie. ERD, DFD, FDD, IDEF, et al.), but this book focuses more on *what* to put in the model. I have consulted on many projects where 100's of pages of "requirements" were documented, yet the documents actually contained 60% design preferences (in detail), 20% expected requirements (ie. performance, security, backup/recovery, installation, service, etc.), and (at most) 20% core, unchanging, business requirements. This book helped me guide these teams to discover and document what their customers needed and wanted, and separate these essential requirements from the typical fluff and "no-duh" staements that had previously been passed-off as their requirements document.
OO zealots can gain useful insights from this book on what makes up a "business requirement", if they can put aside their bias against traditional structured modeling techniques.
Mark Lucas, Houston, TX Feb 1997