In AEC projects, risk management and requirements management are typically treated as separate disciplines. Different teams, different tools, different workflows. But in practice, these two domains are deeply connected — and integrating them can lead to better outcomes for complex projects.

When analysing design briefs for major AEC projects, you can notice that many of the requirements are responses to risk. They aren’t arbitrary wishes or technical preferences, but deliberate measures to prevent or reduce the impact of undesirable events.

Take a subway station. Its design brief will likely include detailed requirements for drainage systems and pump stations. These requirements exist because heavy rainfall can be a serious issue for underground structures, potentially causing flooding. They are intended to prevent service disruption and protect passengers and equipment.

Or consider a museum. The brief might contain requirements about the resistance class of the façade, intrusion detection systems, CCTV placement, and access systems. All of these are risk-related — they help mitigate threats such as burglary and vandalism.

And there are plenty more examples: hospitals with requirements for infection control; data centres with demands for redundant power supply; schools with specifications for access control, and so on.

In all these examples, the link between risks and requirements is clear: the requirements exist because of risks that need to be dealt with.

Connecting risks and requirements

Despite the connection, risks and requirements are often managed in isolation. Risk managers work on their risk registers, focusing on impact and likelihood. Requirements managers write design briefs, focusing on functions and performance.

Both roles are vital — but the lack of coordination can lead to missed opportunities, unclear rationales, or gaps in the project brief. In the worst case, it can result in major oversights: a critical risk that was never translated into a requirement, leading to serious problems in the operation or use of the facility. That’s why we believe risks and requirements should be addressed in tandem — from the very start of a project.

This means asking:

• What can go wrong?
• How likely is it?
• What would the impact be?
• And how can design or planning help to prevent or mitigate the consequences?

Once these questions are answered, they should feed directly into the project’s requirements. This ensures that key risks are not only identified but also actively addressed — and that everyone involved understands the why behind each requirement.

Risk-based verification

Connecting risks and requirements also enables more effective design verification. In large projects, there will be thousands of requirements and it won’t be possible to verify compliance for every single requirement.

A risk-based approach can be highly practical in such projects: not checking everything, but prioritising the verification, testing and commissioning of risk-related requirements — improving safety and resilience while saving time and cost.

Returning to the earlier subway example: this means, for instance, giving extra attention to simulating the performance of pumps and drainage systems during design and testing their actual working before hand-over  — to be absolutely sure they will perform as intended.

How BriefBuilder supports this

To help project teams with applying this approach in their projects, we’ve introduced a new risk module in BriefBuilder.  With the risk module, you can:

✅ Define all relevant risks for your project
✅ Add custom attributes like likelihood, impact, risk owner, and mitigation strategy
✅ Link each risk to one or more requirements or mitigation actions
✅ Track which requirements are risk-driven
✅ Use these links to prioritise verification and stakeholder reviews

Here’s what that can look like:

 

In this example, the risk of flooding has been registered, with a unique ID (‘RSK-1’)  and attributes such as risk level, likelihood and impact. In the last column, you can also see that it has been linked to a set of requirements in the design brief.

All these risks also have their own ‘detail view’, in which it is possible to add a description, upload documentation and to see the specific requirements that are relevant.

 

It also works the other way around. When you look at a requirement — say, a specific CCTV coverage requirement — you can immediately see that the requirements is related to one or more risks, of which you can see all the details when clicking on it. This gives design teams, contractors, and client reviewers greater insight into why the requirement exists and what problem it’s solving.

 

These links between requirements and risks can be used in design reviews, tender evaluations, commissioning plans, and more. They provide a way to ensure that mitigation measures are not only defined, but also traceable, verifiable, and defensible.

Towards better risk resilience

Risks cannot be eliminated — but they can managed by means of requirements. By making the connection between risks and requirements explicit, project teams can improve clarity and overall performance. It’s a small change in practice, but one with big potential impact.

 

Try it yourself

Want to explore how this works in practice?
You can get a free trial of BriefBuilder here — no credit card required.

Want to learn more about the risk module specifically?
Check out our knowledge base article for details.