Use Case Modeling and Analysis

# Use Case Modeling and Analysis

6.1 Use Cases as Collections of Scenarios for a Goal

6.1.1 What a Use Case Really Is

A use case — a story of how an actor uses a system to reach a goal — is a collection of related scenarios that share one goal and cover both success and failure outcomes. A scenario (also called a use case instance) is one specific sequence of interactions between actors and the system — one path through the use case. The use case is the complete set; each scenario is one member of that set. This is the RUP definition restated in plain words: "a set of use-case instances, where each instance is a sequence of actions a system performs that yields an observable result of value to a particular actor."

Think of a theatre play to anchor the relationship. The overall drama — say, "Resolve a shoplifting dispute" — is the use case. Each performance on a different night, with different audience reactions and different improvisations, is a scenario. When the system helps a cashier handle a return, the success path (receipt found, refund issued) and the failure paths (receipt not found, reimbursement rejected) are different scenes, but they all belong to the same drama because they serve the same goal.

6.1.2 Functional Requirements Through Use Cases

Why did the industry move away from feature lists? A feature list says what without who or when. "System shall support login," "System shall support payment," "System shall print receipts" gives no order, no interaction, and no visible value test. Teams using such lists frequently reached the final demo only to hear "this is not what we wanted," because the customer's real context — the sequence, the data needed at each step, the error handling, the business outcome — was never written down. That pattern is near the top of causes for project failure when user involvement stays shallow.

Use cases fix this by writing the requirement as a story in context. They ask the more user-centric question set: Who is using the system? What is their goal? What is a typical path, and what are the alternates? Because the story form is simple and familiar, domain experts themselves can write or review use cases, which keeps customers involved — the best defense against building the wrong system.

A crucial process idea travels with this: use cases are just-in-time and evolutionary. They are not written perfectly once at the start in a waterfall style. They are written when needed, refined step by step, and changed happily when a real need changes. The aim is to discover requirements in a convenient, iterative format rather than to freeze them. In the Unified Process this means in early iterations only a small slice of use cases is written in brief form, and elaboration adds detail incrementally based on feedback from early programming and demos.

When to pick which: Feature lists have a place as high-level vision or backlog markers, but never as the contract for what to build. Whenever you need agreement on behavior, write the story.

6.1.3 Success and Failure Scenarios Together

Every use case contains a Main Success Scenario (also called the happy path or basic flow) — the typical unconditional path where everything goes right — and a set of Extensions (also called alternate or alternative flows) that describe success variations and failure handling branched from specific steps of the main flow. Both kinds belong in the same use case because they share the same goal.

Extensions typically outnumber the main flow in thorough writing. That is expected: the combination of happy path plus extensions should satisfy nearly all stakeholder interests for that goal.

Visual intuition: picture a tree diagram. The trunk is the Main Success Scenario, vertical, from trigger at the top to observable value at the bottom. At each step, small branches shoot off — labeled 3a, 3b, 5a, *a — each branch is an extension. Most runs travel the trunk (80 to 90% happy-path traffic), but the branches show every important detour. A good use case balances the trunk and the branches: the trunk is written first and is condition-free; the branches carry all the "if this happens" logic.

6.1.4 Why Stories Work

Use cases are deliberately plain-text stories. The plainness is strategic. Researchers learned that domain experts disengage when analysis methods wrap simple ideas in layers of formalism; customers help most when the format is one they already understand. Stories are that format.

Real-world and domain connection: The switch-case analogy helps teams model any multi-path goal — login, payment, checkout, enrollment — as one use case with branches, rather than inventing a separate use case per branch. In commercial systems such as POS (Process Sale in the NextGen case study), the Handle Payment sub-behavior itself is factored out precisely because card, cash, and check are alternates within the same payment goal. In agile projects this story form becomes the backbone for iteration planning: teams pick the most architecturally significant and high-value stories first and refine them just enough to build and get feedback.

6.2 System Boundary and the Black-Box View

6.2.1 Boundary and Scope

Choosing the system boundary is choosing scope. Inside the boundary is the system under discussion (SuD) — the software (or hardware plus software) you will design. Outside are actors — people, organizations, external software services, or devices that interact with the system. Defining the boundary is therefore defining what you will build and what you will treat as given.

