Stakeholder requirement vs story
Both are often written "As a …, I want …". One is a need that stays true; the other is a piece of work that ends.
In short
A stakeholder requirement is a need: it stays true for as long as the product exists. 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 | As long as the product | Days, then Done |
| Changes by | A decision about the need | Being built |
| Proof | Its acceptance criteria are Met | The criteria it covers are Met |
How to tell them apart
- If it will still be true after the work is done, it is a requirement.
- If it will be 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 later change is still measured against it.