Cockburn A., Writing Effective Use Cases (2001)

 |  Book Reviews

The book presents Use Cases, a great framework for deterministic requirements. The later you discover a requirements mistake, the more it costs to fix. It is like $1 in design phase vs $10 in development vs $100 in production.

Contents

Summary

The book is, in many parts, a modern common sense. It provides a chapter exercises with examples and answers (in Appendix B) simplifying the material understanding and more experienced engineers, reading the book for fun may obtain finer tools or wider perspectives for their daily work.

In my review, I deliberately included only uniquely practical bits for a beginner engineer to quickly grasp the core to build on it later. Additionally, I described approaches that bridge those bits with modern effective software development practices — ultimately turning the review into a concise yet dense modeling (design) guide. Hope you enjoy it :)

[VS] The above "1:10:100" rule 1 (design:development:production defect fix cost ratio) is known about a half a century but often overlooked. Rushing to be "agile" businesses waste resources, (2) on fixing late stage defects where they could have gained (saved = gained) on not making defects instead. Use cases are the way to be deterministic right enough the level you product requires 2 that automatically prevents later stage defects.

Use cases provide a hierarchically structured model of product functionality aggregates. It contains 3 levels (p. 61): Summary Goals (kite), User Goals (sea), and Subfunctions (underwater). The hierarchy ensures the fulfillment of product functionality by connecting business-level goals (Summary or kite-level) through User Goals (sea-level) to Subfunctions (underwater-level). Implementing solutions in code with this model becomes a defect-free, routine task.

Do user stories (1, 2) have their place in this context? Definitely.

User stories contain the same attributes use cases do 3 and are goal and value-justification oriented by design. What they naturally lack is tools to deliver Summary Goals (kite-level) goals' values (through requirements) down to code 4.

Nevertheless, they are easier to write and understand and can either replace or become a part of User Goals (sea-level) use cases. Whenever their use is justified, they should be instrumented with BDD/Gherkin scenarios and SbE, UML diagrams for beyond-banal functionality to model the solution before A/TDDing the code, (2). Besides, underwater-level use cases can (and I would recommend it) be replaced by the mentioned modeling tools too.

Use Case Levels

Summary Goals (kite-level)

Summary-level goals involve multiple User Goals. They serve three purposes in describing the system (p. 64)... they typically execute over hours, days, weeks, months, or years:

  • They show the context in which the user goals operate.
  • They show life-cycle sequencing of related goals.
  • They provide a table of contents for the lower-level use cases, both white (?) and blue.

In other words, they represent high-level business processes that span multiple user interactions or systems, covering end-to-end business workflows (e.g., "Manage Customer Orders") rather than single interactions, often involving multiple actors.

User Goals (sea-level)

It is the goal the primary actor has in trying to get work done or the one the user has in using the system. It corresponds to “elementary business process” in business process engineering (p. 62).

In other words, sea-level use case is a user goal that delivers measurable business value in a single, complete interaction between an actor and the system ("User buys a book"). It must not be a high-level too broad compound workflow (kite-level, "User manages their account"), neither technically-oriented (that might be a underwater-level, "System validates the login credentials").

5-1-use-case-levels Summary Goals (kite), User Goals (sea), and Subfunctions (underwater)

Subfunctions (underwater-level)

These use cases represent low-level, system-centric steps that support higher-level goals (sea-level or kite-level). They are not user goals but rather technical or mechanical actions required to complete a user-facing task (e.g., "Calculate Order Tax" supports "User Checks Out"), often not directly triggered by actors.

What Is in a Use Case

The following is the core content of a kite-level use case (p. 2):

  • Scope: identifies the system that we are discussing.
  • Actor: anyone or anything with behavior.
  • Use case: a contract for the behavior of the SuD.

The following is the optional content for sea- or subfunction-level use cases:

  • Preconditions and guarantees: what must be true before and after the use case runs 5.
  • Main success scenario: a case in which nothing goes wrong (p. 87).
  • Extensions: what can happen differently during that scenario (p. 99).
  • Stakeholder (p. 53): someone or something with a vested interest in the behavior of the (SuD).
  • Primary actor (p. 54): the stakeholder who or which initiates an interaction with the SuD to achieve a goal.

Numbers in the extensions refer to the step numbers in the main success scenario at which each different situation is detected (for instance, steps 4a and 4b indicate two different conditions that can show up at step 4).

When a use case references another use case, the referenced use case is underlined.

Use Case Formats

There are multiple use cases formats (p. 119). Two formats provide better value for beginners.

UML use cases diagram is good for kite-level use cases 6.

uml-use-case-example

The tabular format is good starting point for sea- or subfunction-level use cases.

1-1-table-use-case

Requirements and Use Cases

(p. 13)

  • They really are requirements 7. You shouldn’t have to convert them into some other form of behavioral requirements. Properly written, they accurately detail what the system must do.
  • They are not all of the requirements. They don’t detail external interfaces, data formats, business rules, and complex formulae. They constitute only a fraction (perhaps a third) of all the requirements you need to collect—a very important fraction but a fraction nonetheless.

Scenarios (Extension and Steps)

Refer to p. 87, 99 for original content.

[VS] Scenarios, alternatives (extensions) and steps are of finer granularity than kite- or sea-level use cases. Modeling the behaviors of finer granularity is difficult with textual formats presented in the book.

Nevertheless the original table format for sea-level use case mentioned above is a good staring point. What we do is we, better, rephrase the use case title in a user story format. And then, for non-banal cases, replace scenarios and extensions with separate BDD/Gherkin scenarios, SbE, UML diagrams (Sequence + Class + State). It would provides us with a good enough model to start A/TDDing the code.

Footnotes

  1. Now add here the sometimes irreversible consequences of production defects, like lost customers, lost court cases, bankruptcy threats etc. They may overweigh the defects fix costs by orders of magnitude. ↩

  2. It is a common sense to adapt use cases (as any tools) to your product strictly or loosely, gradually or upfront, coarse- or fine-grained depending on how far is your domain and product functionality foresight spans.
    But one must understand, no code can be written without 100% determinism. It is your choice if your programmers' determinism is either implicit, unintended and unconscious, not explicitly conveying what stakeholders want, in most cases leading to defective code or explicit, intended and conscious, leading to zero-defects and doing exactly what stakeholders need from the first time.
    To conveying 100% explicit stakeholder-aligned determinism to code use the specific engineering tools and techniques I mentioned above along with whatever managerial tools you apply. ↩

  3. Aligning use cases to user stories, actors are user stories' roles, User goals are business values and Subfunctions (in a broader sense) are functions respectively. ↩

  4. To compensate for this, some vague managerial tools were suggested which are by nature are not appropriate for modeling product functionality that must be deterministically translated to code. ↩

  5. Preconditions and guarantees (inputs and outputs) coming from Design by Contract are most important here as they implicitly tell the modeler a story about the required explicit behaviors of the use case. The outcomes - main success scenario, extensions, errors, as well as inner states all are dependent on expected inputs and outputs and can (must) be derived by the modeler. Also see "ch. Preconditions, Triggers, and Guarantees". ↩

  6. The image example is taken from the later source as the book lacks useful UML example because UML was developed nearly at the same time the book was written, not being much in practice then. ↩

  7. Wiegers K., Software Requirements Essentials (2024), Robertson J., Mastering the requirements process (2014), Beatty J., Visual Models for Software Requirements (2012). ↩