Use-Case Analysis

Writing one out

A use case can be written at three levels of detail. A brief use case is one paragraph. A casual one is a few paragraphs of story. A fully written one follows a template, and it is the form to use for the important and complicated goals of your project:

The heart is the main success scenario: the steps of the path where nothing goes wrong, written in plain sentences, each saying who does what. Then comes the valuable part, the extensions: for each step, what else could happen, and what the system does then. Numbering an extension after its step, 3a, means "instead of step 3 going as written".

Write the steps as what happens, not how the screen looks. "The student chooses the items and quantities" survives a redesign of the menu page. "The student taps the orange plus button beside the item" does not.

Two relationships between use cases

When use cases share behaviour or add to each other, UML offers two relationships. They are drawn in Chapter 20, but they are decided here.

Include. When the same steps occur in two or more use cases, they can be written once as a use case of their own, which the others include. The included steps always happen as part of the including use case.

Extend. When a use case adds optional behaviour to another at a particular point, under a condition, it extends that other use case. The extended use case makes complete sense without the extension; the extension only makes sense inside it.

Use both sparingly. A use case model with arrows everywhere is usually a flowchart in disguise. The worked team found one genuine extension and no genuine inclusion, and said so.

The worked project: the use cases

Actors and goals

The worked team had three human actors, from Chapter 5's user classes: Student, Counter staff and Owner. The owner can do everything the counter staff can, and more; in UML terms the owner is a specialisation of the counter staff actor, which Chapter 20 draws as an arrow with a hollow triangle.

The list

All seventeen functional requirements appear in the last column, and every use case realises at least one. That two-way check is the first thing the team's guide asked about.

UC-4 Place an order, fully written

Primary actor: Student. Goal: to order lunch for a pickup slot, and know the order number. Preconditions: the student is signed in. At least one item can be ordered and at least one slot is open. Trigger: the student opens the menu page.

Main success scenario:

1. The system shows today's menu, and the pickup slots that are still open with their cut-off times.
2. The student chooses one or more items and a quantity of each, and a pickup slot.
3. The student asks the system to place the order.
4. The system checks that the slot is still open, that the student has no active order for that slot, and that there is enough of every item left.
5. The system takes each item from the stock, records the order as placed, and gives it a number.
6. The system shows the student the order number and the slot.

Extensions:

• 2a. The student chooses more than 5 of one item or more than 10 items in all: the menu page will not let the quantity go higher. If a request arrives anyway, the system refuses it, naming each problem.
• 3a. The student has lost their connection: the page says it cannot reach the canteen server and the order is not placed. The student tries again.
• 4a. The slot has closed since the page was opened: the system refuses the order and says ordering for that slot has closed. The student chooses another slot and returns to step 3.
• 4b. The student already has an active order for this slot: the system refuses, saying so. The student chooses another slot, or keeps the existing order.
• 4c. An item has been taken off today's menu: the system refuses the order, naming the item.
• 4d. Fewer portions of an item are left than were asked for: the system refuses the whole order, saying how many are left, or that the item is sold out, and nothing is taken from the stock. The student changes the order and returns to step 3.
• At any step. The student's sign-in has expired: the system refuses the order and asks the student to sign in again.

Postconditions (success): the order is recorded as placed for the chosen slot and today's date, the stock of each item is reduced by its quantity, and the student has the number. Requirements: FR-7, FR-8, FR-9, FR-10, FR-11; NFR-1, NFR-2.

Read extension 4d again. It is FR-9's hardest sentence from Chapter 10, told as a story, and it will become a test in Chapter 53 in which a thali is ordered with too much biryani and the thali's stock is checked afterwards.

UC-6 Cancel an order, and the one extension

Primary actor: Student. Goal: to cancel an order the student no longer wants, before the kitchen starts on it. Preconditions: the student is signed in and viewing their orders (UC-5); the order is theirs and is placed.

Main success scenario:

1. The student asks to cancel the order.
2. The system asks the student to confirm.
3. The student confirms.
4. The system marks the order cancelled and returns its items to the stock.
5. The system shows the order as cancelled.

Extensions:

• 3a. The student changes their mind: the order is kept.
• 4a. The counter has started preparing the order since the page was loaded: the system refuses, saying the order is being prepared and can no longer be cancelled.

Cancelling happens only from the list of one's own orders, and only when an order is still placed. It is optional behaviour added to UC-5 at one point, under one condition. That is exactly what the extend relationship means, and it is the only one in the worked team's model: UC-6 extends UC-5.

They looked for an include and did not find a real one. Signing in is needed before most use cases, and some textbooks draw that as an include. The team treated it as a precondition instead, because signing in is a goal in its own right (UC-2), not a shared fragment of other goals, and wrote that reasoning into the SRS.

UC-8 Update order status, briefly

The counter staff member, seeing an order in the list for the current slot, moves it to its next status with a single tap: placed to being prepared, being prepared to ready, ready to collected when the student pays, or ready to not collected at the end of the break. The system refuses any other change, such as placed straight to ready, and says why. An order marked not collected does not return its food to the stock.

The team wrote UC-8 as a brief use case because its rules are already exact in FR-15. A fully written version would have repeated them.

Do this for your project

1. List the actors from your stakeholder register. Remember external systems, if any.
2. List each actor's goals, and name one use case per goal, verb first.
3. Check the level of each: satisfying in one sitting, neither a single click nor a whole job.
4. Map use cases to functional requirements, both ways.
5. Write the two or three most important use cases fully, extensions included. Brief versions are enough for the simple ones.
6. Decide include and extend relationships honestly; prefer a precondition to a doubtful include.

Mistakes that cost marks

Use cases that are screens. "Menu page", "Admin panel" are places, not goals.

Use cases that are steps. "Validate quantity" and "Check stock" have no actor who would call them a goal.

No extensions. A use case with only its happy path has specified the easy half.

Interface details in the steps. A redesign should not make a use case wrong.

Include and extend used as flowchart arrows. They are relationships between goals, not the order in which things happen.

Quick revision

• An actor is a role outside the system: a human, hardware or another system.
• A use case is one goal, yielding an observable result of value to an actor.
• Find them from actors and their goals; one use case per goal; check the level.
• A fully written use case: ID and name, primary actor, goal, preconditions, trigger, main success scenario, extensions numbered after their steps, postconditions, requirements.
• Include: shared behaviour always inserted. Extend: optional behaviour added at a point, under a condition.
• Every functional requirement is realised by some use case, and every use case realises some requirement.

Questions you must be able to answer

1. What is a use case, and how do you tell a use case from a step? A specification of how the system and an actor interact to achieve one of the actor's goals, yielding an observable result of value to that actor. A step, such as checking the stock, is not observable or valuable to the actor on its own; a use case, such as placing an order, ends with a result the actor wanted.

2. What is the main success scenario, and what are extensions? The main success scenario is the numbered sequence of steps when everything goes right. Extensions describe what else can happen at particular steps, alternatives and failures, numbered after the step they replace, such as 4a, together with how the system responds.

3. Distinguish include from extend, with an example. An include inserts shared behaviour that always happens as part of the including use case, used when two or more use cases share steps. An extend adds optional behaviour to another use case at a particular point under a condition; in the worked project, cancelling an order extends viewing one's orders, when the order is still placed.

4. Why did the worked team not draw sign-in as an include? Because signing in is a goal in its own right with its own use case, and it happens before the other goals rather than as a shared fragment inside them. It was written as a precondition of the other use cases instead.

5. What does extension 4d of UC-4 require, and how will it be tested? That when any item has too few portions left, the whole order is refused and nothing is taken from the stock. It is tested by ordering a thali together with more biryani than is left, checking the order is refused, and checking that the thali's stock is unchanged.