As it says on our website, BriefBuilder is a tool for requirements management. But what exactly is that?
Definition
The concept of requirements management (RM) is well established in other engineering disciplines such as software development and aerospace engineering, but still relatively new to the construction industry. So, some explanation is in order. Let’s start with a definition.
Formally defined, requirements management is:
The process of capturing, structuring, communicating, analysing and verifying the requirements for a facility, with the aim to ensure it will fulfil the needs of the stakeholders who will use, own, acquire and operate it.
Informally defined, it is:
All that is needed to make sure that the project’s outcomes will meet stakeholder needs.
The concept has a large overlap with the concept of construction briefing (or architectural programming, as it is called in the US), but there is a difference in scope. While briefing traditionally focuses on the early phases of a project (i.e. the briefing phase), RM is a continuous process in which requirements are defined, refined, updated and verified throughout all project phases. See diagram below for a comparison (based on the work of Arto Kiviniemi).
Another defining aspect of RM is that it not only focuses on the client’s functional requirements, as briefing often does, but also on technical and operational requirements. As such, requirements management is targeted at the design team, plus all other actors involved, such as project managers, engineers, contractors and suppliers.
Why is requirements management important?
Requirements are the basis for any design or engineering project. They define what is expected and needed in relation to important themes such as usability, sustainability, safety, flexibility, efficiency and user experience.
In complex construction projects (e.g. hospitals, labs, infrastructure), there are usually lots of such requirements, which makes it difficult to maintain an overview. This introduces the risk of requirements being overlooked or ignored, or not properly updated and verified during the project. The potential consequences include design defects, scope creep, budget overruns and delivery delays due to rework.
Requirements management aims to avoid such problems. The central idea is that clear and error-free requirements, combined with systematic compliance testing, helps to ensure that projects meet the needs of their stakeholders.
What activities are part of requirements management?
Effective RM consists of the following activities:
- Capturing requirements
- Structuring requirements
- Communicating requirements
- Analysing requirements
- Verifying compliance
- Linking requirements to BIM models
- Managing change
- Standardising and re-using requirements
Each of these activities is explained below. The exact order and content of these activities depends on the complexity of the project and the chosen tender procedure.
1. Capturing requirements
The first step is to collect and elicit the needs and requirements of the project’s stakeholders (i.e. the construction client, facility managers, users and other interest groups).
-
-
- Stakeholder mapping/identification.
- Workshops/interviews with stakeholders.
- Document analysis of internal or external standards.
-
2. Structuring requirements
In this step, the information that has been collected – which is often quite ‘fuzzy’ – is structured and refined. The goal is to produce a single, clear and well-organised set of requirements.
-
-
- Making breakdown structures of requested spaces and/or systems.
- Making requirements ‘smart’ (i.e. adding explicit values and units of measurement).
- Identifying and solving possible inconsistencies, removing duplicates.
-
3. Communicating requirements
It is essential to communicate requirements to those who will be designing and building the project. This can be done by giving teams access to the online requirements model and by means of exports and reports.
-
-
- Giving project actors access to requirements and the ability to comment on them.
- Updating requirements, managing versions and communicating differences between versions (also referred to as baselining).
- Creating dedicated overviews or reports for different actors.
-
4. Analysing requirements
A requirements analysis is a formal review of the project’s requirements, typically made by the design/delivery team before the start of the design process or during the tender process. The outcomes are then fed back to the client as input for further improvement of the requirements.
-
-
- Making a risk analysis of the requirements set.
- Reviewing the feasibility of requirements.
- Allocating requirements to the various project actors (contractor, architect, etc.).
-
5. Linking requirements to BIM models
If captured in the right format, requirements can then be linked to BIM models. The advantage of doing so is that requirements can be integrated into the design process and be used for the automated verification of design solutions.
-
-
- Linking spaces in BriefBuilder to spaces into BIM (ifc) models.
- Checking how requirements have been translated into design solutions
- Exporting/integrating requirements into the design teams applications
-
6. Verifying compliance
Verification is the process of checking whether a design proposal or built solution is compliant with the defined requirements. It can be done by using a simple compliance matrix, but also by means of a comprehensive plan that stipulates specific verification methods (e.g. calculations, simulations, inspections) and verification moments.
-
-
- Developing a verification plan.
- Assigning verifications to various disciplines/actors.
- Carrying out verifications in different phases.
-
7. Managing change
Ideally, requirements do not change during a project, but change cannot be avoided entirely. Changes may come from new insights, budget changes, feedback from contractors or regulatory changes. This need not be a problem as long as change happens in a controlled way.
-
-
- Analysing/reviewing RFCs in terms of their impact on costs, time and quality.
- Implementing RFCs if accepted.
- Communicating changes to the stakeholders.
-
8. Standardising and re-using requirements
Having developed an effective set of requirements, it makes sense to standardise and reuse them. Large clients may, for example, develop requirements templates for specific room types (e.g. patient rooms or classrooms) or systems (e.g. access control systems). Standardisation will help to create consistency across projects and speed up the specification process.
-
-
- Developing requirement libraries/templates for common room types, systems or building types.
- Evaluating the quality of requirements after each project (e.g. by looking at verification outcomes and the number of RFCs relating to a specific requirement).
- Conducting post-occupancy evaluations of projects and incorporating the ‘lessons learnt’ into requirements for new projects.
-
Try it!
You’re probably already considering how requirements management could boost your project’s success. A great way to start and ensure smooth adoption is to start building out these processes with BriefBuilder. Start creating a requirements management model for your project, for free, by signing up for a BriefBuilder trial, no credit card required.