Requirements & Use Cases

Why Model and Design Software? exam

Any program that works on day one can still be a failure a year later, when nobody can understand it well enough to fix or extend it. Design and modelling are the course's answer to that problem. This section gives the course's two definitions, then the two forces every design has to survive: complexity and change.

"Tangible" means you can point at it; "abstract" means it leaves out detail that doesn't matter for the question at hand. Because client and developers can look at the same model, it becomes the place where they build a common understanding of the system before (and while) code is written.

Challenge 1: complexity

Physical parts can only touch their neighbours, but software is abstract, so any component can depend on any other. Nothing physical stops a developer from adding one more dependency, and developers tend to add complexity when nothing stops them. With N components there can be up to

The reason is simple counting: each of the N components could depend on each of the other N − 1, and each pair is counted twice (A–B and B–A), so divide by two. Step through the picture to watch the count grow much faster than N itself.

Challenge 2: change

The second force is that requirements change. Larman (ch. 2) reports that about 25% of a typical project's requirements change, and 35–50% on large projects. So a design is judged not just by whether it works today, but by how cheaply it can be changed tomorrow. A design that is hard to change fails over time, even if it works on day one.

Larman's framing

UML, by contrast, is just notation. Knowing UML is not the same as knowing design: someone who draws fluent UML without design skill simply produces bad designs on paper. Larman also takes an agile modelling view: the main purpose of modelling is to understand and communicate, not to document. So you model the hard parts, sketch them quickly and treat the diagrams as throw-away hints, because only tested code shows the true design.

Object-Oriented Analysis vs Design exam

"Analysis" and "design" are such broad words that two people can use them for completely different activities. Larman's fix is to always qualify them: say which kind of analysis or design you mean. Each object-oriented activity is then one kind of the general activity, and each kind produces specific artefacts.

Here is the same idea on a tiny example from Larman (1.4), a flight information system. Watch one name travel through all three activities.

The short form of the distinction is that analysis is the "what" and design is the "how". Use cases themselves are not object-oriented, since they are just stories, but they are the main input to OOA/D.

Bird's-eye example: the Dice Game (Larman 1.5)

Larman's Dice Game runs through the whole pipeline in four artefacts, and it is worth knowing as a map of the course: use case (this Part), domain model (Part II), interaction diagram and design class diagram (Part III). Step through it; each artefact is built from the one before.

UML: Three Uses, Three Perspectives exam

The same UML box can be a whiteboard scribble or a machine-checked specification, and it can stand for a real-world concept or a Java class. Two classifications sort this out: how UML is being used, and what the diagram is describing. Getting the second one wrong is the commonest error in this area of the exam.

Three ways to apply UML (Fowler)

Three perspectives: what the boxes mean

The second classification is about meaning. A rectangle labelled Sale might describe a real sale in a shop, or a Java class in a program. UML uses the same notation for both, so the reader needs to know which perspective the diagram takes.

The commonest exam error here is mixing perspectives: drawing a domain model (conceptual) but slipping in software ideas. Compare the two domain-model fragments below.

The course uses these UML diagrams, and the rest of the site covers each one:

Iterative Development and the Unified Process exam

If requirements change by a third or more during a project, a plan that freezes them on day one is doomed. The course's answer is iterative development, organised by the Unified Process (UP). This section explains how iterations work, what the UP's four phases really are (two are routinely misread), and, from the Week 11 lecture, when in a project modelling and design actually happen.

Iterative and evolutionary development

The work is cut into a series of short, fixed-length (timeboxed) mini-projects called iterations, typically 2–6 weeks long. Each iteration has its own requirements, design, implementation and testing, and ends with a tested, integrated, executable partial system. That partial system is production-grade, not a throw-away prototype.

Because the system grows incrementally from one iteration to the next, the approach is called iterative and incremental. Because the specifications and design evolve through feedback and adaptation, it is also called iterative and evolutionary.

Two planning rules shape the iterations. The first is timeboxing: the end date is fixed, so if the work won't fit, you de-scope (move tasks to a later iteration) rather than slip the date.

