PRINCE2 — Hierarchy of Requirements

One of the practical gaps in PRINCE2 guidance is that it doesn't explicitly address requirement management — how requirements should be structured, where they live, and how detailed they should be. Unlike PMBOK, which has more explicit requirement management directives, PRINCE2 leaves this to the practitioner. This post provides a practical three-level framework.

The Three Levels

Level 1 — Project Product Description (PPD)

High-level requirements belong in the PPD as part of the Composition and Quality Expectations sections. The PPD lives in the Project Brief (and later in the PID). Keep this to fewer than 10 items — these are the top-level outcomes and quality expectations that define whether the project has succeeded.

Level 2 — Product Descriptions

Intermediate (Epic) level requirements live in individual Product Descriptions. These describe specific deliverables — what they contain, their quality criteria, and how they will be reviewed. Aim for between 10 and 100 bullet points per Product Description. This is the right level of detail for project planning and team delegation.

Level 3 — Detailed Requirements

Many projects will have hundreds or thousands of detailed requirements or user stories. These are too granular for Product Descriptions and should be managed in separate documents or backlogs — requirement specifications, user story maps, or Jira/Azure DevOps backlogs depending on the delivery method in use.

Reference Summary

This hierarchy keeps PRINCE2 documentation at the right level of abstraction — strategic at the top, actionable at the bottom — without forcing detailed requirements into places they don't belong.