Use Cases vs User Stories for Complex Regulated Systems

The user story has become the default requirements artefact in most modern delivery, to the point where teams rarely ask whether it is the right artefact. In regulated, complex, multi-actor systems, the answer is often that it is not, or at least not on its own. The use case, a more structured artefact that predates the agile movement, does work in this setting that user stories do not do naturally. The two can coexist, and the teams that deliver best in regulated scope usually do coexist them.

This post covers the differences that matter, the specific scenarios where use cases outperform user stories, the scenarios where user stories are the better choice, and the hybrid patterns that work. It draws on programmes in capital markets, payments, claims, and customer onboarding, where the multi-actor complexity pushes back on the single-persona framing of user stories.

The essential difference

A user story is a promise for a conversation. It captures user value in a thin format: "as a role, I want something, so that I get a benefit". Its deliberate thinness forces collaboration to fill in the detail. For simple, single-actor, single-outcome functionality, this is ideal.

A use case is a structured description of a goal achieved by an actor interacting with a system through a specified sequence of steps, with alternative and exception flows documented. Its structure makes it useful for complex, multi-actor, multi-branch functionality where the story format cannot carry the load without collapsing into a de facto use case dressed as a story.

The difference is not aesthetic. It is fit-for-purpose.

Where user stories work

User stories work when:

• The functionality is simple and can be described in one or two sentences
• There is one primary actor
• There are few alternative flows
• The acceptance criteria can be expressed compactly
• The team can have productive refinement conversations to fill in detail
• The audit trail for the story is manageable within the story template

For most feature development in most systems, this is true. Teams should default to user stories in these cases, as covered in our post on writing user stories for regulated industries.

Where use cases work

Use cases work when:

• The functionality involves multiple actors with distinct interactions
• There are significant alternative or exception flows
• The sequence of interactions matters for correctness
• The regulatory requirement is specified at the use case level (for example, a complete process that must be performed in a specific way)
• The audit trail requires explicit enumeration of the main and alternative paths
• The functionality spans multiple systems or interfaces where the orchestration logic is the point

A trade capture process with multiple actors (trader, middle office, risk, compliance), multiple systems (OMS, risk engine, compliance monitoring), and regulatory overlays (MIFID II, MAR) is better described as a use case than as a string of related user stories.

Structural anatomy of a use case

A good use case has a consistent structure. The specific template varies by firm, but the core elements are:

Name and identifier

A stable reference. Use case names are often expressed as verb-noun: "Capture a customer order", "Approve a high-value payment", "Settle a corporate action".

Primary and secondary actors

The primary actor is who initiates or benefits from the use case. Secondary actors are who else participates. For regulated use cases, the secondary actors often include the regulator (by way of mandatory notifications or reports) and automated systems that execute controls.

Preconditions

What must be true before the use case can start. For a payment authorisation use case: the payer's account is active, the payee is a validated beneficiary, the payment channel is operational.

Postconditions

What will be true after the use case completes successfully. For the same example: the payment is in the authorised status, the payer's available balance is reduced by the payment amount plus fees, the audit log contains the authorisation event.

Main success flow

The happy path. Step-by-step. "1. The customer initiates a payment. 2. The system validates the payee. 3. The system performs SCA. 4. The SCA provider confirms outcome. 5. ..." Each step is short, unambiguous, and specifies which actor acts.

Alternative flows

The acceptable variations on the main flow. "Alternative: customer has saved payee. In which case step 2 is skipped." Alternative flows are where much of the real behaviour lives.

Exception flows

The error conditions and their handling. "Exception at step 3: SCA times out. In which case the system retries once, and if the retry times out, the payment is held for customer re-authentication within 10 minutes." Exception flows are the difference between a robust system and a fragile one, and regulators often ask about them specifically.

Non-functional considerations

References to the NFRs that apply: latency, resilience, security, retention. The use case itself is functional, but it calls out the NFR properties that are load-bearing for the flow.

Business rules referenced

The business rules that govern the decisions within the flow. The use case does not embed the rules; it references them by identifier, so that rule changes propagate automatically.

Worked example: authorise a high-value customer payment

Use Case ID: UC-PAY-HV-001

Name: Authorise a high-value customer payment

Primary actor: Retail customer

Secondary actors: SCA provider, fraud engine, sanctions engine, payment rail, central operations (for manual referral)

Preconditions: Payer's account is active, has sufficient available funds or agreed overdraft, payee is a validated beneficiary or a new payee undergoing validation.

Postconditions: Payment is in the authorised status, funds are earmarked, customer has received confirmation, audit log is updated.