In the NextGen POS case study the boundary is drawn around the POS application itself. The Cashier, the Customer, the Payment Authorization Service, the Tax Calculator, and the Inventory and Accounting systems sit outside. Payment authorization is not within the boundary; there is an external actor that provides it. That one decision alone determines which responsibilities appear in use case text and which are delegated to an interface.

Boundary choices are clarified by asking "who is outside?" List external primary and supporting actors; the boundary then becomes the rectangle that encloses the system and excludes those actors. If the scope broadens to "hardware plus software as a unit" or to "an entire organization," the same technique applies, only the rectangle expands or contracts.

6.2.2 Black Box Thinking

The system is treated as a black box — its inside is not seen while writing requirements. Use cases describe responsibilities of the system as a whole, not the collaboration of its internal parts. "A sale is recorded" is a responsibility of the black box. Whether that recording touches a database, a file, or a cloud store, which table, which SQL statement, which framework — none of that belongs in the use case. It is how the box does the job, decided later during design. Keeping the description at the level of responsibilities preserves implementation freedom and keeps requirements understandable to non-technical stakeholders.

This focus on responsibilities is intentionally aligned with object thinking. An often-quoted line is that software elements have responsibilities and collaborate with others that have responsibilities. At the system level, the whole POS has the responsibility to "log the completed sale." Later, during object design, that responsibility will be decomposed and assigned to collaborating objects such as Register, Sale, ProductCatalog, and external service adapters.

For object-oriented work this view is natural: externally the system offers a set of functionalities to its actors; internally you will do a lot of work to deliver those functionalities, but the actors need not see that detail at requirement time.

6.2.3 Separating What From How

A practical editorial test while writing: does this sentence say what happens or how it happens?

A helpful mental picture for the team is the rectangle with the system name in a use case diagram. That rectangle is the box. The ovals inside are responsibilities the box must fulfil (Process Sale, Handle Returns). The stick figures outside are actors. Lines between actor and oval mean "this actor is involved in this responsibility." No line suggests Actor–Actor interaction — that detail belongs to the use case text, not the picture. Keeping the diagram and the what/how discipline together prevents drifting into architecture during requirements workshops.

Visual intuition: imagine a use case diagram as a stage poster. A bold rectangle center stage is labeled "NextGen POS." Inside, ovals read Process Sale, Handle Returns, Process Rental. On the left margin, a stick figure labeled Cashier (primary actor, near the top-left, consistent with Western reading order) reaches toward Process Sale. On the right margin, figures labeled Payment Authorization Service and Tax Calculator reach back. The line between Cashier and Process Sale has no arrowhead — implying two-way talk: the Cashier gives item identifiers and receives totals and receipts. A one-way arrow would mean passive receipt, but the default is bidirectional. The takeaway in one line: the picture answers "who talks to what," while the text answers "what is said, in what order, to what outcome."

Real-world and domain connection: In retail, banking, and e-commerce checkout alike, the black-box discipline is what keeps business rules reviewable by the people who own those rules. A supermarket manager can validate "the system collects tax correctly" without reading Java or SQL, and an auditor can trace liabilities to recorded sales without knowing the persistence technology. Teams that hold the line on what versus how also keep the door open for technology change — moving from on-prem databases to cloud stores does not require rewriting the use cases.

6.3 Actors, Stakeholders, and Goals

6.3.1 Who Is an Actor

An actor — anyone or anything outside the system that interacts with it by initiating events, providing input, receiving output, or doing both — is defined as a role, not a single person or job title. "Cashier" is a role. Any individual who acts as cashier at a given moment fills that role. The same person may fill different roles at different times (cashier now, supervisor later), and one role may be filled by many people. Actors are external by definition: they sit outside the system boundary, even when the actor is software or hardware. The system under discussion itself can appear as an actor when it calls upon services of other systems.

A stakeholder is a broader set: anyone with an interest in the system, even if they do not directly interact with it. All actors with goals are stakeholders, but not all stakeholders are actors. Owners, security officers, maintenance teams, and downstream systems that consume sales data later all care about the outcome. Listing stakeholders and their interests — "who cares and what do they want?" — is the methodical check that prevents missing a goal. Without it, a responsibility like "salesperson commissions updated" can be overlooked until late, because the salesperson never appears on screen but still has a stake in every sale.

6.3.2 Primary and Secondary Actors and Notation