The second rule is risk-driven and client-driven planning: early iterations tackle the highest risks, especially the core architecture (which is why the UP is called architecture-centric), and the features the client values most.

The benefits follow from this: less project failure, better productivity and fewer defects; early mitigation of high risks; early visible progress; early feedback and user engagement; managed complexity, with no "analysis paralysis"; and a process that itself improves from iteration to iteration.

The four UP phases

The UP groups its iterations into four phases, always in this order. Two of them are often misread, so pay attention to what inception and elaboration are not.

Four schedule terms are worth knowing precisely, because MCQs like to swap them.

Disciplines: the work that happens in every phase

A discipline is a set of activities and artefacts in one subject area. In any single iteration work happens in most disciplines, but the relative effort shifts: early iterations are heavier on requirements and design, later ones on implementation. This is the picture to have in your head when someone says "analysis and design are disciplines, not phases".

Agile, the agile UP, and common misconceptions

The Agile Manifesto values four things over four others. (The things on the right still have value; the left is valued more.)

The agile UP applies that spirit to the UP. It uses few artefacts, lets requirements and design emerge over the iterations, and applies UML with agile modelling. For planning it keeps a coarse Phase Plan for the whole project and a detailed Iteration Plan only for the next iteration. Agile modelling means modelling to understand, and modelling only the tricky parts: whiteboards, modelling in pairs, developing the static and dynamic views in parallel, and "good enough" notation. Developers model for themselves rather than handing diagrams off.

When do we model? Inception and elaboration in detail (Week 11)

The Week 11 lecture, Modelling & Design in the Software Process (Larman chs. 4, 8, 12, 14), returns to the UP to answer one question: when, in the development process, do we design and create models? Its recap slide is Larman's sample of UP artefact relationships.

Inception

Inception is the initial short step to establish a common vision and basic scope for the project. It asks: What is the vision and the business case? Is it feasible? Buy, build, or both? Is the rough (admittedly unreliable) cost tens of thousands of dollars or millions? Do the stakeholders basically agree, and is the project worth serious investigation? Proceed or stop? Because the UP is not waterfall, inception is not the time to gather all the requirements or make believable estimates; that happens in elaboration.

By the end of inception you should have a common vision and basic scope, a business case that addresses cost, about 10% of the use cases analysed in detail, an analysis of the critical non-functional requirements, a prepared development environment, perhaps some prototypes, and a go / no-go decision. The starred artefacts below are the must-haves, and every artefact is only started in inception, never finished.

Elaboration

Elaboration is the initial series of iterations for building the core architecture, resolving the high-risk elements, defining most requirements, and estimating the overall schedule and resources. When it ends, three things are true: the core, risky architecture has been programmed and tested (an executable architecture); most requirements are discovered and stabilised (the lecture says about 80% reliably defined); and the major risks are mitigated or retired. It is not a do-the-whole-design phase. The artefacts that may be started in elaboration are the Domain Model, the Design Model, the Software Architecture Document, the Data Model, and use-case storyboards and UI prototypes. So the lecture's answer to its opening question is: design and modelling usually happen in elaboration.

Asked in the same lecture whether the architecture must always come first, the lecturer said no: the architecture, the domain model and the design model can be developed concurrently over several iterations, because this is not a waterfall in which a finished architecture precedes everything else.

When and how design and modelling happen

The lecture's slogan is iteratively do the right thing, do the thing right. Requirements work is "doing the right thing" (validation); design is "doing the thing right" (verification). An iterative method embraces change, but you should still provoke the inevitable change early, in the first iterations, so requirements discovery settles and the goal becomes stable. None of this takes weeks: use case writing and domain modelling take a few hours or days, mixed into a few weeks that also include proof-of-concept work, finding resources, planning and setting up the environment.

Use cases are spread across iterations, because one use case is often too big to finish in one short iteration. Different parts or scenarios of it go to different iterations:

Developers design objects in one of three ways:

