Rédiger des cas d'utilisation efficaces

Agile Software Development Series

by Alistair Cockburn

Rédiger des cas d'utilisation efficaces De l'importance des cas d'utilisation... Première étape de la modélisation UML, les cas d'utilisation jouent un rôle essentiel dans le processus de développement d'une application, car ils répertorient tous les scénarios d'utilisation possibles de cette application. ... et de l'art de bien les rédiger ! Malgré son apparente simplicité, la rédaction de cas d'utilisation est une tâche difficile. Que faut-il décrire ? Avec quel niveau de détail ? Comment ne rien oublier ? Cet ouvrage, écrit par l'un des meilleurs spécialistes du sujet, répond à ces questions en proposant une méthodologie claire, illustrée par 40 exemples détaillés et commentés. Quelques cas d'utilisation traités : À qui s'adresse ce livre ?
À tous les utilisateurs d'UML;
Aux chefs de projets, maîtres d'oeuvre et maîtres d'ouvrage ;
Aux analystes-concepteurs et aux développeurs.

Genres: Programming, Business, Software, Technology, Computer Science, Nonfiction, Technical

Paperback

First published October 1, 2000

About the author

Alistair Cockburn is an American computer scientist, known as one of the initiators of the agile movement in software development. He cosigned (with 16 others) the Manifesto for Agile Software Development.

Reviews

[Nick · Rating 3 out of 5]

A full guide that basically explains what I found to be a rather verbose set of templates. Succinctly, you can boil down the books advice to:

Write clearly. Readability is the most important thing. The Most Important Thing.
Work backwards from the goals of the user of the system.
Iteratively enumerate the steps of what can occur, drilling down a level of abstraction each time and asking "what if"
Prefer extensions to use cases over riddling them with conditions that complicate the use case.
Where you draw boundaries is arbitrary.

[Trent Rich · Rating 5 out of 5]

This book has changed and, quite possibly, saved my life.

[Steve Whiting · Rating 4 out of 5]

Really excellent treatment of Use Cases - probably the best coverage I've ever read. Practical & pragmatic rather than theoretical, and all the better for it.

A couple of minor niggles:
- his use of icons to denote the scope of UCs is natural during discussion with stakeholders, but would be painful to work with in documents (and are a bit twee, as well).
- And he is, I think, a bit overly dismissive of UML sequence diagrams as an alternate/complement to textual use cases (though I do agree that context diagrams are of very limited usefulness in comparison).

However, all-in-all, a very good read, and probably even better as a reference book after reading

[Jeff Dalton · Rating 5 out of 5]

Pretty good book that provides some interesting thoughts around organizing and structuring use cases. One of the best tidbits I got from this book is to avoid the dreaded UML use case. Doing use cases in UML never felt right to me. After reading this book Alister confirmed by bias that UML use cases end up making the process of capturing key activities more difficult and provide less clarity (quite ironic).

If you capture requirements or describe how systems work then I highly recommend this book. The advice for structuring sentences, scope and level is well worth the price.

[Marcos Moret]

Profoundly dull, this is a very reader-unfriendly book, if this is the best book available on the subject (as the reviews on Amazon suggest), then there's a big gap on the market waiting to be filled...

[Tim · Rating 4 out of 5]

This is probably the 'bible' for anything use case related. It shows how we can be flexible in the requirements space and still achieve project success

[Richard Malmström · Rating 3 out of 5]

Very usefully - though definitely not entertainment.

[Scott Pearson · Rating 4 out of 5]

The first thing I noticed is that this book is almost 25 years old. That’s an eternity in computer science, especially in a non-mathematical subject. It was written under the “waterfall” paradigm of software development, before agile took over most of the software engineering world. Instead of a page or two, waterfall specifications could require a binder of dozens, if not hundreds, of pages. This book describes “use cases” instead of the “user stories” that agile commends. Why is this book worth someone’s time? In other words, why did I choose to read it?