Three kinds of actors appear in relation to the system under discussion:

• Primary actor — has user goals fulfilled through using services of the system. The primary actor initiates the use case to get something of value. Example: Cashier for Process Sale. Identify them to find the goals that drive use cases.
• Supporting (secondary) actor — provides a service (for example, information or validation) to the system while the primary actor's goal is being pursued. Often a computer system, but can be a person or organization. Example: automated Payment Authorization Service, Tax Calculator, Inventory System. Identify them to clarify external interfaces and protocols.
• Offstage actor — has an interest in the behavior of the use case but is not primary or supporting during that use case. Example: Government Tax Agency that wants tax collected on every sale. Identify them to ensure subtle interests are not missed.

By UML convention, primary actors are drawn on the left of the system boundary and secondary/supporting actors on the right — often with a <<actor>> or <<system>> stereotype to distinguish software systems from people. In Western reading order this puts the driver of the story where the eye starts. The notation is a secondary concern; the meaning — who benefits and who helps — is primary. Place the most critical primary actors and their critical use cases toward the top-left to improve scanability, and stack use cases to imply timing only loosely (top tends to occur earlier).

On the association line between actor and use case, arrowheads deserve care. When no arrow is shown, communication is understood as two-way — the actor both gives input and receives output. Cashier connected to Process Sale with no arrow implies the cashier both gives product and payment details and receives receipt, change, and error information. A directed arrow signals one-way initiation, but many modelers avoid arrowheads unless the passive nature of an actor is essential, because arrows are often misread as data flow (as in a data-flow diagram) rather than invocation. Associations mean "this actor is involved with this use case," not "data flows this way."

Actors also link to events. Each event the system must handle — enter item, make payment, request authorization — comes from somewhere, and that somewhere is an actor with a goal. Writing an actor-goal list (actor → goal) is therefore a direct path to finding use cases: list actors, write what each wants to achieve with the system, and turn each goal into a candidate use case.

6.3.3 Goals, Observable Results, and State Change

This connects use cases directly to business processes, which always have business outcomes. "Process Sale" ends with sale recorded, tax calculated, receipt generated, accounting and inventory updated — outcomes a business stakeholder can name and test. The guideline extends to naming: a use case should be named with a strong verb in domain language — Withdraw Funds, Enroll Student, Process Sale — rather than weak, technical verbs like Process Transaction that reflect a developer view rather than a user goal.

Two ways to phrase the same rule are used in the Unified Process and in Cockburn's writings, and both point to the same check:

• User-goal level — corresponds roughly to an elementary business process (EBP): a task done by one person, in one place, at one time, in response to a business event, that adds measurable value and leaves data in a consistent state.
• Observable result of value — the actor can see that the goal is done and judge success or failure.

The worldview behind this is state-transition thinking, articulated in the lecture as "the world is always moving from one state to another." Each use case moves the system — and the business — from one consistent state to another consistent state, triggered by events. After six months you hold a different employment position; after a sale, the stock level and cash drawer position are different. Events are the triggers; the transition is the work; the consistent end state is the guarantee.

Visual intuition: picture two snapshots of the world. Snapshot A (before): Account X has 500, Account Y has 300, total 800. An arrow labeled "Transfer 100, event: actor requests transfer" points to Snapshot B (after). In a correct execution, Snapshot B shows 400 and 400, total still 800 — consistent. In a failure with proper rollback, Snapshot B is again 500 and 300 — also consistent, with a failure reason returned. The inconsistent middle — 400 and 300, total 700 — is allowed only transiently, never as the final state exposed to actors.

Real-world and domain connection: In the POS cashier-led sale, the Cashier drives the process (primary, left side), while the Payment Authorization Service and Tax Calculator help from the right (supporting, secondary). Placing them left versus right communicates the business arrangement at a glance: who benefits and who provides services. The same pattern recurs in banking, e-commerce, and university enrollment — a human primary actor on the left, system actors on the right — and the state-change guarantee recurs wherever money or inventory moves.

6.4 CRC Cards — An Informal Way to Learn Object Orientation

6.4.1 Class, Responsibility, Collaborator

CRC stands for Class, Responsibility, Collaborator — a very informal, low-tech technique introduced in 1989 by Kent Beck and Ward Cunningham (and others) to teach object orientation itself, with no heavy theory. The physical artifact is a small card, about four by six inches — postcard size — divided into three compartments: the Class name at the top, its Responsibilities listed below on the left, and the names of Collaborator classes it needs to fulfill those responsibilities on the right.