For the drawing itself, the lecture recommends agile modelling with lightweight UML: model together with other developers; build the static and dynamic models (class and interaction diagrams) in parallel; draw by hand on whiteboards and capture the result digitally, or use a UML tool with IDE integration and reverse or round-trip engineering; and spend a few hours to a day near the start of an iteration (for a three-week iteration). Drawing UML is really making design decisions. Correct notation matters, because a model exists to communicate, but object design skill matters more than UML notation skill, and it rests on responsibility assignment (GRASP, Part IV) and design patterns (Part VI).

Requirements and FURPS+ exam

A requirement that nobody wrote down is a requirement that nobody builds. But "requirements" covers very different things, from "process a sale" to "respond within 30 seconds" to "must be written in Java". This section sorts them into kinds, gives the UP's checklist (FURPS+) so that no kind is forgotten, and shows which artefact each kind lives in.

Managing requirements is a systematic approach to finding, documenting, organising and tracking the changing requirements of a system. It is done iteratively, not by freezing a full specification up front. Elicitation techniques include writing use cases with customers, requirements workshops with developers and customers, focus groups, and demos of each iteration's result to get feedback.

Functional vs non-functional

Requirements split into two broad kinds, and there is a quick linguistic test to tell them apart: try putting the requirement after "The system does…".

Quality requirements (usability, reliability, performance, supportability) are also called quality attributes or the "-ilities". They matter because they strongly shape the architecture (Part VIII). For example, a high-reliability requirement for when remote services fail drives large-scale design decisions.

FURPS+: the checklist

FURPS+ is the UP's requirements categorisation. Use it as a checklist when eliciting or reviewing requirements, so that no category is forgotten. The five letters are the main categories; the "+" adds further ones.

Where requirements live: the UP requirements artefacts

Larman's Fig. 6.1 (also on the Week 1 and 2 slides) shows how these artefacts feed one another, with the use case text as the starting point.

Use Cases, Scenarios and Actors exam

Long "the system shall…" feature lists are hard for customers to read and easy to get wrong, because they describe features out of context. Use cases replace them with stories of someone using the system to get something done. This section defines the vocabulary, each term building on the one before, and then the three kinds of actor.

The core terms

So a use case and a scenario differ as a set differs from one of its members. The picture makes this concrete.

Why use them at all? They are simple stories that customers can write and review, which keeps users involved (and lack of user involvement is a top cause of project failure). They focus on who uses the system, their typical scenarios and their goals. They organise requirements in context instead of long feature lists. And they drive design (through use-case realisations), iteration planning, estimation, testing and user manuals.

The three kinds of actor

Actors come in three kinds, depending on how they relate to the SuD, and each kind is worth finding for a different reason. Throughout this page, primary, supporting and offstage actors keep these colours.

Three further points

Primary actors can be non-human. In the POS diagram the Sales Activity System is a primary actor, because it requests sales data from the POS. Similarly, "time" can be an actor when the system reacts to a time event, such as producing a nightly report.

Who is primary depends on the system boundary. Move the boundary and the primary actor changes:

A related case: for a ticket website that a phone agent uses exactly as a customer would, the agent is only a proxy, so the Customer is the primary actor.

Internal parts of the SuD are not actors. The system's own database, back-end server or classes are inside the boundary. Only external systems are supporting actors. The course's notation reference makes this explicit: the back-end server that processes every request is not drawn as an actor.

Use Case Formats and the Fully Dressed Template exam

Writing every use case in full detail on day one would be waterfall in disguise, but some use cases do need full detail early because they carry the architecture. So use cases come in three formats of increasing detail, and you choose the format by how far into the project you are and how important the use case is.

Three formats

A customer arrives at a checkout with items. The cashier uses the POS system to record each item. The system shows a running total and line-item details. The customer enters payment information, which the system validates and records. The system updates inventory. The customer gets a receipt and leaves with the items.

Main success scenario: A customer arrives at a checkout with items to return. The cashier uses the POS system to record each returned item…

