If you want to really get into use cases, then this book is a pretty good starting point. There is a strong emphasis throughout the book on understanding what you should and should not be looking to get from use case modelling. This puts things into perspective, and for anyone who sees use case modelling as diagrams with stick-men, ovals and not a lot of useful information this book should be something of an eye-opener. The strength of use cases lies in the documentation and descriptions that should accompanyuse case diagrams rather than in the diagrams themselves.

A lot of the book is given over to considering what kinds of information should be captured in a use case. But in addition to this, considerable effort is made to address procedural and organisational aspects of use case modelling. This is important, because for use cases to be used effectively, it is vital that all concerned parties (I can't bring myself to use the S word...), many of whom are not technically oriented, understand what they are doing and what they should expect to gain from it.

The authors go out of their way to try and make the transition from theory to practice as easy as possible. Very often, the ideas and theories presented in books sound great, but prove very difficult to get to grips with on the ground. Two worked examples of use case descriptions are given in the appendices, which really help the reader to understand the kind of information they should be looking to capture.

This book is certainly a useful and thorough guide to use case modelling. That said it is probably best to be selective about which bits of the recommended approach are used. It isn't hard to see project teams getting bogged down in producing reams of documentation at the expense of generating real shared understanding of the project requirements.