Requirements to Design: Use Cases and Sequence Diagrams

ClassClass diagrams describe a system's static structure — the classes that will exist and how they relate. They say nothing about where that structure comes from, or how it behaves once it's running. Two other UML diagram types fill those gaps, and together with class diagrams they trace an actual path from "what does the system need to do" to "here's a design ready to implement," following the object-oriented analysis and design process Larman's textbook sets out in detail¹.

Use-Case Diagrams: Capturing Requirements

AA use-case diagram captures requirements from the outside — what the system needs to let someone accomplish, without saying anything yet about classes or implementation. Its vocabulary is small: an actor (a person or external system interacting with the system being designed), a use case (a goal the actor can accomplish, drawn as an oval, named as a verb phrase — "Borrow Book," not "Book"), and the association line connecting an actor to the use cases relevant to them — a notation Jacobson introduced specifically to capture requirements from the outside, in the user's own terms, rather than starting design from an internal decomposition of the system².

Two relationships between use cases are worth knowing precisely, because they're easy to use interchangeably despite meaning different things: <<include>> means the including use case always triggers the included one as a mandatory part of its own steps — Borrow Book always includes Check Availability, because you cannot sensibly borrow a book without that check happening. <<extend>> means the extending use case is optional, triggered only under specific conditions — a "Pay Overdue Fine" use case might extend "Return Book" only when a fine is actually owed, not on every return.

Sequence Diagrams: Capturing Behaviour

WhereWhere a use-case diagram names a goal, a sequence diagram shows the actual conversation between objects that achieves it — which object calls which method on which other object, and in what order. Take "Borrow Book" from the use-case diagram above and work it through as a sequence diagram:

Each vertical line is a lifeline — one object, existing across the diagram's timespan. Each horizontal arrow is a message — a method call from one object to another, read top-to-bottom as the order things actually happen in. The thin vertical bar on a lifeline (not drawn explicitly above, but implied wherever an object is actively doing something) is its activation — the period during which that object is executing, as opposed to waiting. Notice that this single sequence diagram uses exactly the classes Class Diagrams already introduced for the same library domain (Library, Book, Loan, Member) — a sequence diagram doesn't invent new structure, it shows the already-designed classes' objects actually collaborating.

The OOAD Workflow

PutPut together, the standard object-oriented analysis and design sequence runs: gather requirements and express them as use cases (what must the system do, from an outside actor's perspective) → build a domain model of the classes involved and their relationships (a class diagram) → work through each significant use case as a sequence diagram, checking that the classes as designed can actually collaborate to achieve it → implement, informed by both. The sequence-diagram step is where a class diagram that looks reasonable in isolation often turns out to be missing a method, or missing a relationship altogether — the class diagram says what exists; the sequence diagram is what forces the question of whether what exists can actually do the thing the use case demands.

Where This Breaks Down

ThisThis sequence — requirements, then design, then implementation, each step completed before the next begins — assumes requirements are knowable and stable up front, which is exactly the assumption an iterative or agile process is built to relax. In practice, teams following an agile process still draw use-case and sequence diagrams, but for one small slice of functionality at a time (one user story, one sprint) rather than the whole system up front, revisiting and redrawing them as understanding of the requirements improves rather than treating an early diagram as fixed once drawn.

References