• A class names a kind of object — a template or category (e.g., Sale, Register, ProductCatalog).
• Its responsibilities are the duties it must carry out — what it knows or does (e.g., "record sale line item," "calculate total," "log completed sale").
• To meet those responsibilities it often needs help from other classes; those helpers are its collaborators — other cards it talks to (e.g., Sale collaborates with SalesLineItem and ProductSpecification).

The card's size is intentional. Four by six inches forces brevity: if responsibilities no longer fit on one card, that is a design smell that the class is doing too much and should be split. The collaborator list on the side makes coupling visible at a glance — a card with many collaborators is highly connected and may need simplification.

6.4.2 The Workshop: Acting Out Scenarios

The real power of CRC is the workshop — an interactive role-play, not a diagramming exercise. A group of five to six people each holds one or more cards and plays the role of that class. A use case scenario — ideally a concrete path through Process Sale — is read aloud step by step. The person holding the relevant card says, "In this step I will do this." The next person says what they will do in that scenario, and so on. Each line of the scenario maps to a responsibility on some card, and the dialogue makes explicit where one object calls another for help.

It is both serious and playful. Observers and documenters stay nearby to record requirements as they appear. The "play on stage" turns an abstract design into lived interaction: objects talking to each other, passing data, asking for services. Gaps become obvious in the acting — if no one steps forward for a line ("who calculates tax?"), a missing responsibility or a missing class has been spotted before any code is written.

6.4.3 Why This Helps

The method was built to teach that idea in about half an hour. Half an hour of standing up, holding cards, and walking through the scenarios that belong to the use cases gives a felt sense that no one class can do all the work alone. Each class owns duties and asks collaborators for support. That felt sense is the design.

Beyond teaching, CRC is a practical early analysis tool. By acting through the scenarios that belong to the use cases, the team spots missing responsibilities, missing classes, and missing helpers early — before diagramming and before coding. It is low-cost, requires only index cards and a table, and can be run with both developers and client-side stakeholders (e.g., cashiers, sales managers) in the room, so domain knowledge enters the design conversation directly. The NextGen case study team is encouraged to read a short guide on CRC and try a small role-play for POS or rental workflows.

Visual intuition: picture a table with six people standing, each holding a white index card at chest height. The card tops read Sale, Register, ProductCatalog, SalesLineItem, ProductSpecification, Payment. Below each title, two columns: Responsibilities on the left, Collaborators on the right. A facilitator reads "Cashier enters item 12345." The Register holder steps half a step forward and points to ProductCatalog. The network of pointing gestures during the walk-through is itself a diagram — a living interaction diagram — showing coupling and collaboration density without drawing a single UML line.

Real-world and domain connection: Running a CRC session with developers and client stakeholders for a point-of-sale or a rental workflow makes gaps visible before code is written and before time is spent polishing diagrams that encode the wrong responsibilities. The technique is tool-agnostic and has been reused across retail, university enrollment, and banking domains wherever early OO learning and lightweight responsibility exploration are needed.

6.5 Writing Use Cases — Formats and Templates

6.5.1 Different Formats Teams Use

Teams choose among several widely used forms and pick what suits the project's maturity and risk. All forms share one purpose — to record the main success scenario and its alternates as ordered stories — but they differ in weight:

• Brief format — a terse one-paragraph summary of the main success scenario. Written in a few minutes during early requirements brainstorming to get a quick sense of subject and scope. Test: if you cannot write that paragraph, the use case is not yet clear enough.
• Casual format — an informal paragraph format with multiple paragraphs covering the main success scenario plus a short list of alternate scenarios. Also quick to produce; suitable for early workshops when many use cases are being sketched.
• Fully dressed format — all steps and variations are written in detail, with supporting sections such as preconditions, success guarantees, stakeholders and interests, and extensions. Typically two to three pages per use case and not more. Used after many use cases have been identified in brief form, when the architecturally significant and high-value ones (perhaps 10% in the first workshop) are selected for deeper elaboration. Page 68 of the widely used Larman text shows the canonical example; study one or two fully dressed examples there.
• Two-column / conversational format — actors' actions on the left, system's responsibilities on the right (first promoted by Rebecca Wirfs-Brock and by Constantine & Lockwood). The visual separation aids usability analysis. Functionally equivalent to one-column; choice is stylistic.
• Interaction format — strictly stimulus and response: 1. Actor does X, 2. System responds Y, 3. Actor gives Z, 4. System does W. Each step is an event that moves the system to a new state, making the trigger–response chain explicit.
• Step-by-step or pseudocode — a simple algorithm-like listing of steps, sometimes using alternate markers such as 3a or 3b for branches at a specific step. Useful when the flow is highly branched.

