Last modified: 13:23:31 23-Jan-2009
This is the most approachable of the several books I examined for explanations of the "use case" approach to requirements documentation. Many of the other books covering the topic provide explanations of the technique within general explanations of universal data modelling (UML) approaches in software design. However, the use cases approach is readily useable outside UML projects, as well as within it. In my experience, use cases are the best approach to documenting "user requirements". The authors in this case also mention the UML links and advocate the use of UML, but focus primarily on use case methods. The reader user who may be interested in application of use cases outside of UML approaches can therefore gain a solid introduction to use case techniques without a requirement for broad skill in UML.
Classical approaches involving the development of lists of "things the software must do" suffer problems with organization, and difficulties in clear separation of function, non-functional, business, and software requirements from "user requirements". This creates difficulties for the developers, who must constantly make subtle decisions about what type of requirements are being represented. Difficulties are also created for user representatives who rarely understand or appreciate the distinctions. To contrast, use case techniques seem to naturally guide the developer to representations of user requirements alone, and simultaneously place these in a context that allows nearly any future system user to indicate whether the description provided is accurate and complete.
This book provides a clear explanation of the use case approach, with useful examples, etc.
My primary reservation about this book is that the authors advocate abandonment of several more traditional software engineering approaches on the basis that use cases are so much better. The techniques the authors identify as "obsolete" or "deprecated" include: requirement lists, data flow diagrams, entity-relationship diagrams. I essentially agree with the authors comments about "requirements lists". However, I feel that data flow diagrams and entity-relationship diagrams hold continuing value. I find these tools to be very complimentary to application of use case techniques, and I continue to use them all - often within a single development project. Nonetheless, the authors express their opinions briefly and then get on to the main topic of use case techniques. Their preferences therefore do not interfere with the reader's ability to learn use cases in a way that might harmonize with many of their more traditional software engineering approaches.
Last modified: 13:23:31 23-Jan-2009