Skip to content

Creating and Managing Use Cases

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:

  • Consistent – the same terms, style, and structure throughout.
  • Non-redundant – no duplicate cases that confuse the reader.
  • Complete – no undefined actors or missing scenarios.
  • Modifiable – easy to update when requirements change.
  • Conformant – matches agreed standards and templates.

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:

  1. for Actor action
  2. for System response
  3. 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

  1. Identify actors and goals.
  2. Write the main success scenario in steps.
  3. Add alternate and exception flows.
  4. Check quality criteria (consistent, complete, modifiable, conformant).
  5. Link terms to the glossary.
  6. Use prototypes to validate with stakeholders.
  7. 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.