Choice of format is a company or project preference; it is not a correctness issue. What matters is that main success and alternate paths are both recorded in some form and remain readable to business stakeholders. Cockburn's template (available since the early 1990s at alistair.cockburn.us) is probably the most widely shared fully dressed template.

6.5.2 Template Elements

A common fully dressed template — synthesizing Cockburn and Larman — includes these headings. Some are mandatory for clarity; others are optional depending on scope:

Why Stakeholders and Interests is the most important preface. The contract view states: the use case captures all and only the behaviors needed to satisfy stakeholders' interests. By starting with that list — Cashier wants accurate fast entry, Salesperson wants commissions, Customer wants visible prices and proof of purchase, Company wants recorded receivables and fault tolerance, Manager wants override, Government Tax Agencies want tax collected, Payment Authorization Service wants correct protocol — you have a method to derive what must be in the remaining sections, rather than relying on memory. Missing the salesperson interest is how commission handling is missed.

Preconditions state what is assumed true before the scenario begins — they are not tested within the use case. "Cashier is identified and authenticated" implies a prior successful Login scenario. Do not write noise such as "the system has power." Success guarantees state what must be true on successful completion of any path that claims success — Sale is saved, Tax correctly calculated, Accounting and Inventory updated, Commissions recorded, Receipt generated.

The Main Success Scenario is the "happy path," often written without conditions or branching; defer condition handling to Extensions. Steps come in three idiomatic kinds: (1) an interaction between actors, (2) a validation (usually by the system), (3) a state change by the system (recording or modifying something). Idioms include capitalizing actor names and indicating repetition ("Cashier repeats steps 3–4 until indicates done").

Extensions carry the bulk of the text in thorough cases. An extension has two parts: the condition and the handling. Write the condition as something detectable by the system or an actor: "System detects failure to communicate with external tax calculation service" is better than "External tax calculation system not working" because the first names a signal the system can actually test. Label extensions relative to the main flow: 3a, 3b for alternates at step 3; 3–6a for a range; a, b for "at any time" asynchronous events such as manager override or system failure.

Special Requirements and Technology Variations deserve explicit placement. Placing "credit authorization response within 30 seconds 90% of the time" with the use case keeps it near the flow it constrains, though many teams later consolidate non-functional items in the Supplementary Specification for architectural analysis.

6.5.3 How Much Detail

Keep language simple, actor-centered, and testable. Avoid technical terms tied to implementation. Show a clear start and a clear end, just as a flowchart shows start and end with a sequence and branches inside. Use cases are also described naturally as events and state changes — each step is an event that moves the system to a new state. Listing every event the system must support is a good completeness check.

The iterative and evolutionary caution from the early chapters applies directly: writing all use cases in detail before the first development iteration is a classic waterfall misunderstanding, not a healthy UP or agile project. In a well-run cycle, a few critical use cases are written in detail, designed and built in a timeboxed iteration, demonstrated to stakeholders, and then refined. Written specifications give the illusion of correctness; only code and tests reveal what is truly wanted and what works.

Visual intuition: imagine a one-page template poster on the wall. Across the top, boxes for Name, Scope, Level, Primary Actor. Down the left, a tall column for Stakeholders and Interests. In the middle, the Main Success Scenario runs as a numbered spine from 1 to 10. To its right, a dense forest of branches labeled 3a, 3b, 5a, 7b, *a — the Extensions — shooting off that spine. Two smaller boxes at the bottom hold Special Requirements and Technology Variations. The poster communicates the same message as the Larman page-68 example: the spine is the contract's heart, the branches are its reality, and the top boxes are its boundaries.

6.5.4 Cashier Example in Story Form

