Stakeholder requirement vs story
Both are often written "As a …, I want …". One is a need the change must meet; the other is a piece of work that delivers part of it.
In short
A stakeholder requirement is a need: it says what a group of people must get from the change, and it binds the whole initiative. A story is work: a slice of change that is built, verified and closed. Many teams use "user story" for both, which is why they get confused.
Side by side
| Stakeholder requirement | Story | |
|---|---|---|
| Kind | A need (authority side) | Work (execution side) |
| Lifetime | Its initiative; then kept as history with its reasons | Days, then Done |
| Changes by | A decision about the need | Being built |
| Proof | Its acceptance criteria are Met | The criteria it covers are Met, and its design changes are applied |
How to tell them apart
- If it states what a group needs, whichever piece of work delivers it, it is a requirement.
- If it will be built, Done and closed, it is a story.
- One requirement is often delivered by several stories, and one story can deliver parts of several requirements.
Example: Clinic Booking
Requirement: "As a patient, I can move my own appointment online."
Stories implementing it: "Move from the e-mail link", "Move from the patient portal", "Show free slots for the next two weeks".
Why the difference matters to an agent
If the need lives only inside a story, it disappears when the story closes, and the next agent session has nothing to check against. Keeping the need as a requirement means every story in the initiative is measured against it, and the stories' design changes leave the solution's design describing what was actually built.