For two reasons. First, I’m a big fan of studying history. I’ll admit that I didn’t read every page closely in 2025, but I picked up on why agile design documents are organized a certain way. Knowing the history of the field allows me to understand the present better – and theoretically, be prepared for the future better.

Second, most of the literature I’ve read on user stories is overly simplistic. They don’t go into enough detail about what to choose and how. When communicating with my developers, I want to understand what possibilities can and cannot be communicated. To see the global set of options, I had to go back in time to when large design documents were the norm. Just like when someone reads Beowulf or The Canterbury Tales to understand how modern literature took its form, I can see all the glorious option that writing a user story encompasses.

Realistically, I don’t expect this book to be explored by a ton of people now. After all, it’s almost 25 years old! But thumbing through its pages enlightened me a bit as I start to communicate my ideas to the developers I work with. This was the greatest book on use cases in the waterfall era, written by the greatest expert on the subject, so I’m better primed to jump into agile practices and whatever era comes next.

[Nat · Rating 3 out of 5]

It's a good book, but not to my liking. It has too many examples (examples are cool, but I'm not going to just copy your use cases), confusing made-up terminology (if I say something like 'indigo goals', nobody on the team will understand me), childish symbols (kites, waves, houses...?). I personally would much prefer if it was more concise and to the point.

[Franck Chauvel · Rating 3 out of 5]

Use cases? Uh … isn’t it one of those UML diagrams with stickmen, boxes, and bubbles? There is more to it, and “Writing Effective Use-cases” by A. Cockburn is the place to start.

I am always unsure about how much requirement I need, especially when building prototypes? So, reading about use-cases, I came across it on M. Fowler’s post on his “Use Cases”. It still costs about 30 EUR on Amazon, but I went for it anyway. Several years ago, I had read Software Requirements 3, I felt I needed a refresher.
Here come 300 pages on use-cases only. Part I details the various sections they include, whereas Part II discusses frequently asked questions. Part III concludes with a list of “reminders for the busy”. UML diagrams only show up in appendix.

A. Cockburn is another contributor to the Agile Manifesto and created the Crystal family of agile methodology. He authored several books on both use-cases and agile methods.

I found this book very practical as it focuses on textual use-cases as opposed to graphical views as in UML, for instance. We dive straight in with the use case document and its different sections: Scope, main scenario, extensions, etc. Alistair helps with the writing style and provides two templates for the so-called casual and fully-dressed formats. On the downside, I feel the process to collect and refine use-cases is somewhat less clear, but I am guessing this goes beyond the intended scope.

I finally give it 3 stars. It is a good and practical book and a reference I will definitely keep in mind. On the downside, I still do not get how far to go with the requirements.

[Erich Oswald · Rating 4 out of 5]

Opinionated but with a lot of helpful advice

[Wayne · Rating 4 out of 5]

Classic

[Omar Trejo · Rating 2 out of 5]

Practical methodology for comprehensive use cases.

[Mitzi Fox · Rating 3 out of 5]

Good if you're in the field albeit a bit dry, but gotta expect that with the subject....

[Javier Rodriguez · Rating 5 out of 5]

You have decided to develop your own software. Then you cannot avoid use cases. Because these are the central elements of every specification. With these elements, you break down the user stories to a level of detail that allows you to link interfaces, business rules or data structures to the process.

In my opinion, there is nothing better on the market on this topic than Alistair Cockburn's book. What is a use case, when does it come into play, how do you identify use cases, how do you find the right level of abstraction and how do you describe the use case clearly, concisely and unambiguously. All questions to which the author provides simple and practical answers. In the last chapter, the author summarises the most important reminders. First of all, he writes: "Use cases are like an exercise in essay writing, with all the difficulties that come with writing in general". An insight that took me years to understand, and actually, the most fundamental of all.

By far the book I use most for my projects. Not only business engineers can learn a lot from this book, but everyone who deals with digitalization of business. Start thinking in use cases and you will approach every project much more relaxed. Because you always have the overview.

[Jim · Rating 2 out of 5]