Real-world and domain connection: Many teams record extensions with labels like 3a, 4b to mark branches at a specific step of the main flow. This notation — shared between Larman, Cockburn, and tooling like AgroUML and StarUML — scales from a five-step casual sale to the deeply branched NextGen Process Sale on page 68 with its dozens of extensions for tax-exempt, price override, coupon, rebate, and printer-out-of-paper. The form stays the same; only the branch catalog grows.

6.6 Finding and Checking Use Cases

6.6.1 How to Find Them

Two practical methods stand out and are often used together in requirements workshops:

• Actor-goal list — the most popular starting point. List actors, write what each wants to achieve with the system, and turn each goal into a candidate use case. For NextGen POS, a fragment looks like: Cashier → Process Sale; Customer → Process Rental, Make Payment; Manager → Manage Users, Manage Security, Handle Returns; System Administrator → Shutdown, Startup. The procedure is: choose the system boundary, brainstorm primary actors (who has goals fulfilled through the system), identify each actor's goals, and define user-goal level use cases that satisfy those goals (usually one-to-one, with occasional exceptions).
• Event list — list every event the system must respond to, often organized with a state-transition view or a system event catalog, and link each event to the originating actor and the goal it serves. Events arise from human actions, time (Time as an actor for scheduled jobs), hardware sensors, or external system messages.

A third lens complements both: follow the system's inputs and outputs. If something must enter or leave the system for a purpose, ask which actor needs it and which goal it serves. "Sales data requested by the Sales Activity System" is an output that points to a use case driven by that remote system's goal.

The textbook stresses process honesty: finding use cases is an evolving discovery, not a one-time specification. Teams are advised not to stress about finding all use cases at once. Step through actors and events, capture what is clear, draw a quick actor-goal diagram, and let the rest appear as understanding grows through iteration demos and feedback. In the Unified Process, business and development participants (including the chief architect) do this together in timeboxed requirements workshops, picking the high-value, high-risk slice to elaborate first.

Helpful elicitation questions include: Who starts and stops the system? Who does system administration, user and security management, log retrieval? Is "time" an actor because the system does something on a schedule? Is there a monitoring process that restarts the system on failure? Who is notified on errors? How are software updates handled — push or pull? Who evaluates system activity or performance? In addition to human primary actors, are there external software or robotic systems that call upon services of the system? Each answer can surface an actor and a goal that would otherwise be missed.

6.6.2 Naming and Scope

For each candidate use case, define its intent explicitly: what is the goal, why does it matter (which stakeholder interest it satisfies), where does it start, where does it end, and what is the happy path that covers 80 to 90 percent of real runs? If you cannot write a single-paragraph summary of that happy path, the candidate is not yet a true use case — it may be a step, a constraint, or a piece of background work that belongs inside a larger use case or in the Supplementary Specification.

A well-formed use case must also be started by a primary actor, must connect to at least one actor, and must give a complete description with start and end marked — just as a flowchart shows start and end with sequence and branches inside.

6.6.3 The Elementary Business Process Check

A widely shared validity check is the Elementary Business Process (EBP) guideline, a term borrowed from business process engineering. It asks whether a candidate is a task that is:

performed by one person, in one place, at one time, in response to a business event, that adds measurable value and leaves data in a consistent state.

Most valid user-goal use cases pass this test, though a few legitimate exceptions exist (small or technical use cases, infrastructure housekeeping). The guideline helps decide: is this really a business task worth supporting as an independent use case, or is it a small step that should live inside a larger use case?

Visual intuition: picture two walls in a workshop. On wall A, sticky notes in two columns: left column actors (Cashier, Manager, Payment Service, Tax Agency, Time), right column goals (Process Sale, Handle Returns, Manage Users, Submit Taxes). Lines connect each goal to its primary actor — that is the actor-goal wall. On wall B, a timeline of events (customer arrives, item entered, payment requested, authorization response, sale logged) flows left to right. Connecting the walls shows coverage: every event on wall B touches a goal on wall A, and every goal has events that trigger and complete it. A gap — an event with no goal, or a goal with no event — is a requirements defect.

Real-world and domain connection: In a store, "Process Sale" readily passes EBP while "scan item" alone does not, because only the larger sale adds measurable value outside the transaction. The same judgment recurs in banking ("Transfer Funds" versus "enter account number") and in university enrollment ("Enroll Student" versus "enter student name"). The method — actor-goal list plus event/state view plus EBP check — travels directly across domains.

