Project requirement
Something the project must deliver besides the product itself: training, documents, a test suite, a migration.
What it is
A project requirement describes a deliverable of the project rather than a behaviour of the software. Training for receptionists, a user guide, a data migration from the old system, an agreed test report.
Why it matters
A product can work perfectly and still fail to launch because nobody trained the people who use it, or the old data never arrived. Project requirements make those deliverables visible and planned, instead of remembered in the last week.
What goes wrong without it
- Go-live is blocked by a forgotten deliverable.
- Training, documentation and migration are squeezed in at the end, badly.
- The team and the customer disagree about what "finished" includes.
What it gives an AI agent
Agents can produce many project deliverables — guides, migration scripts, test suites — if they know they are expected. A project requirement tells them, and gives people a way to check the deliverable against criteria.
Example: Clinic Booking
| Weak | Strong |
|---|---|
| Receptionists should know how to use it. | Every receptionist completes a one-hour training with the new schedule view before go-live. |
How it relates to the rest
- Sits beside the chain: it does not refine a business requirement.
- A work package delivers a project requirement.
- Differs from a technical requirement (how the product is built) and from a project constraint (a limit on how the project is run).
In Corpole
- Type Project Requirement (PR), in the Requirements group.
- Needs at least one acceptance criterion before Approved or Authority.
- Work packages are linked to it with delivers.