INFOSYS 220 Chap.4 UML Requirements and Use Cases
UML Requirements and Use Cases
Model goals inside a clear boundary
A use case model shows the solution boundary, external actor roles, goal oriented system functions and their relationships. It does not show screen order, process timing or data flow. Actors represent roles outside the solution, not named people or internal devices. A use case should describe a meaningful multi step goal rather than every click.
Include extracts required reusable behaviour; extend adds behaviour while the base use case remains complete.
Complete the picture with scenarios
The diagram gives scope, while the use case document describes trigger, preconditions, interactions and outcomes. A normal flow reaches the goal under expected conditions. An alternative flow takes a conditional successful route.
An exception responds to failure and may end without the goal. Every branch should return to a stated step or end explicitly. User stories offer a concise role, goal and value statement, while INVEST helps test whether a story is workable.
What this chapter covers
- 01
User stories with role, goal and value
- 02
INVEST quality characteristics
- 03
Actors as external roles and the system boundary
- 04
Goal sized use cases and associations
- 05
Include, extend and generalisation relationships
- 06
Normal, alternative and exception scenario flows
Worked example · free
Repair an overloaded use case model
- 2Correct the actors and boundary.
- 2Replace the trivial use case with a goal.
- 2Remove process order from the model.
- 2Name the document that carries flow detail.
Key terms
- User Story
- A concise statement identifying a role, desired goal and reason that goal creates value.
- Actor
- An external role that interacts with the system to pursue or support a goal.
- System Boundary
- The visual scope separating functionality inside the solution from external actors.
- Use Case
- A goal oriented system function containing one or more interaction scenarios.
- Include Relationship
- A dependency in which the base use case requires extracted reusable behaviour.
- Extend Relationship
- A dependency adding behaviour while leaving the base use case complete without it.
- Precondition
- A system state that must already hold before a use case can validly begin.
UML Requirements and Use Cases FAQ
Can an internal database be an actor?
Usually not when it is part of the solution being modelled. Actors sit outside the boundary and interact with the system. A genuinely external information service may be an actor, but internal components belong to design or architecture views rather than the use case model.
What is the difference between alternative and exception flows?
An alternative flow is a conditional route that still pursues or achieves the use case goal. An exception flow responds to a failure and can abandon the goal. Both need explicit conditions and must return to a stated point or end the use case clearly.
When should include be used?
Use include when a base use case depends on a reusable piece of behaviour that has been extracted, often because several goals share it. Do not use the arrow merely to show that one action happens after another; sequence belongs in flow documentation.
How do user stories relate to use cases?
Both centre stakeholder goals, but they operate at different levels of detail. A user story is a concise conversation prompt with role, goal and value. A use case model defines solution scope, and its document explains scenarios, conditions and interactions needed to achieve the goal.
Exam move
Start with a short list of stakeholder goals and draw the system boundary before adding actors. Name actors as roles and use cases as verb plus meaningful goal. Test granularity by asking whether the oval describes a complete reason for interacting with the system; move clicks and field entry into flow steps. For every relationship, write a sentence in plain language.
If that sentence describes time order, remove the relationship and place sequence in the documentation. Choose one use case and write its trigger, preconditions and successful postcondition. Number a normal flow, then add one alternative that returns to a named step and one exception that ends explicitly. Compare the diagram with the document: names, actors and scope must agree.
Convert the same goal into a user story and apply all six INVEST checks. For deliberate error practice, draw one named person, one internal component as an actor, one trivial use case and one sequence arrow, then correct each error and explain why. Finally, shrink the model until it remains legible when inserted into a report.
Revision should alternate notation checks with semantic questions: who wants the goal, why it matters, what lies inside scope and which scenario evidence proves that the documented behaviour is complete.
Working through UML Requirements and Use Cases in INFOSYS 220? Sia is AskSia’s AI Information Technology tutor — ask any INFOSYS 220 UML Requirements and Use Cases question and get a clear, step-by-step explanation grounded in how INFOSYS 220 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.