QUICK ANSWER
What should a use case template include?
A use case template should capture one primary actor goal inside a named system boundary, plus supporting actors, stakeholder interests, preconditions, trigger, minimum and success guarantees, a numbered actor-system main scenario, and step-anchored extensions that resume explicitly or end. Link business rules and requirement IDs, but keep backlog stories, system-wide requirements, screen flows, workflow states, and acceptance evidence in their own records.
A written use case makes one actor goal reviewable across the boundary between a person or external system and the system being specified. It explains the successful interaction, the conditions that can divert it, and what must remain true when the goal is not completed.
This original pack provides four fictional equipment-lending examples, a blank Markdown record, closed JSON Schema, generated CSV and Mermaid review views, a dependency-free validator, thirteen tests, and deterministic ZIP bytes. It keeps the interaction narrative connected to neighboring planning records without pretending they are interchangeable.
Build one interaction contract without absorbing its neighbors
Start with the actor goal, then add only the behavior needed to make every material success and failure path reviewable. Stable IDs let the use case point to other owner records without copying their full contents.
Name one system boundary and one actor goal
Describe the result one primary actor wants from the named system. Keep organization-wide process, solution architecture, page hierarchy, and unrelated goals outside the record. If two goals can finish independently, give them separate use case identities.
Sources: [ivar-use-case-foundation], [figma-use-case], [use-case-pack]
Identify actors, interests, conditions, and guarantees
Name the primary actor that initiates the interaction, supporting actors the system calls, stakeholder interests, preconditions, and trigger. Write minimum guarantees for every exit and success guarantees for the completed goal before describing the happy path.
Sources: [figma-use-case], [ivar-use-case-foundation], [use-case-pack]
Write the main success scenario as actor-system turns
Give every main step a stable ID and order. State who acts, what the actor or system does, and the observable response. Describe required behavior rather than interface controls, database operations, framework choices, or test fixtures.
Sources: [ivar-use-case-foundation], [use-case-pack]
Anchor alternate and exception flows to exact steps
Attach each condition to the main step where it can occur. Record the extension steps, then end with exactly one known resume step or explicit terminal outcome. This prevents an error paragraph from becoming an unreviewable dead end.
Sources: [figma-use-case], [use-case-pack]
Link rules and requirements, then hand off detailed work
Reference the governing business rules and requirement IDs. Send backlog decomposition to the user story template, system-wide contracts to the software requirements specification template, durable states to the workflow examples, screen paths to the user flow template, and criterion-level outcomes to the acceptance criteria template.
Sources: [use-case-pack]
The written use case owner boundary
Use this owner when the unresolved question is how an outside actor and the specified system interact to achieve one goal across successful and alternate scenarios.
Included
- One named system boundary, one stable use case identity, one primary actor, and one actor goal
- Supporting actors, stakeholder interests, preconditions, trigger, minimum guarantees, and success guarantees
- Numbered actor-system main scenario steps with observable responses
- Alternate and exception flows anchored to exact main steps with explicit resume or terminal outcomes
- Business-rule and requirement references, special requirements, owner role, status, and review date
- Blank Markdown, completed fictional JSON, closed JSON Schema, generated CSV and Mermaid review views, validator, tests, and deterministic ZIP
Not included
- Backlog-sized actor, need, value, dependencies, risks, estimates, ready or done boundaries, and story decomposition
- System-wide functional, nonfunctional, interface, constraint, assumption, source, and acceptance traceability
- Durable record lifecycle states, transition guards, server authority, provider side effects, retries, audit, and operational recovery
- Interface screens, visible UI states, navigation, page hierarchy, wireframes, and task-path design
- Criterion-level outcome rules, Given/When/Then examples, test fixtures, test runs, evidence verdicts, UAT signoff, and release approval
- UML notation certification, native diagram files, whiteboard collaboration, or a gallery of use case diagrams
- Business-case ROI, funding, option appraisal, procurement, or executive approval documents
DOWNLOADABLE RESOURCE
Download the use case template pack
Use Markdown for drafting, JSON as the controlled source, CSV for scenario review, and Mermaid for a compact actor-to-goal overview. The fictional equipment-lending cases demonstrate interaction structure without prescribing real lending policy.
Use case template pack
A requirements-level actor-system interaction pack with stable goals, conditions, guarantees, main scenarios, anchored extensions, and rule and requirement traceability.
Format: ZIP with Markdown, JSON, JSON Schema, CSV, Mermaid, JavaScript validator, tests, and deterministic builder
Locally reproduced August 1, 2026. SHA-256: 49f1853a60b97756306777f4698fe6de0e5e174303ba2c593afb495c2fac8bb9
Included
- Blank Markdown use case record with ownership and handoff boundaries
- Four completed fictional equipment-lending use cases in a closed JSON model
- Draft 2020-12 JSON Schema for closed pack, actor, reference, scenario, and extension shapes
- Generated CSV ledger for every main and extension step
- Generated Mermaid actor-to-goal overview that does not claim UML conformance
- Dependency-free validator, thirteen tests, package scripts, and fixed-byte ZIP builder
Verification boundary
Local checks passed for exact object keys, stable unique IDs, known actor, system, rule, and requirement references, one primary actor, contiguous step order, actor-system interaction, preconditions, trigger, minimum and success guarantees, anchored extensions, exactly one resume or terminal result, forward resume paths, fictional-data safety, closed schema definitions, generated CSV and Mermaid parity, exact archive contents, and repeatable ZIP bytes. Public availability and any adapted policy remain separate gates.
Four use case examples with different interaction risks
Each example describes one actor goal and the system responses needed to keep success, conflict, failure, and handoff behavior reviewable. The records stop before interface design, operational workflow control, and test execution.
Request an equipment loan
Use when: An outside actor asks the system to create one new request from current eligibility and availability facts.
The primary actor selects an item and period; the system checks current inventory and lending limits, then records one stable pending request or ends without mutation.
Structure
- Member goal, inventory and coordinator support, preconditions, trigger, and guarantees
- Five actor-system main steps from request intent to stable pending identity
- Unavailable-item terminal extension and adjusted-period extension that resumes at recording
Watch for: The example does not define catalog screens, physical safety policy, coordinator state transitions, executable tests, or approval authority.
Sources: [figma-use-case], [ivar-use-case-foundation], [use-case-pack]
Review an equipment request
Use when: An authorized actor makes one version-sensitive decision and a communication attempt follows separately.
The coordinator reviews current request and inventory versions, records approve or decline, and keeps version conflict and notification failure from silently changing the decision.
Structure
- Coordinator goal, request-version precondition, minimum guarantee, and decision guarantee
- Version-conflict terminal path that preserves current and reviewed versions
- Notification-failure terminal path that keeps delivery recovery separate from the recorded decision
Watch for: A written decision use case does not replace authorization testing, the durable request lifecycle, delivery monitoring, or business acceptance.
Sources: [ivar-use-case-foundation], [use-case-pack]
Record an equipment return
Use when: An authorized actor records one real-world handoff without claiming a separate inspection or maintenance result.
The coordinator identifies an active loan, confirms the handoff, and the system records one stable return or returns an explicit mismatch or duplicate result.
Structure
- Active-loan precondition and minimum no-mutation guarantee
- Identity mismatch and duplicate-return terminal extensions
- Explicit boundary between software recording and later physical inspection
Watch for: The example must not be adapted to imply that return recording proves equipment condition, safety, availability, or inventory accounting.
Sources: [figma-use-case], [use-case-pack]
Export member loan history
Use when: A person asks for a bounded data result whose authorization, generation, and notification outcomes must remain distinct.
The member confirms an allowed period, the system generates a member-scoped export, and invalid-period or generation-failure paths avoid cross-member or partial-file disclosure.
Structure
- Member-scoped precondition, privacy minimum guarantee, and stable export guarantee
- Invalid-period extension that resumes only after an explicit narrower boundary
- Generation-failure terminal extension with no retrievable partial file
Watch for: The example does not establish retention, privacy approval, secure-delivery policy, report interface design, or production monitoring.
Sources: [figma-use-case], [ivar-use-case-foundation], [use-case-pack]
Choose the neighboring record when the question changes
A use case should remain one actor-goal interaction contract. Use these stop rules before a useful narrative becomes an overloaded product, design, process, or test document.
The question is what one backlog item delivers and why it matters
Choose: Use a user story for actor, context, need, value, implementation boundary, dependencies, risks, and ready or done references. Link it to the reviewed use case steps.
Tradeoff: The backlog keeps smaller work identities while the cross-step actor goal remains stable and reviewable.
The question spans all system behavior, quality targets, interfaces, and constraints
Choose: Use the software requirements specification owner and reference relevant use case IDs from its functional requirements and acceptance records.
Tradeoff: Traceability requires two records, but one scenario no longer pretends to specify the whole system.
The question is how a durable record changes state across teams or providers
Choose: Use a workflow state table for authoritative states, guards, retries, side effects, audit, timeout, and recovery. Reference the use case as interaction context.
Tradeoff: The actor narrative stays readable while operational authority and failure recovery remain executable.
The question is what one person sees and does through interface states
Choose: Use a user flow for entries, screens, visible states, decisions, errors, recovery, success, and safe exits. Reference use case steps instead of copying system behavior into screen nodes.
Tradeoff: Interaction requirements and interface design can change at different speeds without silently redefining each other.
The question is the observable rule that accepts one requirement or story
Choose: Use an acceptance criterion with stable parent reference, context, event, outcomes, boundary category, evidence requirement, and reviewer role.
Tradeoff: The use case remains a multi-step goal narrative while criterion-level behavior can be tested and reviewed independently.
The search job is a UML diagram, editable canvas, or template gallery
Choose: Use a dedicated use case diagram resource or modeling tool. Keep this written template as the narrative source and treat its Mermaid file only as a generated overview.
Tradeoff: Teams maintain a written interaction contract and a visual map, but neither artifact claims the other format is complete.
START WITH THE RECORD
Download the use case pack and adapt one actor goal
Replace every fictional actor, condition, guarantee, rule, requirement, and outcome with reviewed project evidence. Keep the neighboring owner records linked by stable ID.
Download the use case packThe pack validates structure and generated-file parity. It does not approve requirements or prove implementation.
Open the system-wide SRS templateUse the SRS owner when the requirement set spans behavior, quality, interfaces, constraints, and acceptance traceability.
What the use case template cannot prove
A structurally valid narrative makes missing actors, guarantees, steps, extensions, and references easier to see. It cannot decide whether the underlying product or policy is correct.
- The four equipment-lending examples are fictional planning records, not customer specifications, implementation proof, or recommended lending policy.
- Structural checks cannot prove requirement value, completeness, feasibility, usability, accessibility, security, privacy, legal review, or compliance.
- An actor-system scenario does not prove interface behavior, durable workflow correctness, provider delivery, or production recovery.
- Rule and requirement IDs establish reference integrity only; they do not establish approval, current evidence, or reciprocal coverage in another repository.
- The generated Mermaid file is a compact review view, not native UML, a diagram editor artifact, or proof of modeling-tool compatibility.
- The ZIP is verified locally but not publicly available until an authorized environment serves the exact bytes with the correct content type.
- This informational article does not claim a native use-case generator or grant AI signup credits.
Sources and verification record
Current public guidance supports the actor, system, goal, condition, main-flow, alternate-flow, and neighboring-artifact vocabulary. The exact fields, examples, validator, generated views, and packaging are original Playcode editorial work.
[use-case-pack] Playcode:Completed fictional use case examples
Checked August 1, 2026. Supports: The four fictional use cases, actor and rule registries, twenty main steps, eight extensions, nine extension steps, traceability fields, generated views, and structural checks described in this guide. Public availability remains unverified until deployment.
[ivar-use-case-foundation] Ivar Jacobson International:Use-Case Foundation
Checked August 1, 2026. Supports: Defining a use case as the ways a system is used to achieve one user goal, with the initiating primary actor, supporting actors, a basic scenario, and extensions. It does not prescribe this pack or validate an adapted record.
[figma-use-case] Figma:What Is a Use Case? How to Write One, Examples and Template
Checked August 1, 2026. Supports: The actor, system, goal, stakeholder, primary actor, precondition, trigger, basic-flow, alternate-flow, scenario, user-story, and test-case distinctions used in the editorial explanation. It does not prescribe this artifact or prove implementation.
Use case template questions
What is the standard format for a use case?
A practical written format includes a stable ID and title, system boundary, user-goal level, primary and supporting actors, stakeholder interests, preconditions, trigger, minimum and success guarantees, numbered main scenario, step-anchored extensions, special requirements, business-rule and requirement references, owner, status, and review date.
What is the difference between a use case and a user story?
A use case describes the actor-system interactions and alternate scenarios needed to achieve one goal. A user story turns approved intent into one bounded backlog item with actor, context, need, value, dependencies, risks, acceptance examples, and ready or done boundaries. Link their stable IDs instead of copying one into the other.
What is the difference between a use case and an SRS?
A use case owns one actor-goal interaction across main and alternate scenarios. A software requirements specification owns the broader system contract: functional and nonfunctional requirements, interfaces, constraints, assumptions, sources, dependencies, and acceptance traceability. An SRS can reference several use cases without becoming one long scenario.
What is the difference between a use case and a user flow?
A use case describes required behavior between an actor and system without choosing screens. A user flow maps what one person sees and does through interface screens and visible states. A user flow may implement one part of a use case, while the use case can include non-visual system and supporting-actor behavior.
What is the difference between a use case and a workflow?
A use case follows one actor goal across system interactions. A workflow controls how a durable record moves through authoritative states, roles, guards, side effects, retries, timeouts, audits, and recovery. Use both when an actor goal starts or observes only part of a longer operational process.
Are use cases the same as acceptance criteria or test cases?
No. A use case is a multi-step interaction narrative. Acceptance criteria state observable rules for one reviewed parent requirement or story. Test cases add fixtures, executable steps, actual results, verdicts, and defects. Use case extensions can suggest important boundaries, but they do not prove those boundaries were tested or accepted.
Does a written use case need a UML diagram?
No. A written use case can stand alone when actors, goal, conditions, guarantees, scenarios, extensions, and references are clear. A diagram can help show the actor-to-goal context, but it should link to the written source. This pack includes a generated Mermaid overview and does not claim native UML conformance.
TURN THE REVIEWED CASE INTO SOFTWARE
Give Playcode the bounded actor-system interaction
Describe the reviewed actors, rules, main scenario, exception outcomes, data boundaries, and tests in plain language. Build the smallest coherent web-app slice, then verify the actual target before expanding it.
Start BuildingA use case is a planning input. Product priority, provider setup, policy review, real-user evidence, and production approval remain separate.