In the AI Unified Process (AIUP), the spec sits at the center. The use case is the unit of work. You write a system use case, AI generates the code, and tests confirm the behavior. The use case is the source of truth. The code is a derived artifact.

That puts a lot of weight on one thing: the quality of the use case itself.

AI does not fix a bad use case. It just builds the wrong thing faster. So if the spec is the center, then writing a good spec is the skill that matters most. And the best book I know on that skill is more than 20 years old: Writing Effective Use Cases by Alistair Cockburn (Addison-Wesley, 2001).

Here is why I keep recommending it, and how it connects to AIUP and to the other use-case posts on this blog.

The book is about one hard question

Cockburn is honest from the first page. Writing a use case is really writing clear prose. The hard part is not “what does a good use case look like?” It is “how do I write one so it comes out good?”

He also says something that takes the pressure off. You do not need a perfect use case to get value. Even a mediocre use case is often more useful than the typical requirements document. So relax, write something readable, and you already help your team.

That message fits the “Keep IT simple” idea, and it fits AIUP. We do not want gold-plated specs. We want clear ones that a person and an AI can both follow.

Four ideas from the book that AIUP runs on

1. Goal levels: write at the right altitude

Cockburn’s most useful idea is goal levels. A goal can sit at the summary level (too high), the user goal level (sea level, the sweet spot), or the subfunction level (too low). To move up, ask “why?”. To move down, ask “how?”.

This is exactly the line I draw in What, Harness, How: The Three Layers of AIUP. A use case written too high is vague and the AI guesses. A use case written too low leaks implementation into the spec, and then the “What” and the “How” get tangled. Cockburn gives you a simple test to stay at the right level.

2. Main success scenario plus extensions

A Cockburn use case has a main success scenario, written as simple numbered steps in active voice, and a list of extensions for everything that can go differently. The extensions are where the real thinking happens.

If you have read Use-Case 2.0: The Forgotten Practice That Solves What User Stories Can’t, this will look familiar. The main success scenario is the basic flow. The extensions are the alternative flows. AIUP feeds exactly this structure to the AI: a clear goal, a step-by-step flow, the variations, and the test cases. Cockburn’s extensions are the part most people skip, and they are also the part the AI cannot invent for you.

3. Stakeholders, interests, and guarantees

Cockburn does not only look at the actor in front of the system. He looks at the offstage stakeholders with interests the system must protect, and at the guarantees the system gives even when things fail.

This is the heart of Why in Spec-Driven Development the Spec Must Be Readable for All Stakeholders. A spec is the shared foundation for everyone, not just developers. Cockburn’s stakeholder thinking forces you to ask who else cares about this goal, and his guarantees give you the acceptance criteria that later become tests.

4. Clear, active-voice steps

Cockburn wants each step to be one short sentence, in active voice, from a clear point of view. He wrote that advice for human readers in 2001. It turns out to be perfect advice for AI readers too.

A clear step is easy for a person to review and easy for an agent to implement. This is the same reason I argue that tracing use cases to tests works so well: when the steps are clean, the link from intent to code to test stays honest.

Old book, new context

Cockburn wrote for a world where humans read the use case and then wrote the code by hand. In AIUP, the use case is also read by an AI that writes the code for us. That changes one thing in practice: we no longer slice a use case into tiny tasks just to make it fit a sprint. The whole use case becomes the unit of work, as I describe in the Use-Case 2.0 post.

But the qualities that make a use case good did not change. A clear goal, the right level, explicit extensions, named stakeholders, and readable steps were good in 2001, and they are good now. If anything, they matter more, because the AI will faithfully build whatever you wrote, including the mistakes.

There is a nice line of heritage here. Ivar Jacobson invented use cases. Use-Case 2.0 (Jacobson, Spence, Bittner) modernized them, and it is one of the foundations of AIUP. Cockburn’s book sits right next to it as the practical writing guide. Together they cover the big picture and the detail.

Should you read it?

Yes, if you want to get better at the one skill AIUP depends on. Read Part 1 first, the use case body parts. That is where the goal levels, scenarios, extensions, and stakeholders live. Part 3 is a set of quick reminders you can keep next to your keyboard.

You do not have to adopt everything. Take the goal-level test, write a clean main success scenario, and put your real effort into the extensions. Then hand that use case to Claude Code and watch how much better the result is when the spec is good.

AI writes the code now. This book still teaches the use cases. That is a pretty good deal for a 20-year-old book.