Use Cases / Template

Use Case Document Template

Structure for use case kickoff documents. Written by UV to describe the system being built -- scope, flows, data, constraints, critical path, and deliverables. Fields marked MANDATORY require confirmed information. Fields marked DERIVED can be proposed by UV based on domain experience.

Version UCT-3.1 Date 2026-05-02 Owner Uued Viljapuuaiad Status Active Authority Tier 2

Purpose

This is the structure for a use case document. It is written by us. It describes what we are building, how it works, what it depends on, and what the critical path to delivery looks like.

It is not a questionnaire. It does not ask anyone to fill anything in.

Field Classification

Marker Meaning
[M] MANDATORY -- requires confirmed information from client or domain research. Cannot be invented.
[D] DERIVED -- UV proposes based on experience. Client confirms or corrects.

Section 01 -- Overview [M]

All fields mandatory. This is the identity of the project.

Field Value
Use Case ID UC-XX
Client Reference [M] Client's own project code / PO number / tracking ID
System Name [M]
Domain [M]
One-Line Description [M]
Status [M] Kickoff / In Development / UAT / Production
Target Delivery [M]

Summary [M]

What the system does and why it exists. 2-3 paragraphs. No implementation detail.


Section 02 -- Actors [M]

Roles must come from confirmed understanding of who uses the system.

Role [M] Description [M] Access Level [D] Frequency [D]
What this person does in the business What they can see and do -- UV proposes UV estimates based on role

Section 03 -- User Stories [M/D]

Stories are written by UV based on understood requirements. Priority assigned by UV, confirmed by client.

Grouped by actor. Priority: P1 (must), P2 (should), P3 (could), P4 (won't this phase).

Actor: [Role]

P1 stories must be confirmed. P2-P4 can be proposed by UV.


Section 04 -- System Flows [M/D]

Flow triggers and happy paths are mandatory (confirmed). Exception handling and SLAs can be derived.

One subsection per workflow.

Flow: [Name] [M]

Trigger [M]: What starts this flow.

# Step [M] Actor [M] Input [M] Output [D] Decision [M]
1

Result [M]: End state when flow completes.

Exceptions [D]: What happens on failure, rejection, timeout. UV proposes standard handling.

SLA [D]: Maximum time from trigger to completion. UV proposes based on flow type.

Volume [M]: Expected frequency. Must be confirmed (drives architecture).


Section 05 -- Data Model [M/D]

Entities and their key fields are mandatory. Field types, validation rules, and lifecycle states can be derived from domain patterns.

Entities

Entity [M] Description [M] Key Fields [M] States [D] Relationships [D]
What it represents Unique identifiers UV proposes lifecycle UV infers from entity graph

Business Rules [M/D]

ID Rule [M] Trigger [D] On Violation [D]
BR-01 The rule itself must be confirmed When it fires -- UV proposes Response -- UV proposes

Rules themselves are mandatory (business logic cannot be invented). Implementation triggers and violation responses can be derived.


Section 06 -- Screens [D]

Entire section is derived. UV proposes screen layout based on actors, flows, and data model. Client confirms or adjusts.

Screen [D] Actor [M] Purpose [D] Key Elements [D]
Confirmed from Section 02 UV proposes UV proposes

Wireframes or mockups attached where available.


Section 07 -- Integrations [M]

All integration points are mandatory. Cannot be guessed -- must be confirmed what systems exist and what data moves.

System [M] Direction [M] Data [M] Format [D] Frequency [M] Fallback [D]
In / Out / Both What is exchanged UV proposes (API preferred) Must be confirmed UV proposes retry/queue

Section 08 -- Infrastructure [D]

Entire section is derived unless client has hard constraints. UV proposes stack based on requirements.

Layer Choice [D] Reason [D]
Hosting UV proposes
Database UV proposes
Frontend UV proposes
Runtime UV proposes

Constraints [M]

Hard limits that override UV proposals. Only include confirmed constraints.

If none confirmed, state "No hard constraints confirmed."

Environments [D]

UV proposes standard setup. Client confirms.

Environment Purpose
Development Build and test
UAT Acceptance testing
Production Live

Section 09 -- Critical Path [D]

Derived by UV based on dependency analysis of sections above. Client confirms timeline is acceptable.

# Item [D] Depends On Duration [D] Blocker Risk [D]
1 --
2 #1
3 #2

Parallel Work (off critical path) [D]

Item Can Start After Duration

Milestones [D]

Milestone Reached When Target Date
M1: Core flow operational First end-to-end with real data
M2: UAT ready All P1 stories deployed to UAT
M3: Go-live Sign-off, production deployed

Section 10 -- What Is Needed [M]

Items that must be obtained before work proceeds. All mandatory -- this is the blocker list.

# Item [M] From [M] Blocking [M] Status [M]
1 Yes/No Open / Received

Section 11 -- Acceptance Criteria [M/D]

Definition of Done [D]

UV proposes standard criteria. Client confirms what constitutes acceptance.

Criterion [D] Verified By [D]
All P1 stories implemented UAT pass
Business rules enforced Test per BR-XX
Integrations operational End-to-end with real data
Performance within SLA Load test
Security review Pen test / code review

Success Metrics (30/60/90 days) [M]

Must be confirmed -- these define whether the project succeeded.

Metric [M] Target [M] Measured By [D]

Section 12 -- Risks [D]

UV identifies risks based on analysis. Standard risk management.

# Risk [D] Likelihood [D] Impact [D] Mitigation [D]
R1 H/M/L

Open Questions [M]

Questions that remain unanswered. These are mandatory to document -- unknown unknowns must be surfaced.

# Question [M] Impacts [D] Resolution [M]
Q1 UV explains impact Must be answered

Section 13 -- Cooperator Brief [D]

Entirely derived by UV. This is our internal handoff to the developer.

Field Value
Scope [D] What exactly is being built
Stack [D] Confirmed technology
Timeline [D] Milestones with dates
Dependencies [D] What must exist before work starts
Interfaces [D] What is received and what is delivered
Quality Bar [D] Test coverage, review process, documentation
Handover [D] Artefacts delivered at completion

Classification Summary

Section Classification Notes
01 Overview Mandatory Cannot proceed without this
02 Actors Mandatory Must know who uses it
03 User Stories Mixed P1 mandatory, rest derived
04 System Flows Mixed Triggers/steps mandatory, error handling derived
05 Data Model Mixed Entities mandatory, lifecycle/validation derived
06 Screens Derived UV proposes entirely
07 Integrations Mandatory Must know what connects to what
08 Infrastructure Derived UV proposes unless hard constraints exist
09 Critical Path Derived UV calculates from dependencies
10 What Is Needed Mandatory Blocker list
11 Acceptance Mixed Success metrics mandatory, criteria derived
12 Risks Derived UV identifies from analysis
13 Cooperator Brief Derived Internal UV document

Version History

Version Date Changes
UCT-3.1 2026-05-02 Added [M]/[D] classification to all fields. Classification summary table.
UCT-3.0 2026-05-02 Rewrite: solution description by UV. Critical path. No questionnaire.
UCT-2.0 2026-05-02 Stakeholder questionnaire (deprecated)
UCT-1.0 2026-05-02 Nexus-internal spec (deprecated)