Program of Requirements (PoR)

A Program of Requirements (PoR) records what a project must deliver before designers, consultants or contractors develop a solution. The document describes the goals, performance levels, constraints and assessment criteria that matter to the client.

For construction projects, renovations, tenders and technical assignments, the PoR is often the basis for design, request for quotation and contract formation. The clearer the PoR is, the more consistently bidders answer the same question and the lower the risk of disputes about quality, scope or additional work.

What is a Program of Requirements?

A Program of Requirements is a structured description of the requirements a project, building, installation, product or service must meet. It is not just a list of wishes, but a set of testable agreements: what must the result be able to do, under which conditions must it function and when is it acceptable?

This makes the PoR the bridge between the client's need and the market's solution. In an early design phase, the PoR can provide direction. In a tender or agreement, the PoR can become part of the contract documents. In that case, it helps determine how a contractor is assessed.

What is included in a good PoR?

The content differs per project, but a complete Program of Requirements usually contains these components:

• Project goal and scope: what must the project solve, deliver or improve, and what is outside the assignment?
• Functional requirements: what must the result be able to do, such as capacity, use, comfort, safety or availability.
• Technical and performance requirements: measurable requirements for quality, materials, energy, maintenance, service life or regulations.
• Constraints: budget, planning, location, permits, existing situation, sustainability, accessibility and nuisance reduction.
• Testing and acceptance: how compliance with the requirements will be checked, for example with calculations, certificates, inspections, tests or completion documents.

A requirement is stronger when it is clear who is responsible, how the requirement is measured and which evidence is needed. Without a testing method, a requirement can easily become a matter of interpretation.

Difference between a PoR and a specification

A PoR and a specification are often confused, but they do not have the same function. The PoR mainly describes what must be achieved. The specification usually develops the assignment further into concrete works, materials, execution methods and contract conditions.

Document	Main question	Example
Program of Requirements	What must the result be able to do or achieve?	The office space must be comfortable, energy-efficient and suitable for 60 workstations.
Specification	How is the work executed and specified?	Supply and install the specified installation, finishing, materials, connections and completion criteria.

In traditional contracts, the specification often follows the PoR. In integrated contract forms, such as Design & Build or UAV-GC, the PoR remains important because the contractor has more room to develop the solution independently.

Why is a PoR important for quotations?

A quotation can only be compared properly when all bidders use the same starting points. A clear PoR prevents one contractor from pricing a minimum solution while another includes extra quality, maintenance or risk.

For clients, a PoR helps assess quotations on substance instead of price alone. For contractors and consultants, the PoR clarifies which performance levels matter, which assumptions are needed and where questions must be asked during the quotation phase or Information Notice.

How do you formulate good requirements?

Good requirements are concrete, measurable and verifiable. Avoid general words such as "high-quality", "sustainable" or "user-friendly" without explaining what they mean.

Vague requirement	Clearer formulation
The building must be energy-efficient.	The design must meet the agreed energy performance and demonstrate this with a calculation at completion.
The system must be user-friendly.	A new user must be able to complete the main task within 10 minutes without help from an administrator.
The installation must require little maintenance.	Maintenance intervals, response times and required inspections are recorded upfront and substantiated at completion.

Common mistakes in a PoR

• Prescribing too many solutions: this leaves little room for market knowledge or innovation and can unintentionally shift responsibility back to the client.
• Mixing wishes and requirements: make clear what is mandatory, what is a preference and what only counts as an assessment criterion.
• Not including a testing method: without an agreed control method, it is difficult to determine later whether a requirement has been met.
• Leaving contradictions unresolved: check the PoR for conflicts with drawings, budget, permits, planning and other contract documents.

Practical rule of thumb: write a requirement as if you need to check it at completion later. If you cannot explain which evidence is needed, the requirement is probably still too vague.

From PoR to clear assignment

A good PoR does not have to be unnecessarily long. Above all, it must clarify which result the client expects, which constraints are fixed and how quality will be assessed. This makes the PoR a practical steering document for design, quotation comparison, contract formation and execution.

For small projects, a compact requirements list may be sufficient. For complex construction and tender processes, a more detailed PoR is needed, including verification, document order of precedence and agreements about changes. In both cases, the clearer the requirements are upfront, the less room there is for misunderstandings later.