Writing Effective Use Cases

The focus of this text is on use cases that are written, as opposed to modeled in UML. This book may change your mind about the advantages of writing step-by-step descriptions of the way users (or actors) interact with systems. Besides being an exceptionally clear writer, the author has plenty to say about what works and what doesn't when it comes to creating use cases. There are several standout bits of expertise on display here, including excellent techniques for finding the right "scope" for use cases. (The book uses a color scheme in which blue indicates a sea-level use case that's just right, while higher-level use cases are white, and overly detailed ones are indigo. Cockburn also provides notational symbols to document these levels of detail within a design.)

This book contains numerous tips on the writing style for use cases and plenty of practical advice for managing projects that require a large number of use cases. One particular strength lies in the numerous actual use cases (many with impressive detail) that are borrowed from real-world projects, and demonstrate both good and bad practices. Even though the author expresses a preference for the format of use cases, he presents a variety of styles, including UML graphical versions. The explanation of how use cases fit into the rest of the software engineering process is especially good. The book concludes with several dozen concrete tips for writing better use cases.

Software engineering books often get bogged down in theory. Not so in Writing Effective Use Cases, a slender volume with a practical focus, a concise presentation style, and something truly valuable to say. This book will benefit most anyone who designs software for a living. --Richard Dragan

Topics covered:

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.


Indispensable.   October 12, 2001
33 out of 33 found this review helpful

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.


Will change the way you approach processes and requirements   March 26, 2001
Linda Zarate (Azusa, CA United States)
42 out of 44 found this review helpful

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.


Effective Knowledge Transfer   December 4, 2000
29 out of 29 found this review helpful

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.


The Search is Over...   October 24, 2000
Dan Rawsthorne
44 out of 48 found this review helpful

I have been 'doing' Use Cases for a long time, and have run workshops and seminars on the subject - so I think I know what I'm talking about... and it's over.

Alistair has finished the job. Martin Fowler (author of "UML Distilled") and I were discussing this book last week, and we both agreed that Alistair's book wraps up the subject of Use Cases with a nice red bow - there is no need for another Use Case book.

If you want to use Use Cases, or merely to understand them, this is the book to buy.

DrDan ;-)