6.8 Use Cases, User Stories & Acceptance Criteria Definition
Key Takeaways
Use Cases specify detailed system interactions between Primary/Secondary Actors and the System within defined boundary conditions.
User Stories articulate functional needs from the user's perspective using the standard syntax: 'As a [role], I want [capability], So that [business benefit]'.
The INVEST framework ensures user stories are Independent, Negotiable, Valuable, Estimable, Small, and Testable.
Acceptance Criteria define the explicit boundary conditions for feature completion, commonly structured using Given-When-Then (BDD) syntax.
Use Cases excel in complex, structured systems, whereas User Stories excel in iterative, Agile delivery environments.
6.8 Use Cases, User Stories & Acceptance Criteria Definition
Use Case Architecture
A Use Case describes a set of discrete interactions between an external actor (user or system) and a solution to achieve a specific, valuable goal. Use cases are formal, structured requirements artifacts widely utilized in complex enterprise initiatives.
Core Components of a Fully Dressed Use Case
| Use Case Element | Architectural Standard & Content |
|---|---|
| Use Case Name | Active verb phrase representing the goal (e.g., Withdraw Cash, Submit Claim). |
| Primary Actor | The role or external system initiating the interaction to achieve the goal. |
| Secondary Actors | External systems or roles participating in execution (e.g., Payment Gateway). |
| Pre-conditions | Mandatory state conditions that must be true before the use case can execute. |
| Post-conditions | Guaranteed state conditions that must be true after successful execution. |
| Main Success Scenario | The ideal, error-free sequential path (Happy Path) from trigger to goal completion. |
| Alternate / Exception Flows | Branching paths describing error handling, validation failures, or optional steps. |
Agile User Stories & the INVEST Quality Framework
In Agile and adaptive environments, requirements are frequently expressed as User Stories. A user story is a lightweight requirement artifact designed to initiate conversation between business users and delivery teams.
USER STORY SYNTAX & CONSTRUCT
┌──────────────────────────────────────────────────────────────────────────────────┐
│ "As a [Specific User Role], I want [Capability / Action], So that [Business Value]" │
└──────────────────────────────────────────────────────────────────────────────────┘
The INVEST Framework for User Story Quality
A senior BA evaluates user story quality against the six INVEST criteria:
- I - Independent: User stories should be decoupled so they can be prioritized, developed, and delivered in any order without complex dependencies.
- N - Negotiable: Stories are not rigid contracts; they articulate intent and invite collaborative refinement between product owners and developers.
- V - Valuable: Every story must deliver clear, quantifiable business or user value.
- E - Estimable: Technical teams must understand the story well enough to estimate implementation effort.
- S - Small: Stories must be sized appropriately to fit within a single iteration or sprint (typically 2 to 5 days of work).
- T - Testable: Stories must possess clear acceptance criteria allowing binary pass/fail verification.
Acceptance Criteria: Behavior-Driven Development (BDD) Syntax
Acceptance Criteria define the exact boundary conditions required for a user story or use case to be accepted as "Done". They bridge business intent and quality assurance testing.
Given-When-Then (Gherkin) BDD Structure
- Given: The initial context or baseline state of the system.
- When: The specific action, event, or trigger performed by the actor.
- Then: The expected, testable outcome or state change in the solution.
Example Gherkin Specification:
Scenario: Automated Fraud Flag on High-Value Foreign Transaction
Given a registered credit card holder has an account in "Active" status
And the cardholder's home region is documented as "United States"
When the cardholder attempts a point-of-sale transaction exceeding $2,500 in "France"
Then the payment authorization engine shall place a temporary hold on the transaction
And dispatch an automated SMS alert to the cardholder within 5 seconds.
Use Cases vs. User Stories: Strategic Comparison
| Dimension | Use Cases | User Stories |
|---|---|---|
| Primary Environment | Plan-driven / Waterfall / Complex Enterprise Systems | Adaptive / Agile / Scrum / Kanban |
| Scope & Detail | Comprehensive, capturing main flow and all alternate/exception paths in one document. | Short, focused slices of functionality intended to be expanded during sprint planning. |
| Documentation Focus | Detailed system interaction contract. | Prompt for conversation supported by acceptance criteria. |
| Lifetime | Maintained as permanent living documentation across solution lifecycle. | Transient cards archived upon sprint completion (with acceptance criteria retained). |
Practical Example: E-Commerce Return Management
Consider an e-commerce platform return workflow:
- Use Case Artifact: Specifies Use Case UC-104 Process Product Return, detailing pre-conditions (Order status = Delivered within 30 days), main success scenario (select item, generate shipping label), and exception flow E1 (item non-returnable due to clearance status).
- User Story Decomposition: Decomposes UC-104 into Agile user stories:
- "As a Customer, I want to download a prepaid return shipping label, So that I can return defective items without visiting a store."
- Acceptance Criteria (Gherkin):
- Given a customer is viewing an order delivered 10 days ago,
- When they click "Generate Return Label",
- Then a downloadable PDF shipping label is generated with a unique tracking barcode.
CBAP Exam Strategy & Distractor Analysis
- INVEST Criteria Questions: Exam scenarios often present a user story that cannot be completed within a sprint because it is too large. Identify this as a violation of the S - Small criterion (an "Epic").
- Post-conditions Guarantee: Remember that Use Case post-conditions must be true regardless of whether the main success scenario or an exception flow executed (e.g. audit logs written in both cases).
- User Story Value Clause: Watch out for user stories missing the 'So that...' clause. A story lacking a business benefit violates the V - Valuable principle of INVEST.
A product owner presents a user story during backlog refinement: 'As a customer service rep, I want a complete enterprise analytics dashboard displaying all customer historical touchpoints.' The development team states that this story will take 6 months to implement across 12 systems and cannot be estimated accurately. Which INVEST criterion has been violated?
Independent
Negotiable
Small (and Estimable)
Valuable
In a formal Use Case specification for an automated Teller Machine (ATM), what component defines the mandatory system state conditions that must be validated as true before the ATM can allow a customer to initiate a cash withdrawal?
Pre-conditions
Main Success Scenario
Post-conditions
Alternate Flow E1
A Quality Assurance (QA) engineer is writing automated test scripts for a new mobile banking app feature and structures the test parameters as follows: 'Given an active user on the transfer screen, When they enter $500 and click Submit, Then their account balance shall decrease by $500.' What notation is the QA engineer leveraging?
UML Class Syntax
Given-When-Then (Gherkin BDD) Acceptance Criteria
BPMN Swimlane Rules
CRUD Matrix Parameters
A business analyst is documenting requirements for a complex nuclear power plant control system governed by strict regulatory safety standards. Why might the BA choose detailed Use Cases over lightweight Agile User Stories for this initiative?
Because Use Cases prohibit technical developers from asking questions.
Because Use Cases provide a comprehensive, structured specification of pre-conditions, main success flows, and all alternate/exception failure paths in a permanent artifact.
Because Use Cases do not require acceptance criteria or testing.
Because User Stories are legally banned in engineering software.
Sections you finish are checked off in the contents.