It's unfortunate that the authors became too enamored with their own cleverness that they forgot to actually involve with consumers of their book. For example, they offer a section on “graphical icons to highlight goal levels.” To quote from the book:

”Very summary (very white) use cases get a cloud, [cloud icon:]. Use this on that rarest of occasions when you see that the steps in the use case are themselves white goals.”

and:

”Some subfunctions (black) should never be written. Use a clam, [clam icon:], to mark a use case that needs to be merged with its calling use case.”

Ouch. In the second snippet, what I suspect they were trying to say is "this function is too low-level to be a use case."

[Deniss Ojastu · Rating 4 out of 5]

The book describes the methodology of putting the software requirements in written through the use cases. Very systematic and logical approach, clear and easy to understand guidelines for writing, quite good examples.

Sometimes, the methodology as a whole feels too dogmatic and sets quite strict limits. I did not find suggestions for schematic icons too useful either. Besides, the methodology feels a little bit outdated in 2012 (the book was written in 2001).

Overall, recommended to software analysts and software team leads - along with some newer books on the software requirements methodology.

[EOB · Rating 5 out of 5]

I've adapted Cockburn's principles and actual templates effectively to every form of agile or waterfall estimation & planning process I've worked with. I'll always believe success of such things is 70% how you apply them to team & org context, but Cockburn is usually my starting point for documenting human-centric requirements, with little competition. These templates can work so well and robustly with test-driven development, a variety of flow-based planning methods, and classic BMP and ops planning, it's perfect for my kind of widely-scoped work.

[Paulius · Rating 4 out of 5]

Review: (Why did I chose this book?, plot holes, irritations, good things, keynotes, verdict)
I must make an use case for a new project. So, it was quite easy to decide what to read.
Book is dedicated to writing effective use cases. Simple and effective tips are placed in one book. You could follow book step by step and make a use case at the same moment (although I didn't it). For me as with 0 background in this area, book was perfect choice. 4/5.
Type of book: Self study guide.
Goals: To know how to write effective use case.
Tags: Use case.

[Eric · Rating 5 out of 5]

This is one of the most useful technical books that i ever read. Cockburn presents a pragmatic, hands-on method for writing use cases. There's lots of useful advice, including a number of templates that can be adapted to any real project. When I'm writing use cases, this is the book I always return to.

[Marion · Rating 4 out of 5]

This book is ancient in Software Development terms, but I guess it's still one of the very few good reference books on use cases. It clearly describes how use cases can and should be used, and what the possibilities and limitations are. It would be interesting to have an updated version, especially regarding the tools that can be used to create and manage use case sets.

[Gopal · Rating 5 out of 5]

Writing Effective Use Cases by Alistair Cockburn is one of the essential readings for product managers, product marketing managers, engineers and anyone who is a part of software development for end users. This book has provided me the required framework and tools to study use cases of customer relationship management software when I was a novice marketer 16 years ago.

[Chris Corbell · Rating 4 out of 5]

This book should be "in the canon" for anyone who designs software. The only thing that keeps me from five stars is that there is probably more detail and variation than most folks need in the latter half of the book.

[Cori · Rating 4 out of 5]

This is an informative and easy read. Since he touts the necessities of writing use cases in plain text it makes sense that his book would be straightforward. I felt like it jumped around a bit, but this book has certainly helped me to write better use cases.

[Ravi Paleti · Rating 3 out of 5]

Let me read and put some comments here

[Rejeev Divakaran · Rating 3 out of 5]

Not as good as it is been reviewed. But a good reading. More about methodology than about philosophy.

[Linda Walters · Rating 3 out of 5]

This is probably the best book on writing use cases for systems engineering requirements.

[Ramesh · Rating 5 out of 5]

Object oriented, functional, procedural, process, business analysis or just about whatever in the IT/corporate sector - you can't go wrong reading this.

[Thom · Rating 5 out of 5]

One of the best books I've read on Use Cases.

[Mark · Rating 4 out of 5]

Excellent book for information on preparing effective use cases. Recommended highly for business analysts and software testers as an approach to preparing requirements for software development.