6.7 Ranking Use Cases and Drawing Diagrams

6.7.1 Ranking for Planning

Not every use case goes first. Ranking orders implementation across iterations and increments so that the earliest builds deliver the most value and mitigate the most risk. Common label sets are Must-have / Essential / Nice-to-have or High / Medium / Low. In the UP and in agile variants, ranking reflects frequency, business impact, risk, and need — not merely whether a candidate passes the EBP check, and not merely technical neatness.

The NextGen POS example studied in Larman and referenced in the lecture illustrates the judgment. Teams pick the architecturally significant, high-business-value, high-risk goals first (often about 10% in the first requirements workshop) and implement them in the earliest timeboxed iterations.

6.7.2 The Use Case View and Diagram Notation

A standard POS example — consistent across Larman and the lecture — includes: Process Sale, Handle Returns, Process Rental, Manage Security, Manage Users. The Cashier as primary actor on the left drives Process Sale; secondary or supporting actors on the right provide services — Payment Authorization Service, Tax Calculator, Accounting System, Inventory System. Customers may appear as primary actors for goals they initiate directly (e.g., Process Rental where the customer is the driver), while system actors appear stereotyped as <<system>>.

Diagram work is about 20% of the use case effort; writing the stories is 80%. The picture is a summary and a check; the text is the real work. A useful discipline is to treat the diagram as a table of contents: if the diagram lists Process Sale, the use-case model must contain the corresponding written use case with its main flow and extensions. Keeping the two in sync prevents orphan ovals and orphan stories.

Conventions that improve readability (from UML use case guideline literature) include: place primary actors near the top-left where Western reading starts; put the most critical use cases near that actor; stack use cases to imply timing loosely (earlier goals above later ones); name actors with singular, domain-relevant nouns; associate each actor with at least one use case and each use case with at least one actor; draw actors on the outside edges of the diagram to signal they are out of scope. Generalization between actors is drawn with a closed arrowhead toward the more general element — e.g., International Student is like Student — and is applied to actors (and, rarer, to use cases) only when a clear "is like" sentence holds. Simplicity matters more than decoration; avoid curved or diagonal lines that complicate reading.

6.7.3 Happy Path and Completeness

Once the main flow is solid, add alternates. Aim for clear intent, a named main success scenario, and named extensions branched by step (3a, 4b, *a). The combination of happy path plus extensions should satisfy nearly all stakeholder interests for that goal, with only quality attributes and standard constraints spilling into the Supplementary Specification.

Requirements are just in time and will change. Do not spend effort trying to capture everything forever in one pass. The UP's iterative caution is direct: after programming a few critical use cases, the team returns to workshops to refine the next slice with the benefit of real feedback. Capturing too much — specifying edge cases that may never arise — is a sign of overthinking. Capture what the stated problem needs, prove it with executable slices, and extend later when a real change appears.

Visual intuition: picture the POS diagram as a one-glance map on the wall by the coffee machine. Center: rectangle labeled "NextGen POS" containing five ovals stacked vertically: Process Sale at the top, then Handle Returns, Process Rental, Manage Security, Manage Users. Left margin: stick figure Cashier with lines to Process Sale and Handle Returns; higher up, Customer with a line to Process Rental. Right margin: three system stick figures (Payment Authorization Service, Tax Calculator, Accounting) each with dashed lines to the ovals they support. A new team member reading this in ten seconds understands scope, primary drivers, and supporting services — then turns to the text for the behavioral contract. The one-line takeaway: the diagram answers "who and what," the text answers "how, in what order, to what guarantee."

Real-world and domain connection: A single high-level diagram for a supermarket with Cashier, Payment Service, Tax Calculator, and Accounting System lets a newcomer see the whole scope instantly. In later elaboration the same view is refined — specializations like Cashier versus Supervisor (User as parent) may appear, and included subfunctions may be shown — but the map's purpose remains orientation, not specification. Tools such as AgroUML and StarUML automate drawing without changing the principle: keep the map simple, keep the stories detailed.

6.8 Links Between Use Cases

6.8.1 Include — The Common Part

