This book attempts to take use cases to a higher level of science and in part succeed. Its plus points are discussions on management of use cases and the processes a team goes through in completing the creation / validation cycle. There's a lot of good sense here. Some of the patterns are useful. However, there's also a lot of regurgitation from various other texts and papers, some written by the authors themselves. And some key aspects are missing, aspects that are really important to industry and others that have concerned academia. Industry is not too worried about how to name use cases these days; that's easy. They want to be able to estimate how long it will take to build the system from use case points, for instance, or how to achieve forward traceability to the design and maintain traceability back to the requirements and business strategies (not the same thing exactly as the use case goal - which typically is not to stuff up and to make the principal actor happy). Academics are concerned too with effort estimation, with grammar and consistency checking, with dependencies and product lines, and non-functional requirements and whether use cases are at all to do with requirements in the first place and what they are no good for. Not whether we can build a little online booking web site - we can already do that. Though the book does not set out to answer these difficult questions, in its 200-odd pages, it ought to have, since this is what we really want to know about. So, though the book is excellent on what it does address, there's a lot of over kill in this. What's missing is what it does not address - all the hard problems we really need answers to.
