Customer Reviews

Patterns for Effective Use Cases (The Agile Software Development Series)

5 star:		(3)
4 star:		(0)
3 star:		(0)
2 star:		(1)
1 star:		(2)

 

 

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.

The fact that this book describes a "pattern" named PreciseAndReadable should tell you what you need to know. If you need to be told that use cases should be precise and readable, or that you should name them with active verb phrases (VerbPhraseName), or that they should describe things of value to the business people (UserValuedTransactions), or that you should involve those people in the process of writing them (ParticipatingAudience), or that you should stop writing them when they make those people happy (QuittingTIme), you'll certainly get some value from this book, but it's clear evidence that your problems run considerably deeper than this book will be able to address.

This represents 25 pages of fundamentally simple content spread across 200 pages, and in a thoroughly pretentious manner to boot. Avoid.

Patterns for Effective Use cases is a must read if you need to develop for a software application. The authors describe what makes for a good use case, and make the points memorable with stories, and examples. If you have lots of experience writing use cases many of the patterns will cover things that you already know, but the way the patterns are presented make for an effective tool to help you teach others how to write a good use case. The pattern language format makes it clear that any single practice will not make for a good use case, you need to take a number together, otherwise you may have something that looks good at first glance, but just does not work.

I recommend this book for anyone who is learning to write use cases, or for experienced people who want a refesher course.

While Alistair Cockburn's "Writing Effective Use Cases" book is great for learning how to write use cases, this book takes it to the next level. It enables the reader to understand the issues that teams face when dealing with large numbers of use cases.

The authors cover the pragmatic issues that teams face, providing many real world examples and anecdotes. The pattern language is easy to read and apply on projects. The basic ideas of the pattern language are clearly expressed in the pattern names, for example, "Small Writing Team", "Participating Audience" and "Writers License". The summary on the inside cover provides a handy reminder for those times when you know you are making a mistake, but cannot quite remember the pitfall you are about to fall into.

A great book that I heartily recommend.

The people who will be attracted to this book will be people who are really going to be involved in use case development, whether as actual writers, consulting engineers, subject matter experts, managers, or any other stakeholders in the process. Overall, I found the book to be well written, quite engaging, and, in the main portion where all the patterns are described, nicely organized to enable the reader to almost subconsciously understand how to navigate the pattern language. From a patterns perspective, the collection is more like a true pattern language than many other collections that make such claims and the interrelationships and movement through the language show that the authors did a great deal of work to make the language comprehensive while still keeping it lean. Although I am a veteran use case writer, in reading this text I learned many things that I wish I had known when I was in that practice. The authors have done a superb job at extracting what is the essence of good practice at all levels in developing use cases, and I think that the book could find a spot on many, many software professionals' shelves. Even more importantly, I think they would actually read it. In fact, I think they would study it. I know I did.

This is a good book if you plan to have business analysts writing use cases for other business analysts. It is a lousy book if the audience for your use cases are subject matter experts and technical people/engineers/developers. The "good" examples have all technical details stripped from them supposedly to make them easier to read; in actuality this makes them easier to read for BAs, but useless for anyone else. Details this book recommends ignoring as "design" or "implementation" are actually implied requirements that are derived from non-functional or legacy constraints.

Use cases can be a useful supplement for the "200 page traditional IEEE ... functional requirements", provided they have sufficient technical detail and traceability. Non-technical use cases used to replace traditional requirements is a recipe for project disaster.