Catalog
method#Software engineering#Product#Architecture#Delivery

Use Case Modeling

A structured method for describing functional requirements from the user perspective. Captures actors, goals and interaction steps in concrete scenarios to support analysis, prioritization and testable derivation.

Use Case Modeling is a structured method for identifying and modeling functional requirements from the user's perspective.
Established
Medium

Classification

  • Medium
  • Organizational
  • Design
  • Intermediate

Technical context

UML modeling tools (e.g. Enterprise Architect)Issue tracking systems (e.g. Jira) to link requirementsDocumentation platforms (e.g. Confluence) for collaboration

Principles & goals

Describe behavior from the user's perspective, not the implementation.Separate primary scenarios clearly from alternative and error paths.Use iterative refinement in alignment with stakeholders.
Discovery
Domain, Team

Use cases & scenarios

Compromises

  • Outdated use cases lead to wrong assumptions in development.
  • Excessive formality blocks rapid feedback.
  • Unclear actor identification can obscure responsibilities.
  • Focus on core scenarios and document alternatives concisely.
  • Use simple, predictable role names for actors.
  • Link use cases to acceptance criteria and tests early.

I/O & resources

  • Product vision or business goals
  • Stakeholder interviews and user stories
  • Existing process or system documentation
  • Documented use cases with primary and alternative scenarios
  • Derivation of acceptance criteria and test cases
  • Prioritized implementation packages and open questions

Description

Use Case Modeling is a structured method for identifying and modeling functional requirements from the user's perspective. It captures actors, goals and stepwise interactions in concrete scenarios and links business expectations to technical tests. The approach supports shared understanding, prioritization and derivation of implementation tasks.

✔

  • Increases shared understanding between business and engineering.
  • Enables clear derivation of acceptance criteria and tests.
  • Helps prioritization by focusing on user goals.

✖

  • Focuses on functional requirements, not on non-functional aspects.
  • Can become unwieldy if documented at excessive detail.
  • Requires active stakeholder involvement for valid results.

  • Use-case coverage

    Share of identified user needs covered by use cases.

  • Testable acceptance criteria per use case

    Number of clearly formulated, verifiable acceptance criteria per use case.

  • Time to validation

    Average time between drafting a use case and stakeholder validation.

E-commerce checkout

Use cases describe the sequence from cart to payment including exceptions like payment failures.

Support ticket workflow

Scenarios model ticket creation, prioritization and escalation paths.

Bank transfer

Use cases define permissions, confirmation mechanisms and error handling for transfers.

1

Preparation: identify stakeholders and clarify goals.

2

Elicitation: run workshops, capture actors and primary scenarios.

3

Modeling: document primary and alternative paths.

4

Validation: review and adapt use cases with stakeholders.

5

Derivation: derive acceptance criteria, tests and implementation bundles.

⚠️ Technical debt & bottlenecks

  • Incomplete or inconsistent use-case archives hinder maintenance.
  • Outdated models without traceability to implementations.
  • Lack of standardization leads to divergent modeling styles.
Unclear stakeholder availabilityExcessive documentation effortInconsistent modeling conventions
  • Replacing user interviews with mere documentation of typical flows.
  • Using use cases to prescribe technical implementation details.
  • Assuming a single use case covers all user scenarios.
  • Confusing actor with system component.
  • Neglecting error and exception paths.
  • Involving end users too late in validation steps.
Requirements analysis and facilitationBasic knowledge of UML or structured notationsAbility to communicate with stakeholders
Clarity of requirements relative to the architectureTestability and derivation of acceptance criteriaTraceability of user goals and responsibilities
  • • Time constraints for workshops
  • • Limited access to technical details for business stakeholders
  • • Tool or notation constraints (e.g. UML version)