Main success flow:

1. Customer initiates a payment above the high-value threshold (25,000 GBP)
2. System validates account status and available balance
3. System invokes fraud engine for risk scoring
4. System invokes sanctions engine for payee screening
5. System invokes SCA provider for strong customer authentication
6. Customer completes SCA successfully
7. System records authorisation, earmarks funds, and returns confirmation to customer

Alternative flow A (saved payee, no sanctions concern): step 4 is skipped if the payee has been validated within the last 30 days with a clean sanctions outcome.

Alternative flow B (customer on a supported journey): if the customer has a vulnerability flag, step 6 is preceded by a confirmation of understanding prompt and a cooling-off period of 15 minutes is applied before step 7.

Exception flow X1 (fraud score above threshold): at step 3, if fraud score is above threshold, the payment is held, customer is notified, and a fraud case is created with review SLA of 4 hours.

Exception flow X2 (sanctions near-match): at step 4, if the sanctions engine returns a possible match, the payment is held pending compliance review with review SLA of 2 business hours.

Exception flow X3 (SCA failure): at step 6, if SCA fails twice, the payment is cancelled, customer is notified, and the session is terminated per PSD3 SCA requirements.

Exception flow X4 (system unavailable): if any of the underlying services is unavailable, the payment is held in a deferred status for up to 60 minutes, after which it is cancelled with customer notification.

Non-functional considerations: NFR-LAT-005 (total flow latency below 15 seconds p95 excluding customer SCA response time); NFR-AVL-002 (availability 99.95 percent during operating hours); NFR-SEC-003 (SCA per PSD3 RTS); NFR-RET-001 (audit log retention 7 years).

Business rules referenced: R-FRAUD-001, R-SANC-001, R-SCA-002, R-VULN-003.

The use case is a full specification of the flow. It is testable (each flow and exception has an explicit path). It is auditable (regulators can ask about any specific flow). It is reviewable (the structure makes gaps visible).

The hybrid pattern that works

The best regulated delivery teams we see use a hybrid. Use cases at the higher level for complex processes. User stories under each use case to deliver incremental functionality.

The use case defines the flows, the actors, the business rules, the exceptions. The user stories deliver specific increments: "deliver the main success flow steps 1 to 3", "deliver alternative flow A", "deliver exception flow X2".

Each story references the use case it contributes to, and the test cases for the story align with the use case flow it implements. The audit trail runs from regulatory obligation to use case to story to test to evidence.

Common failure modes

Failure: stories for processes that are use cases

Complex multi-actor processes are decomposed into 40 user stories. The stories individually make sense but collectively do not describe the process. The test cases are written per story and miss the inter-story interactions. Fix: recognise the process as a use case, document it as a use case, and let the stories be the delivery increments.

Failure: use cases for everything

Every feature, no matter how simple, is written as a use case. The overhead swamps the team, refinement slows, delivery cadence drops. Fix: use case or story by fit-for-purpose, not by convention. Reserve use cases for functionality where the complexity genuinely needs the structure.

Failure: unlinked use cases and stories

Use cases exist. Stories exist. The connection between them is implicit. When a use case flow changes, the affected stories are found by search rather than by reference. Fix: every story references the use case it contributes to, and every use case has a list of the stories that implement it.

Failure: the use case as narrative

The use case is written as prose rather than as structured flows. It reads well but is hard to test and hard to review for gaps. Fix: the structural discipline is non-negotiable. Main flow as numbered steps, alternative and exception flows as explicit deviations.

Failure: use cases without business rules

The use case embeds business rules in the step descriptions. When a rule changes, multiple use cases need to be updated. Fix: rules live in the rules catalogue. Use cases reference them by identifier.

External references

The OMG UML specification includes use case modelling as a core technique. Alistair Cockburn's "Writing Effective Use Cases" remains the canonical practitioner reference. The IIBA BABOK guide covers both use cases and user stories within the broader requirements discipline.

The short version

User stories and use cases are both valid requirements artefacts. They fit different purposes. User stories work for simple, single-actor increments. Use cases work for complex, multi-actor processes with significant alternative and exception flows. In regulated scope, complex processes are the norm rather than the exception, and use cases earn their keep.

The hybrid pattern, use cases at the process level and stories as delivery increments under them, is the most common answer in practice. It preserves the agile cadence for delivery while providing the structural rigour regulators expect for the processes themselves.

Our business analysis service supports teams in applying the right artefact for the right scope. For the story-side of the discipline, see writing user stories for regulated industries. For the upstream artefacts that use cases reference, see BRD vs FRD in regulated change.