Creating and Managing Use Cases¶
Glossary¶
Use Case A structured description of how a user interacts with a system to achieve a specific goal.
Actor Any user or external system that interacts with the system.
Exception Flow / Alternate Flow Steps describing what happens when something unusual or unexpected occurs during a use case.
Success Scenario / Main Success Path The "ideal" sequence of steps when everything works as expected.
BPML (Business Process Modeling Language) A notation for describing business processes or workflows.
UML (Unified Modeling Language) A standardized visual modeling language used to describe software systems (e.g., activity diagrams, sequence diagrams).
Mock-up A static or simplified visual representation of part of the system's interface.
Use cases are one of the most practical tools in requirements engineering. They describe how users interact with a system to achieve a goal. Think of them as stories of use: “A student uploads an assignment,” “A tutor reviews and grades it,” “A team member comments on feedback.” Each use case captures what happens step by step.
But not all use cases are good ones. To be useful, they must meet quality criteria and be supported by other techniques.
What Makes a Good Use Case?¶
A high-quality use case should be:
| Criterion | Simple definition | Example in one running project idea |
|---|---|---|
| Adequate | It describes a real, agreed requirement. | “The system shall let students upload their assignment as a PDF before the deadline.” |
| Understandable | The target audience can easily understand it. | Students, tutors, and developers all understand what “upload a PDF before the deadline” means. |
| Complete | It is understandable on its own; key information is not missing. | “The system shall let students upload one PDF file up to 20 MB before the deadline shown on the course page.” |
| Verifiable | We can clearly decide whether it is fulfilled. | Test: try uploading a 15 MB PDF before the deadline → accepted; try 25 MB → rejected. |
| Consistent | It does not conflict with other requirements. | One requirement says “PDF upload is allowed,” and no other requirement says “only ZIP upload is allowed.” |
| Non-redundant | The same requirement is written only once, without overlap. | The PDF upload rule appears in one place, not repeated differently in three sections. |
| Modifiable | It can be changed without damaging the document. | If the file limit changes from 20 MB to 30 MB, we update one atomic requirement, not many scattered sentences. |
| Conformant | It follows the required format and structure. | The requirement is written in the agreed template, numbered properly, and placed in the correct section. |
Tip
When you write a use case, imagine another student taking over your project tomorrow. Would they understand it clearly, without guessing?
Scenarios vs. Use Cases¶
- A scenario is a single story (e.g., “Student uploads assignment but Wi-Fi breaks”).
- A use case bundles all related scenarios together (successful path + exceptions).
Example
Use case: Submit Assignment Scenarios: normal submission, late submission, failed upload, resubmission after error.
Beyond Use Case Diagrams¶
Use case diagrams are handy for showing the big picture (actors and their goals), but they are not enough. You also need structured steps written out:
- for Actor action
- for System response
- for Alternate/exception flow
This structure prevents vague or ambiguous requirements.
You do not have to use text only to describe steps. You can also use tables, BPML, or UML (Unified Modeling Language) activity/sequence diagrams.
Fight against Ambiguity¶
- A glossary ensures everyone uses the same terms. “Assignment,” “submission,” “feedback,” and “grade” should mean exactly the same to all team members.
- Prototypes (mock-ups, sketches, clickable demos) help visualize use cases and clarify steps that words alone cannot.
Danger
Ambiguity will raise eventually, your team have to consciously fight against it. Keep it in your mind when writing and reviewing use cases.
Tip
Avoid vague terms like “quickly,” “easily,” or “intuitively.” Instead, specify measurable criteria: “within 2 minutes,” “with no more than 3 clicks,” or “without prior training.” Some of those disguise themselves as technical terms, like "data" (in SE anything could be data), "information" (same), "system" (not the same for the end user and for the developer), "process" (as something running on your computer or a sequence of actions in real life supported by your tool?), etc. Be specific about what you mean.
The Twin Peaks Paradigm¶
Requirements and design evolve together. You don’t finish all use cases and then start designing. Instead, you iterate between the two: rough use cases guide early prototypes, which in turn refine use cases.
Info
This is called the twin peaks model: requirements peak on one side, design on the other. They grow in detail together, step by step.
Danger
Your use cases will evolve, but you have to be able to present them to the users. Ultimately, they will decide if it is useful or not. But if they are too vague, they will not be able to give you useful feedback.
Focus on the Problem, Not the Tech¶
Always capture the user’s real problem, not the “coolest” technical solution. A student may need to “share feedback quickly,” but whether that’s done via a web app, chatbot, or AI summary is a design choice—not a requirement.
Danger
If you rush to solutions too early, you risk building the wrong thing very efficiently.
Practical Steps¶
- Identify actors and goals.
- Write the main success scenario in steps.
- Add alternate and exception flows.
- Check quality criteria (consistent, complete, modifiable, conformant).
- Link terms to the glossary.
- Use prototypes to validate with stakeholders.
- Iterate with design (twin peaks).
Use cases are living documents. They are not just drawings for a report but working tools that help your team and your customers stay aligned on what the system should do.