Stakeholder requirement
What a specific group of people needs, in their own terms, usually written as a user story.
What it is
A stakeholder requirement names a group — patients, receptionists, clinic managers — and what they need to do or achieve. It is often written as "As a …, I want …, so that …".
Why it matters
Different people need different things from the same system, and some needs conflict. Writing them per group makes the differences visible early, when they are cheap to resolve, and keeps the voice of the people who will actually use the software in the project.
What goes wrong without it
- The system serves the people who spoke up in meetings and ignores the ones who did not.
- Conflicting needs (patients want flexibility, receptionists want predictability) surface only in production.
- Usability problems appear late, because nobody wrote down what each group was trying to do.
What it gives an AI agent
An agent that knows who a feature is for writes different code for a receptionist on a desktop all day than for a patient on a phone once a month. Stakeholder requirements give it that context in a form it can quote back.
Example: Clinic Booking
| Weak | Strong |
|---|---|
| Appointments can be changed. | As a patient, I can move my own appointment online, so that I do not have to call the clinic. |
How it relates to the rest
- Refines a business requirement.
- Is refined by functional and non-functional requirements.
- Stories usually implement stakeholder or functional requirements.
In Corpole
- Type Stakeholder Requirement (SR), in the Requirements group.
- Needs at least one acceptance criterion before Approved or Authority.
- Linked upwards with refines to a business requirement.