Alternate scenarios:
If the customer paid by credit and the reimbursement to their credit account is rejected, inform the customer and pay them in cash.
If the item identifier isn't found, notify the cashier and suggest manual entry.
If the system can't communicate with the external accounting system, …

There is also a two-column ("conversational") variation that puts the actor's actions and the system's responsibilities in separate columns. No single format is best; what matters is writing the main success scenario and its extensions in some form.

Use case writing across the UP phases

Larman's Table 6.1 is a sample (not a recipe) of how the writing might be spread across a project. Notice how it matches the 10% and 80–90% figures from Section 1.4.

The fully dressed template, section by section

A fully dressed use case follows a standard template. Step through it below using Larman's UC1: Process Sale (condensed). On the left the template fills in; on the right is the current section's content and the rule for writing it.

Use Case UC1: Process Sale
Scope: NextGen POS application     Level: user goal     Primary Actor: Cashier
Stakeholders and Interests:
 - Cashier: fast, accurate entry; no payment errors (drawer shortages come out of pay).
 - Salesperson: sales commissions updated.
 - Customer: purchase quickly with minimal effort; visible item/price display; proof of purchase for returns.
 - Company: accurate transaction records; payment receivables recorded; fault tolerance
   (capture sales even if remote services are down); fast automatic accounting & inventory update.
 - Manager: quick override operations; easy debugging of Cashier problems.
 - Government Tax Agencies (offstage): collect tax from every sale.
 - Payment Authorization Service (supporting): requests in correct format/protocol; accurate payables.
Preconditions: Cashier is identified and authenticated.
Success Guarantee: Sale saved. Tax correctly calculated. Accounting and Inventory updated.
   Commissions recorded. Receipt generated. Payment authorization approvals recorded.
Main Success Scenario:
 1. Customer arrives at POS checkout with goods and/or services to purchase.
 2. Cashier starts a new sale.
 3. Cashier enters item identifier.
 4. System records sale line item and presents item description, price, and running total.
    (Price calculated from a set of price rules.)
    Cashier repeats steps 3-4 until indicates done.
 5. System presents total with taxes calculated.
 6. Cashier tells Customer the total, and asks for payment.
 7. Customer pays and System handles payment.
 8. System logs completed sale and sends sale and payment information to the external
    Accounting system and Inventory system.
 9. System presents receipt.
10. Customer leaves with receipt and goods (if any).
Extensions (selection):
 *a. At any time, Manager requests an override operation:
     1. System enters Manager-authorized mode.
     2. Manager or Cashier performs one Manager-mode operation (e.g. void a sale).
     3. System reverts to Cashier-authorized mode.
 *b. At any time, System fails:
     1. Cashier restarts System, logs in, and requests recovery of prior state.
     2. System reconstructs prior state.
        2a. System detects anomalies preventing recovery:
            1. System signals error to Cashier, records the error, enters a clean state.
            2. Cashier starts a new sale.
 3a. Invalid item ID (not found in system):
     1. System signals error and rejects entry.
     2. Cashier responds to the error (manual ID entry, manual price with Manager
        override, or performs Find Product Help).
 3b. Many items of the same category, unique identity unimportant:
     1. Cashier enters item category identifier and the quantity.
 3-6a. Customer asks Cashier to remove (void) an item:
     1. Cashier enters item identifier for removal.
     2. System removes item and displays updated running total.
        2a. Item price exceeds Cashier's void limit:
            1. System signals error and suggests Manager override. ...
 3-6b. Customer tells Cashier to cancel sale:
     1. Cashier cancels sale on System.
 5a. System detects failure to communicate with external tax calculation service:
     1. System restarts the service on the POS node, and continues.
        1a. System detects that the service does not restart:
            1. System signals error.
            2. Cashier may manually calculate and enter the tax, or cancel the sale.
 5b. Customer says they are eligible for a discount (e.g. employee):
     1. Cashier signals discount request and enters Customer identification.
     2. System presents discount total, based on discount rules.
 7a. Paying by cash:
     1. Cashier enters the cash amount tendered.
     2. System presents the balance due, and releases the cash drawer.
     3. Cashier deposits cash tendered and returns balance in cash to Customer.
     4. System records the cash payment.
 7b. Paying by credit:
     1. Customer enters their credit account information.
     2. System displays their payment for verification.
     3. Cashier confirms.
        3a. Cashier cancels payment step: 1. System reverts to "item entry" mode.
     4. System sends payment authorization request to external Payment Authorization
        Service, and requests payment approval.
        4a. System detects failure to collaborate with external system:
            1. System signals error to Cashier.  2. Cashier asks Customer for alternate payment.
     5. System receives payment approval and signals approval to Cashier.
        5a. System receives payment denial:
            1. System signals denial to Cashier.  2. Cashier asks Customer for alternate payment.
     6. System records the credit payment, which includes the payment approval. ...
 9c. Printer out of paper:
     1. If System can detect the fault, it signals the problem.
     2. Cashier replaces paper.  3. Cashier requests another receipt.
