Use cases have never been this easy to understand -- or this easy to create! In Writing Effective Use Cases, Alistair Cockburn offers a hands-on, soup-to-nuts guide to use case development, based on the proven concepts he has refined through years of research, development, and seminar presentations. Cockburn begins by answering the most basic questions facing anyone interested in use cases: "What does a use case look like? When do I write one?" Next, he introduces each key element of use cases: actors, stakeholders, design scope, goal levels, scenarios, and more. Writing Effective Use Cases contains detailed guidelines, formats, and project standards for creating use cases -- as well as a detailed chapter on style, containing specific do's and don'ts. Cockburn shows how use cases fit together with requirements gathering, business processing reengineering, and other key issues facing software professionals. The book includes practice exercises with solutions, as well as a detailed appendix on how to use these techniques with UML. For all application developers, object technology practitioners, software system designers, architects, and analysts.

Average Customer Review: ( 55 customer reviews )
Write an online review and share your thoughts with other customers.

PROBLEM: A horde of analysts descend and produce reams of paper that are little more than stick figures and ellipses. They are, well, of little value because they are devoid of any real information and too often confusing. The other side of this problem is an unmanageable number of these "use cases" are produced with inconsistent detail, or an overwhelming amount of detail crammed into a single use case. RESULT: Developers have no clear idea about how to proceed and much rework is done to get the needed information (or developers do proceed and create something not envisioned).

PROBLEM: Use cases are considered to be the requirements specification. RESULT: Developers build something based solely on behavior, leaving out functions and features that customers want or need, and most likely not suited to requirements.

PROBLEM: [Related to the preceding] Test plans and test cases for systems built upon the shaky foundation of bad use cases cannot be properly developed. RESULT: A hit-or-miss test cycle that is almost certainly destined to miss a large number of defects (functional and operational).

Mr. Cockburn's approach to use cases will allow you to sidestep not only the more common problems associated with improper use cases, but hundreds more than will crop up unless the value and context of use cases in the development or project life cycle is understood. Here are some of the key points in this book that make it so valuable: use cases are but one element of requirements and the hub-and-spoke model given in the book places them into proper context, properly developed use cases are written documents, not diagrams (more about that later), use cases are NOT the requirements document, properly formed use cases DO have a set structure and different levels of precision in accordance with well-defined rules, and the use case creation process needs to be carefully managed because, like software source code, you need to ensure that you're working from the right revision.

Part 1 of this book provides clear guidance for writing, managing and using use cases. Part 2 of the book is especially valuable because it addresses frequently discussed topics. Part 3 is a comprehensive list of reminders and rules that will guide you, and Appendix A is a succinct discussion on use cases in UML. A few other things that set this book apart: there are numerous "short stories" throughout the book. Each of these stories reinforce information and concepts, and also epitomize Mr. Cockburn's recurring advice to keep things short - he shows by example how to cram clear information into brief chunks of writing. He also provides a summary of pass/fail tests for use case fields that will make inspections and walkthroughs easy. One piece of trivia answered a question that had been bothering be for years, "why the emphasis on stick figures and ellipses?" The answer: the CASE tool industry, which sold graphical tools, had a lot of influence on the emphasis placed on graphical depictions vs. text-based use cases. This book will set you on the right course and not one that has evolved from vendor agendas. I personally think this is the best book on use cases and is the only one I recommend to clients and associates.

45 of 45 found the following review helpful:

The power of providing real-world examplesMay 22, 2001
By aharnden
If there's one book that can be credited with popularizing use cases, this is it. Alistair Cockburn shares his applied knowledge in `Writing Effective Use Cases' and does so in a very digestible format. This is a handbook, a self-study guide - one full of real-world examples and exercises (with solutions even!) that any analyst or designer can relate to.

Use cases are a form of documenting systems requirements and behavioral design specifications. Written well, they offer benefits to all who participate in the development life cycle. This includes analysts, designers, project managers, developers, testers and even end users. Mr. Cockburn's book takes the reader through the writing process, highlighting both good and bad examples. He makes no claims that any of these examples are perfect. And that is perhaps the greatest element of his book. Commit yourself to read through all the examples. By the time you're finished studying them, you will find your own skills in identifying what makes a `good' or `bad' use case have been sharply honed.