Include (historically also called Uses) captures common behaviour — Login, tax calculation and other common behaviour that appears in several use cases — so you do not repeat it. Include common behaviour Login tax calculation is the textbook motivation: when one chunk is needed by many flows, factor it out as its own use case — typically a subfunction-level use case — and include it where needed. This is text refactoring and linking to avoid duplication, with navigable hyperlinks if the tooling supports it.

Classic reusable examples are Login, security authorization, and tax or GST calculation. Instead of writing the same login steps inside every use case that needs them, write Login once and let multiple callers include it. Likewise, Handle Credit Payment, once factored out from Process Sale's Extensions, can be included by Process Rental, Contribute to Lay-away Plan, and other payment points.

A practical guideline, attributed to Fowler, is: Use include when you are repeating yourself in two or more separate use cases and you want to avoid repetition. Another motivation is decomposition of an overwhelmingly long use case into subunits to improve comprehension.

Include also handles asynchronous event handling that can occur across a range of steps. Using labels a, b, ... or range labels like 3–9 together with an included confirmation or edit use case lets the base flows reference "at any time, Customer selects to edit personal information: Include Edit Personal Information" without enumerating that path at every step.

6.8.2 Extend — The Variation

Simple purchase by cash is the base. Pay by credit card, pay by debit card, pay by digital wallet, handle machine out of order, handle no change, handle timeout — each is an extension handled at the relevant extension point. In modeling terms, all the what-can-go-wrong concerns at each step are collected as extensions to keep the main event flow readable.

A clean mental rule for the lecture:

• Repeating common part is Include — always runs when the base reaches that point, factoring reuse.
• Varying path is Extend — sometimes runs, under a condition or when something fails, inserting alternate behavior.

Factoring exceptions out as extensions keeps the main event flow readable; otherwise a single use case becomes a dense thicket of conditionals.

The extend relationship was designed for situations where the base use case should not be modified — perhaps it is baselined as a stable artifact, or continually modifying it with myriad new extensions is a maintenance burden. You create an extending (addition) use case that names the condition (Trigger) and the extension points (labels in the base such as "Payment, step 7" or "VIP Customer, step 1") where it inserts behavior. The extending use case points to the base with a dashed <<extend>> dependency (opposite direction to include: the extending points to the extended). The extension point indirection is deliberate — step numbering in the base can change without breaking the link.

Visual intuition: picture Purchase Ticket as a horizontal swim lane from left to right. The lane's center line is the main flow. Include appears as a small subroutine box below the lane that the main line explicitly calls at step 7 — a downward arrow labeled <<include>> pulling control into that box and returning. Extend appears as a side lane above, with dashed arrows labeled <<extend>> diving into the main lane at named extension points — the side lane is an optional detour that may activate, or may never activate, leaving the main lane complete even if the side lane were erased. The takeaway: include is a called subroutine; extend is an optional plug-in.

6.8.3 Generalization and When to Keep It Simple

UML also allows generalization — a parent and child link where the child is a specialization of the parent. For actors, generalization is intuitive: User as parent, Cashier and Supervisor as children, where a supervisor can do everything a cashier can plus more. The "is like" rule is a sanity check: "a Supervisor is like a User" and "an International Student is like a Student" make sense; "a Cashier is like a Payment Processor" does not.

For use cases, a child can do everything the parent does plus extra steps, or can rewrite parts of the basic or alternate courses. An example in the literature is Enroll Family Member as a child of Enroll Student: like normal enrollment, but several requirements reduced and fees calculated differently. Inheritance between use cases is much less common than include or extend, introduces another level of complexity, and lacks agreed best-practice guidelines for extracting value. Consultant experience is consistent: complications result and unproductive time is spent debating specialization.

Real-world and domain connection: In a ticket purchase flow, "purchase ticket" is the base; "machine out of order," "cancel purchase," "no cash change," and "timeout error" are useful extensions that keep the success story clean while ensuring rare but critical failures are named. Factoring Login, Tax Calculation, or Find Product Help once and including them wherever needed prevents requirements duplication across shopping, enrollment, and payment domains alike. Tools (AgroUML, StarUML) render <<include>> and <<extend>> as dashed dependencies, with include drawn horizontally (included to the right of the base) and extend drawn vertically (extending below the base) per common convention.

Exam Guidance Summary

This appendix gathers the exam guidance heard across the lecture in one place for quick review. Each point is also marked inline where it applies in the relevant concept section.

Key Industry Applications