Special Requirements:
 - Touch screen UI on large flat panel; text visible from 1 metre.
 - Credit authorization response within 30 seconds 90% of the time.
 - Robust recovery when remote services (e.g. inventory) fail.
 - Language internationalization of displayed text.
 - Pluggable business rules insertable at steps 3 and 7.
Technology and Data Variations List:
 *a. Manager override by swiping an override card, or entering an authorization code.
 3a. Item identifier entered by bar code laser scanner or keyboard.
 3b. Item identifier may be any UPC, EAN, JAN, or SKU coding scheme.
 7a. Credit account information entered by card reader or keyboard.
 7b. Signature captured on paper receipt (digital capture expected within two years).
Frequency of Occurrence: could be nearly continuous.
Open Issues: tax law variations? remote-service recovery? per-retailer customisation?
   Must a cashier take the cash drawer on log out? Can the customer use the card reader directly?

Extension numbering

An extension's label says where in the main success scenario it can branch off. There are four patterns, shown on one picture.

Four more rules govern how extensions are written:

1. Merge back by default. After its handling, an extension rejoins the main success scenario. If it doesn't, say so explicitly ("use case ends", "Cashier cancels sale").
2. Write detectable conditions. Prefer "5a. System detects failure to communicate with external tax calculation service" over "5a. Tax system not working": the second is an inference, not something the system can observe.
3. Name another use case when you branch into it. Underline its name (Cockburn style) or write "Include Handle Credit Payment", as in "2c. Cashier performs Find Product Help…". See Section 1.10.
4. Factor out the complex ones. If an extension grows very complex, as paying by credit does, move it into a separate subfunction use case.

A second worked example: LazyFair "Update Catalog Item" (Workshop 1)

Use Case UC1: Update Catalog Item
Scope: LazyFair software system   Level: user goal   Primary Actor: Store Manager
Stakeholders and Interests: Store Manager – wants to change an existing catalog item quickly and correctly.
Preconditions: Store Manager has authenticated. Item exists in catalog.
Success Guarantee: Item in catalog updated with entered and confirmed changes.
Main Success Scenario:
 1. Include UC2: Search for Catalog Item.
 2. System displays existing attributes of the catalog item.
 3. Store Manager edits attributes of the catalog item.
 4. Store Manager confirms; System saves changes.
Extensions:
 2a. Search unsuccessful: use case ends.
 *a. Store Manager requests abort of update: use case ends (after confirmation).
 *b. Catalog not accessible:
     1. System notifies user of the problem and logs details.
     2. System initiates periodic reconnection (with status/log updates).
Frequency of Occurrence: tens of times daily.

The alternate flows show both kinds of extension: one at a specific step (2a) and two at any time (*a, *b), and each says whether the use case ends. The search is factored out as a separate use case and included (step 1), which the diagram shows as Update Catalogue Item «include» Search for Catalogue Item (drawn in Section 1.11).

