Business requirement
What the organisation must be able to do to reach an objective, stated without saying how the system does it.
What it is
A business requirement describes a capability the business needs: take bookings outside opening hours, keep one record per customer, report revenue by clinic. It says nothing about screens, databases or code.
Why it matters
Business requirements keep the solution honest. They let a team propose different solutions to the same need and choose the best one, instead of arguing about features whose purpose nobody wrote down.
They are also the level most stakeholders can read and sign off, which makes them the natural place to agree scope.
What goes wrong without it
- The team jumps straight to features and builds one solution without considering others.
- Features are built that the business did not need; the ones it did need are missed.
- Sign-off happens on screens instead of needs, so changing a screen reopens the whole discussion.
What it gives an AI agent
An agent asked for a feature with no business requirement behind it has no way to tell whether its version solves the real need. With one, it can check its work against the need, not just the words of the feature request.
Example: Clinic Booking
| Weak | Strong |
|---|---|
| Add an online booking page. | Patients can book appointments outside the clinics' opening hours. |
How it relates to the rest
- Refines an objective (one level up).
- Is refined by stakeholder and functional / non-functional requirements.
- Epics usually implement business or stakeholder requirements.
In Corpole
- Type Business Requirement (BR), in the Requirements group.
- Needs at least one acceptance criterion before it can be Approved or Authority.
- Linked upwards with refines to an objective.