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?
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?
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?
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?