Functional requirement
A behaviour the system must have: what it does in response to a user or an event.
What it is
A functional requirement describes observable behaviour: when this happens, the system does that. It is the level closest to the code, and the one agents implement most often.
Why it matters
Functional requirements are where intent becomes testable. A good one can be checked by a test or a person without interpretation, which is what makes "done" mean the same thing to everyone.
What goes wrong without it
- Developers and agents implement their own interpretation of a vague need.
- Testers cannot say whether something works, only whether it looks right.
- Edge cases (what if the appointment is in the past? what if two people book the same slot?) are decided by accident.
What it gives an AI agent
This is what an agent builds from. A precise functional requirement with acceptance criteria is the difference between an agent that ships the right behaviour and one that ships a plausible guess. The criteria also give the agent a way to prove its work with tests.
Example: Clinic Booking
| Weak | Strong |
|---|---|
| Patients can change appointments. | A patient can move an appointment to another free slot up to 2 hours before it starts; later changes are refused with a message to call the clinic. |
Acceptance criteria then spell out each case: moving within the limit, moving too late, choosing a taken slot.
How it relates to the rest
- Refines a stakeholder or business requirement.
- Is realized by technical requirements.
- Stories implement it and cover its criteria; tests verify the criteria.
In Corpole
- Type Functional Requirement (FR), in the Requirements group.
- Needs at least one acceptance criterion before Approved or Authority; each criterion gets its own code, e.g. FR-5C0A71/AC2.
- Criteria turn Met or Not met through linked tests or a person; an agent's own report stays unverified until then.