The workshop also advises: if one CRUD operation (Create, Retrieve, Update, Delete) is needed, check whether the others are too. They can then be collapsed into a single "Manage ⟨X⟩" use case, such as Manage Catalogue Items.

Writing Good Use Case Text exam

Two people can describe the same behaviour and produce one use case that survives a redesign and one that is obsolete the moment the screen layout changes. Five guidelines make the difference. Each is shown below as a bad/good pair.

1. Essential (UI-free) style

2. Black-box

3. Terse

Delete noise words. Every word of a use case should carry meaning.

4. Actor and actor-goal perspective

Focus on what gives the actor an observable result of value. The question you ask when eliciting requirements matters: "What do you do?" tends to produce a description of the current procedure, steps and all, while asking about goals gets at what the system is actually for.

5. Root goals

The first thing a stakeholder mentions is often a mechanism, not a goal. Climb the goal hierarchy by asking "why?" until you reach the real requirement.

A quality checklist for use case flows (Workshop 1)

• Is it clear how the use case starts, and does the flow have a definite ending?
• Is every step at the same level of abstraction?
• Does every step describe something that can actually happen and that the system can reasonably detect?
• Does every step make progress toward the goal?
• Are any steps missing? Is it clear how to get from one step to the next, and does the order match what users expect?
• Is every step technology-independent, free of technical details and accidental design decisions?
• Are the steps correctly numbered?
• For each alternate flow, is the triggering condition clearly defined, and is it clear whether it ends the use case or where it resumes?

The workshop discussion added three points. A well-written use case has clarity, a well-defined scope, a glossary of domain terms, and a complete description (main success scenario plus alternate paths). You should write as many use cases as you need, one per user goal; the POS had about 20 user-goal use cases. And if you can only keep one of text or diagram, keep the text.

Finding Use Cases and Choosing the Right Level exam

Given a page of requirements, how do you decide what the use cases are? Too fine-grained and you get "Enter Item ID"; too coarse and you get "Run the Business". This section gives Larman's procedure for finding use cases, then three tests for judging whether a candidate is at a useful level.

The procedure (Larman 6.15)

Work outward: first the boundary, then who stands outside it, then what they want.

Some questions reveal actors and goals you might otherwise miss. Who starts and stops the system? Who does system administration, and user and security management? Is "time" an actor (does the system react to time events)? Is there a monitoring process that restarts it? How are software updates handled? Who evaluates activity, performance or logs? Who is notified of errors? Do any external software or robotic systems call on its services?

Organising the results. You can draw the results directly in a use case diagram, or first write an actor-goal list (it can live in the Vision) and then draw the diagram. Larman's guideline is to draw a simple use case diagram together with an actor-goal list. For the POS:

Event analysis is an alternative route. List the external events, where they come from and why; groups of events usually belong to the same use case.

Three tests for a useful use case

Nearly anything can be a use case at some level, so the practical question is: "What is a useful level to express use cases for application requirements analysis?" Three tests help.

The EBP test fails a candidate in both directions: a single small step ("delete a line item", "print the document") is too small, and something spanning days and multiple sessions ("negotiate a supplier contract") is too big.

Now apply all three tests to Larman's examples (plus one from the lecture). Each test knocks out some candidates.

Reasonable violations

The tests are guides, not laws. Some use cases fail a test and are still worth writing:

Levels and related terminology

The vocabulary comes in three pairs, and the same two use cases illustrate all three.

Relating Use Cases: Include, Extend, Generalisation

Once you have twenty use cases, you notice the same chunk of text (say, paying by credit) written out three times, and a few use cases that have grown unreadably long. Relationships between use cases fix this. They do not change the system's behaviour or requirements; they only organise the text, to aid comprehension, cut duplication and manage the documents.

Which way the arrow points is the most-tested detail, and getting it backwards is a common marked-down error. Learn the three side by side:

«include»: the most common and important

Use include in three situations:

