Break a user story down into system requirements, each naming a component, an action, data and a condition, without forgetting what happens on failure.
What a systems analyst does with a story
What a systems analyst does with a story
The BA course (“Business and Systems Analysis from Scratch”) ended the chain with a user story and a functional requirement: what the system does. A systems analyst (SA) goes on: which component does it, with what data, via which interface, and what happens on failure.
The case is Romashka: grocery delivery from partner stores. Our system is the order service; the customer app, payment provider, stores, courier service, notification service and analytics work with it.
A system requirement = component + action + data + condition. Example: the order service (component) requests a refund (action) of the full amount (data) when a paid order is cancelled (condition). Below, the cancellation story is split into five requirements. SR-3 is a failure case: without such requirements the breakdown is incomplete.
The breakdown: 1) participants and systems; 2) the main scenario, step by step; 3) the component and data at each step; 4) failure cases and negative scenarios; 5) each requirement checked against the BA course's quality checklist.
Unlike a story, a system requirement names a component, can be tested and describes neither buttons nor code. An API endpoint contract is later derived from it.
The role boundary: the SA describes requirements, contracts and models. The architect, with the SA's input, chooses technologies and the split into services. The developer writes the code.
The cancellation story → system requirements
Story: “As a customer, I want to cancel an order before it is handed over to the courier, so that I don't pay for something I don't need.”
| № | System requirement | What it describes |
|---|---|---|
| SR-1 | The order service accepts a cancellation if the status is created, paid or assembling | the condition under which the action is allowed |
| SR-2 | When a paid order is cancelled, the order service asks the payment provider to refund the full amount | an action with data |
| SR-3 | In the in_delivery and delivered statuses, the order service rejects the cancellation and reports the current status | a failure case |
| SR-4 | After a cancellation, the order service publishes the OrderCancelled event | a message to other systems |
| SR-5 | The notification service tells the customer about the cancellation within 30 s | an action with a time threshold |
The chain from business to system
- 1Business requirement
Cancellation without a call to support
- 2User story
“I want to cancel my order before the courier picks it up”
- 3System requirement
SR-1: cancellation in created, paid, assembling
- 4API endpoint contract
POST /orders/{orderId}/cancel and its status codes
- 5Implementation in code
The cancellation handler in the order service
SA artifacts and the question each one answers
| Artifact | Question | Where in the course |
|---|---|---|
| System requirements | what each component does and under what condition | this lesson |
| Context diagram | who we exchange data with | lesson 1.3 |
| API contract | which request and which response | units 2–3 |
| Event description | what we report asynchronously, and to whom | unit 4 |
| Sequence diagram | in what order the calls happen | lesson 5.1 |
| State diagram | which statuses an object goes through | lesson 5.2 |
| Data model | what we store and how it is linked | lesson 5.3 |
Lesson notes
What a systems analyst does with a story
The BA course (“Business and Systems Analysis from Scratch”) ended the chain with a user story and a functional requirement: what the system does. A systems analyst (SA) goes on: which component does it, with what data, via which interface, and what happens on failure.
The case is Romashka: grocery delivery from partner stores. Our system is the order service; the customer app, payment provider, stores, courier service, notification service and analytics work with it.
A system requirement = component + action + data + condition. Example: the order service (component) requests a refund (action) of the full amount (data) when a paid order is cancelled (condition). Below, the cancellation story is split into five requirements. SR-3 is a failure case: without such requirements the breakdown is incomplete.
The breakdown: 1) participants and systems; 2) the main scenario, step by step; 3) the component and data at each step; 4) failure cases and negative scenarios; 5) each requirement checked against the BA course's quality checklist.
Unlike a story, a system requirement names a component, can be tested and describes neither buttons nor code. An API endpoint contract is later derived from it.
The role boundary: the SA describes requirements, contracts and models. The architect, with the SA's input, chooses technologies and the split into services. The developer writes the code.