Perhaps the one area this book does not explore in enough detail is the translation of documented use cases into user interface designs. Mr. Cockburn defers to `Software for Use' (another great book) for this. Even so, I would like to have seen some screen shots and comments about the user interfaces that were created from the examples provided. It would have helped tie the whole picture together. Translating use cases to highly usable interfaces is as much an art as it is a science. I believe this element of use-case driven development is best communicated in a live, face-to-face format. That's why organizations like Classic Systems offer workshops on this topic. As an instructor who teaches use case-driven development, I have found `Writing Effective Use Cases' to be invaluable reference tool. Having tried out a number of Mr. Cockburn's ideas in the classroom, student feedback and learning results have shown me just how potent a learning tool this book can be.

Many designers and developers will tell you they are writing use cases; upon closer inspection, we find very few are writing them well. A poorly written use case can actually cost, rather than save, a project time and money. If your looking for a book that will help you and your team harness the benefits of use cases, this one is a good as it gets.

36 of 36 found the following review helpful:

Indispensable.Oct 12, 2001
By soyaki "a guy"
This book is filled with both information and examples on how to build use cases to do what they absolutely have to do -- communicate the requirements for software behavior to all involved stakeholders. While Cockburn is perhaps too quick in de-emphasizing most aspects of visual modeling, he is very correct in stating that the model is a small part of the story of the software to be. Happily, Cockburn does not focus much on elicitation techniques (as many other books of its ilk do); frankly, elicitation is probably mostly unteachable and certainly a manner of personal style. Instead, the author focuses on how to distill elicited information into written material that will actually move the project forward.

This book probably works very well for a novice. For the more experienced professional, it provides a wealth of ideas to return to. While there are a few bits (the cloud-kite-box indicator scheme comes to mind) that are probably not bound to make an appearance in the average analyst's repertoire, it is hard to imagine anyone dealing in problem domain engineering that wouldn't find considerable value here. Good books have been written on the subject, including ones by Armour and Miller, Kulak, and Conallen. While they might provide valuable context, the Cockburn manual easily stands on its own.

42 of 44 found the following review helpful:

Will change the way you approach processes and requirementsMar 26, 2001
By Linda Zarate "IT Ops Consultant"
My background is not software engineering - it's service delivery and process development. I got this book on a strong recommendation from my mentor because one of my techniques, information mapping, has some gaps when it comes to portraying processes. I had heard of use cases before getting the book, but paid little attention to them.

Mr. Cockburn gives one of the most sensible, logical approaches to capturing, validating and modeling requirements I have ever come across. My initial concern that this book was focused on software requirements was assuaged by the numerous case studies that address processes and policies. This is the heart of what I do, and the book gave complete coverage of it. Of course software engineering-specific material is also addressed since this discipline has the biggest audience.

The sections from which I got the most knowledge are: setting scope for the use cases and the way to use a hierarchy of use cases to depict increasing levels of detail, business process modeling, and the tips for writing use cases. This material pointed me in the right direction for resolving some of the shortcomings inherent in information mapping, and also gave me some fresh ideas on how to effectively and clearly develop processes that are traceable to requirements.

One of the things I liked most about the book is its fast pace and reasonable page count. There is no fluff, and at approximately 300 pages it is an easy read for someone on a busy schedule.

My personal opinion is that this book should be promoted to a much wider audience than software engineering - the approach and techniques will certainly serve the software engineering community well, but are also practices that business analysts, process engineers and others in IT can effectively employ. This one goes in that special section of by library that is reserved for books to which I frequently refer.

29 of 29 found the following review helpful:

Effective Knowledge TransferDec 04, 2000

This book takes the task of writing use cases and provides a set of processes and templates that you can use yourself when you need to define requirements for a software project. The author provides many tips and suggestions that you can apply as well as some real world examples from actual projects. There are different approaches talked about which you can choose from, depending on how detailed you can afford to make your use cases. I immediately created a word template based on some of the examples presented in the book...very useful for creating your own process to use when writing use cases. There's also a lot of very useful tips presented throughout the text (along with examples of poor use cases and how to correct them).

It's an easy read and provides sections that summarize the key points so that you can use it as a quick reference for future work. I recommend it to anyone working on requirements or design for a project.

See all 55 customer reviews on Amazon.com