1. The same partial behaviour is repeated in two or more use cases. Fowler: "use include when you are repeating yourself in two or more separate use cases and you want to avoid repetition."
2. A use case is very long and complex, and splitting it into subunits aids comprehension.
3. Asynchronous events the user can trigger at any time, or within a range of steps. Use *a or a range label: "*a. At any time, Customer selects to edit personal information: Edit Personal Information."

In the text, you write the include inside the step or extension (or underline the included use case's name). Process Sale and Process Rental, for example, both pay by credit in the same way:

«extend»

Larman and the course give slightly different reasons for extend, but both come to the same thing: the base use case stays complete and untouched.

The mechanics: the base declares extension points, labels for places in its flow. The extending use case states its trigger/condition and which extension point it uses. Extension points are an indirection, so the base's step numbers can change without breaking the extension.

Generalisation

Larman places generalisation outside the scope of his introduction: it adds complexity, practitioners don't agree on how to get value from it, and successful use case experts manage without it. The notation is a solid line with a hollow triangle pointing at the general use case (or general actor). Avoid it in the exam unless asked.

The three side by side

Use Case Diagrams exam

Text is precise but hard to take in at a glance. A use case diagram is the one-page summary: a context diagram showing the system boundary, the actors outside it, the use case names and the relationships between them. It is a communication tool, but it is secondary to the text: if you can only have one, keep the text. The exam can still ask for the diagram on its own, as the 2018 ATM question below shows.

Notation

Layout conventions. Put primary actors on the left and supporting actors on the right (the notation reference, the Tony's Pizza video and Larman Fig. 6.4 all do this). Offstage actors are usually not drawn; name them in the stakeholders list. Limit the diagram to user-goal level use cases, adding subfunctions only to show an include or extend. Keep it short and simple: the details belong in the text.

Drawing one, step by step: Tony's Pizza

The procedure from the Tony's Pizza case-study video, applied to its ordering system. (The use case names are paraphrased from the video, since its diagram is an image.) Actor labels are coloured by kind as elsewhere on this page.

More course examples

Online clothing website (the notation reference, redrawn in the appendix). The Customer, on the left, is associated with Search Products, View Products, Manage Cart, Checkout Cart and Buy Now. Checkout Cart and Buy Now both «include» Shipping and Payment, because that behaviour is shared, and Advanced Search «extend»s Search Products as a future feature. On the right are «actor» Inventory Management System and «actor» External Payment Service. The back-end server is part of the system, so it is not an actor.

LazyFair (Workshop 1 solution). The Store Manager is associated with Add Store, Update Catalogue Item and Search for Catalogue Item (Update «include»s Search, matching step 1 of the use case in Section 1.7). The Purchaser is associated with Make Purchase, and the Deliverer with Select Delivery. A fuller answer would add supporting actors on the right, «actor» Payment Service and «actor» Mapping Service, since the worksheet mentions a mapping system.

Past exam: the Pennand ATM (2018 S1 Q8, official answer) exam

The Week 12 review lecture (slides 8–9) shows this question with its official answer. It was the only official past-exam answer in the course material until the official 2021 answers were released on 26–27 October; it is now one of three. It shows that a use case diagram can be asked for on its own: the question just says to draw a use case diagram for the Pennand ATM description.

Every decision in the answer follows the procedure above:

• One user-goal use case, Use ATM, for the account holder, not separate ovals for inserting the card, entering the PIN or authenticating. Those are single steps that fail the Size and EBP tests, and authentication on its own fails the Boss Test. The slide's own annotation says to use the Boss, EBP or Size test to justify the level, so write a line of justification next to your diagram.
• Check balance and Cash Withdrawal hang off Use ATM through «include». The slide notes this include relationship can be added (citing the Workshop 1 supplementary materials): a worthwhile refinement, not the core of the answer.
• The Banking Network (sentence 2: authentication) and the Police Card Agency (sentence 12: stolen-card report) are supporting actors on the right, both associated with Use ATM. The official answer draws them as stick figures; an «actor» box is equally correct.
• The Maintenance Technician is a second primary actor on the left, with its own goal, Service ATM (sentence 13).
• Left out: detecting a fault and switching to out-of-service mode is something the ATM does by itself, so it is not a use case; the camera and the local stolen-card list are parts of the ATM, not actors.

Common Mistakes and Exam Q2 exam

Markers see the same errors every year. This section collects them, drawn from Larman's guidelines, the Workshop 1 checklist and the exam wording, and then gives a recipe and a worked answer for the question type that has appeared as Q2 in both 2021 exams: a brief-format use case.

Mistakes in diagrams

1. Unnamed system boundary. Always label the box with the system's name.
2. Plural actor name. Use a singular role: Customer, not Customers (and never a person's name).
3. Arrowhead on an association. Actor–use case lines are plain solid lines.
4. Include drawn solid and pointing the wrong way. It is dashed, labelled «include», and points from the base (Order) to the included piece (Edit Pizza).
5. A noun as a use case name. "Payment" is not a goal; use a verb phrase, or (as here) recognise the external payment system as a supporting actor.
6. An internal part as an actor. The system's own database is inside the boundary. Meanwhile the real external system, the payment service, was forgotten.
7. An offstage actor drawn with an association. The owner only has an interest; list them as a stakeholder.

All twelve mistakes markers penalise

Exam Q2: the brief-format use case

How much detail do the official answers show? (official answer, released 26/27 Oct) Both official answers (worked in full in Part IX) are short. Each has a use case name, a one-line Assumptions statement (e.g. the customer is authenticated), a main scenario of four to six sentences, and an alternate scenario of three or four sentences that names the condition, says how the system handles it, and ends by saying the use case resumes. Neither labels its actors in a separate list: the supporting systems appear by name inside the sentences, with capitals ("the Subscription Management Service", "the Pricing Engine", "the Payment Gateway"), which is enough to show a non-human supporting actor providing a service. The alternate scenarios are prose, not 3a. numbering, so the numbered form below is a good habit but not a requirement.

Recipe

1. Pick one user-goal use case that passes the Boss, EBP and Size tests, and name it with a verb phrase (not "Log In", not "Enter Address").
2. State the actors: the human primary actor (its role), the non-human supporting actor(s) (the external system and what it provides), and optionally offstage actors.
3. Write one paragraph (brief): the trigger, the primary actor's intentions, the System's responsibilities, the interaction with the supporting actor (so it visibly provides a service), and the result of value. Essential, black-box wording; capitalise actor names.
4. Write the alternate scenario in extension form: a step reference (it helps to show the numbered steps the paragraph corresponds to), a detectable condition, the handling steps and the outcome (resumes at step N, or the use case ends). A failure of the supporting actor, or a business-rule failure, shows the most understanding.
5. Don't add a diagram, UI detail or a database actor. Keep it short: 5 marks is about 6–10 lines.

Worked example (new domain): online library loan system

1. Member searches the catalogue.
2. System presents matching titles with availability.
3. Member selects a title and requests to borrow it.
4. System verifies the Member is eligible to borrow.
5. System requests a loan licence from the eBook Licensing Service.
6. eBook Licensing Service grants the licence with an expiry date.
7. System records the loan with its due date and presents access to the eBook.
8. System sends a loan confirmation via the Email Notification Service.

6a. eBook Licensing Service reports that no licence is available (all copies on loan):
    1. System informs the Member that the title is unavailable and offers to place a hold.
    2. Member accepts the hold.
    3. System records the hold in the title's queue and confirms the Member's queue position.
    4. Use case ends; no loan is recorded.

Why this answer is strong, point by point:

• The name is a verb phrase at user-goal level: the boss is happy, it is one person in one session, and it leaves a recorded loan (consistent data).
• The actors are labelled by type, and the supporting actors visibly provide services in the text (the licence, the notification).
• The text is essential and black-box: no buttons, screens or database.
• The alternate scenario is tied to a step, has a detectable condition, and states its handling and outcome.

The weak answer to avoid