Designing Buildings - User contributions [en]

Requirements management

2021-04-19T14:27:42Z

BriefBuilder:

= What is requirements management? =

The concept of Requirements Management (RM) is relatively new to the construction industry, but it is well established in other engineering disciplines such as software development and aerospace engineering. The concept can be defined as follows:

Requirements management is the process of gathering, structuring, communicating, analysing and verifying the requirements for a facility, with the purpose of ensuring that this facility will fulfil the needs of the stakeholders who will use, own, acquire and operate it.

Requirements management clearly overlaps with the concept of [[Briefing|briefing]], but there is a difference in scope. While briefing traditionally focuses on the development of a building programme in the early phases of a project (i.e. the [[Preparation_and_briefing|briefing phase]]), requirements management is a continuous process in which requirements are defined, refined, updated and verified throughout all phases of a facility’s life cycle.

Another defining aspect of requirements management is that it not only focuses on the client’s functional and spatial requirements—as briefing primarily does—but also on the technical and operational requirements concerning the building’s [[Building_services|technical systems]] and elements, the [[Construction_process|delivery process]], and the [[Facility_management|operation]] and [[Building_maintenance|maintenance]] of the facility. As such, requirements management is targeted at architect, plus all the actors involved, such as project managers, engineers, expert consultants, (sub)contractors, suppliers, asset managers and service providers.

Because of its broad scope, requirements management is often facilitated by [[Requirements_management_application|database tools]] like [https://www.briefbuilder.com/ BriefBuilder] that allow project teams to manage a multitude of different requirements in a systematic way.

= Why is requirements management important? =

Requirements are the basis for any design or engineering project. They define what is expected, needed and required from the project in relation to important quality aspects such as [[Usability|usability]], [[Building_sustainability|sustainability]], [[Security|safety and security]], [[Human_comfort_in_buildings|comfort]], [[Wellbeing_and_buildings|health]], [[Design_flexibility|flexibility]], efficiency and user experience.

Especially in complex construction projects (e.g. hospitals, labs, infrastructure), there is a lot to gain from a systematic approach to requirements. Such projects typically have to comply with a multiplicity of requirements, which makes it difficult to maintain 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|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.

= Activities =

Effective requirements management consists of the following activities:

* Gathering requirements: collecting and eliciting requirements from project [[Stakeholder|stakeholders]]
* Structuring requirements: creating a clear and logically organised set of requirements
* Communicating requirements: communicating requirements with the design/delivery team
* Analysing requirements: reviewing the clarity and feasibility of requirements
* Linking requirements to BIM models: linking requirements to objects in 3D-design models
* Verifying compliance: checking whether solutions are compliant with the defined requirements
* Managing change: logging and evaluating changes and requests for change (RFCs)
* Evaluating and standardizing requirements: creating standardized requirements for new projects

Each of these activities is briefly explained below. The exact order and content of these activities depend on the complexity of the project and the chosen tender procedure.

[[File:RequirementsManagement.png|link=File:RequirementsManagement.png]]

-----
== Gathering requirements ==

The first step is to collect and elicit the needs and requirements of the project’s [[Stakeholder|stakeholders]] (i.e. the [[Construction_client|construction client]], [[Facility_manager|real estate/facility managers]], [[Building_user|users]], interest groups). This can be done by means of workshops, interviews, surveys, the examination of reference projects and document analysis. These activities are classic [[Briefing|briefing]] activities, preferably conducted in the project’s briefing stage. But requirements can also be gathered in a more ‘agile’ way, on an as-needed basis, at later stages in the project.

Activities

* Stakeholder mapping/identification
* Workshops/interviews with stakeholders
* Occupancy and evaluation studies of the ‘as is’ situation
* Analysis of reference projects
* Document analysis of internal or external standards

-----
== Structuring requirements ==

In this step, the information that has been collected in the earlier step—which is often quite ‘fuzzy’—is structured and refined. The goal is to produce a single, clear and well-organised set of requirements. Vague requirements are made specific. Inconsistencies are resolved. Missing requirements are added. Duplicate requirements are removed. For simple projects, this exercise can be done in Excel or Word. For more complex projects it will be useful to have a database tool that can handle large numbers of requirements.

Activities

* Making breakdown structures of requested spaces and/or systems
* Making requirements ‘smart’ (i.e. adding explicit values and units of measure)
* Identifying and solving possible inconsistencies, removing duplicates
* Prioritizing requirements (must-have vs. nice-to-have)
* Reviewing the total set of requirements with stakeholders

-----
== Communicating requirements ==

Needless to say, it is essential to communicate requirements to those who will be designing and building the project. This can be done by means of reports, diagrams and [[Room_data_sheet|datasheets]]. Different actors will be interested in different requirements; an architect, for example, may be primarily interested in spatial requirements, a mechanical engineer in the technical requirements. When communicating requirements, it is crucial that they are up-to-date. Requirements should preferably be accessible via an online platform rather than hidden away in a plethora of emails and reports, so that everybody has access to the same set of up-to-date requirements.

Activities

* Giving project actors access to requirements (via documents or an online model)
* Updating requirements, managing versions and communicating differences between versions (also referred to as baselining)
* Creating dedicated overviews or reports for different actors

-----
== 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 a tender process. It means that all the disciplines involved go through the entire set of requirements and flag requirements that they regard as unclear or risky in terms of costs or feasibility. These outcomes are then fed back to the client as input for further improvement of the requirements.

Activities

* Making a risk analysis of the requirements set
* Reviewing the clarity of requirements
* Identifying possible omissions or contradictory requirements
* Discussing possible improvements with the client
* Allocating requirements to the various project actors (contractor, architect, etc.)

-----
== Verifying compliance ==

[[Verification|Verification]] is the process of checking whether a design proposal or built solution is [[Compliance|compliant]] with the defined requirements. Typically, it is the design team and/or the contractor who is responsible for this. Verification can be done using a simple compliance matrix, but it can also be a more comprehensive procedure based on specifications concerning verification methods (e.g. calculations, simulations, inspections), verification moments, and the documentation that needs to be provided (e.g. test reports).

Activities

* Developing a verification plan
* Assigning verifications to various disciplines/actors
* Carrying out verifications in different phases
* Monitoring progress and overall compliance rate per phase
* Identifying and solving compliance gaps

-----
== Linking requirements to BIM models ==

If captured in the right format, requirements can then be linked to [[BIM_model|BIM models]]. The advantage of doing so is that the verification of design solutions can—in part—be automated. In particular, requirements concerning room quantities, room sizes and the placement of [[FF%26E|FF&E]] items in rooms can easily be checked. Quantitative requirements concerning walking distances and [[Human_comfort_in_buildings|indoor climate]] can in principle also be verified automatically, but that is very much dependent on how the design team has set up its BIM models.

Activities

* Creating data exports of requirements that are ‘readable’ for BIM models
* Executing ‘clash controls’ between design solutions and requirements
* Discussing outcomes with the client

-----
== 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. Once requirements have been formally approved, changes should be made on the basis of formal requests for change (RFCs), which have to reviewed in terms of impact (on costs, time and quality) before they are implemented.

Activities

* Setting up a change management procedure
* Logging requests for change (RFCs)
* Analysing/reviewing RFCs in terms of their impact on costs, time and quality
* Implementing RFCs if accepted
* Communicating changes to the stakeholders

-----
== Evaluating and standardising 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. To ensure that standardised requirements are relevant, it is critical to maintain, manage and improve them on the basis of project evaluations.

Activities

* 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)
* Guiding project teams in the use of requirement libraries/templates in their projects
* Conduct post-occupancy evaluations of projects and incorporate the ‘lessons learnt’ into requirements for new projects

= Summarizing =

Requirements management is a fairly new phenomenon in the construction sector, and although it overlaps with the existing practice of [[Briefing|briefing]], its scope is wider. Requirements management covers the definition, analysis, communication and verification of all project requirements, through all [[Project_stages|phases]] of a project. Especially in large and complex projects, there is much to be gained from systematic requirements management, including avoiding design defects, budget overruns, and delivery delays.

--[[User:BriefBuilder|BriefBuilder]] 15:24, 19 Apr 2021 (BST)

Requirements management

2021-04-19T14:25:49Z

BriefBuilder:

= What is requirements management? =

The concept of Requirements Management (RM) is relatively new to the construction industry, but it is well established in other engineering disciplines such as software development and aerospace engineering. The concept can be defined as follows:

Requirements management is the process of gathering, structuring, communicating, analysing and verifying the requirements for a facility, with the purpose of ensuring that this facility will fulfil the needs of the stakeholders who will use, own, acquire and operate it.

Requirements management clearly overlaps with the concept of [[Briefing|briefing]], but there is a difference in scope. While briefing traditionally focuses on the development of a building programme in the early phases of a project (i.e. the [[Preparation_and_briefing|briefing phase]]), requirements management is a continuous process in which requirements are defined, refined, updated and verified throughout all phases of a facility’s life cycle.

Another defining aspect of requirements management is that it not only focuses on the client’s functional and spatial requirements—as briefing primarily does—but also on the technical and operational requirements concerning the building’s [[Building_services|technical systems]] and elements, the [[Construction_process|delivery process]], and the [[Facility_management|operation]] and [[Building_maintenance|maintenance]] of the facility. As such, requirements management is targeted at architect, plus all the actors involved, such as project managers, engineers, expert consultants, (sub)contractors, suppliers, asset managers and service providers.

Because of its broad scope, requirements management is often facilitated by [[Requirements_management_application|database tools]] like [https://www.briefbuilder.com/ BriefBuilder] that allow project teams to manage a multitude of different requirements in a systematic way.

= Why is requirements management important? =

Requirements are the basis for any design or engineering project. They define what is expected, needed and required from the project in relation to important quality aspects such as [[Usability|usability]], [[Building_sustainability|sustainability]], [[Security|safety and security]], [[Human_comfort_in_buildings|comfort]], [[Wellbeing_and_buildings|health]], [[Design_flexibility|flexibility]], efficiency and user experience.

Especially in complex construction projects (e.g. hospitals, labs, infrastructure), there is a lot to gain from a systematic approach to requirements. Such projects typically have to comply with a multiplicity of requirements, which makes it difficult to maintain 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|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.

= Activities =

Effective requirements management consists of the following activities:

* Gathering requirements: collecting and eliciting requirements from project [[Stakeholder|stakeholders]]
* Structuring requirements: creating a clear and logically organised set of requirements
* Communicating requirements: communicating requirements with the design/delivery team
* Analysing requirements: reviewing the clarity and feasibility of requirements
* Linking requirements to BIM models: linking requirements to objects in 3D-design models
* Verifying compliance: checking whether solutions are compliant with the defined requirements
* Managing change: logging and evaluating changes and requests for change (RFCs)
* Evaluating and standardizing requirements: creating standardized requirements for new projects

Each of these activities is briefly explained below. The exact order and content of these activities depend on the complexity of the project and the chosen tender procedure.

[[File:RequirementsManagement.png]]

== Gathering requirements ==

The first step is to collect and elicit the needs and requirements of the project’s [[Stakeholder|stakeholders]] (i.e. the [[Construction_client|construction client]], [[Facility_manager|real estate/facility managers]], [[Building_user|users]], interest groups). This can be done by means of workshops, interviews, surveys, the examination of reference projects and document analysis. These activities are classic [[Briefing|briefing]] activities, preferably conducted in the project’s briefing stage. But requirements can also be gathered in a more ‘agile’ way, on an as-needed basis, at later stages in the project.

Activities

* Stakeholder mapping/identification
* Workshops/interviews with stakeholders
* Occupancy and evaluation studies of the ‘as is’ situation
* Analysis of reference projects
* Document analysis of internal or external standards

== Structuring requirements ==

In this step, the information that has been collected in the earlier step—which is often quite ‘fuzzy’—is structured and refined. The goal is to produce a single, clear and well-organised set of requirements. Vague requirements are made specific. Inconsistencies are resolved. Missing requirements are added. Duplicate requirements are removed. For simple projects, this exercise can be done in Excel or Word. For more complex projects it will be useful to have a database tool that can handle large numbers of requirements.

Activities

* Making breakdown structures of requested spaces and/or systems
* Making requirements ‘smart’ (i.e. adding explicit values and units of measure)
* Identifying and solving possible inconsistencies, removing duplicates
* Prioritizing requirements (must-have vs. nice-to-have)
* Reviewing the total set of requirements with stakeholders

== Communicating requirements ==

Needless to say, it is essential to communicate requirements to those who will be designing and building the project. This can be done by means of reports, diagrams and [[Room_data_sheet|datasheets]]. Different actors will be interested in different requirements; an architect, for example, may be primarily interested in spatial requirements, a mechanical engineer in the technical requirements. When communicating requirements, it is crucial that they are up-to-date. Requirements should preferably be accessible via an online platform rather than hidden away in a plethora of emails and reports, so that everybody has access to the same set of up-to-date requirements.

Activities

* Giving project actors access to requirements (via documents or an online model)
* Updating requirements, managing versions and communicating differences between versions (also referred to as baselining)
* Creating dedicated overviews or reports for different actors

== 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 a tender process. It means that all the disciplines involved go through the entire set of requirements and flag requirements that they regard as unclear or risky in terms of costs or feasibility. These outcomes are then fed back to the client as input for further improvement of the requirements.

Activities

* Making a risk analysis of the requirements set
* Reviewing the clarity of requirements
* Identifying possible omissions or contradictory requirements
* Discussing possible improvements with the client
* Allocating requirements to the various project actors (contractor, architect, etc.)

== Verifying compliance ==

[[Verification|Verification]] is the process of checking whether a design proposal or built solution is [[Compliance|compliant]] with the defined requirements. Typically, it is the design team and/or the contractor who is responsible for this. Verification can be done using a simple compliance matrix, but it can also be a more comprehensive procedure based on specifications concerning verification methods (e.g. calculations, simulations, inspections), verification moments, and the documentation that needs to be provided (e.g. test reports).

Activities

* Developing a verification plan
* Assigning verifications to various disciplines/actors
* Carrying out verifications in different phases
* Monitoring progress and overall compliance rate per phase
* Identifying and solving compliance gaps

== Linking requirements to BIM models ==

If captured in the right format, requirements can then be linked to [[BIM_model|BIM models]]. The advantage of doing so is that the verification of design solutions can—in part—be automated. In particular, requirements concerning room quantities, room sizes and the placement of [[FF%26E|FF&E]] items in rooms can easily be checked. Quantitative requirements concerning walking distances and [[Human_comfort_in_buildings|indoor climate]] can in principle also be verified automatically, but that is very much dependent on how the design team has set up its BIM models.

Activities

* Creating data exports of requirements that are ‘readable’ for BIM models
* Executing ‘clash controls’ between design solutions and requirements
* Discussing outcomes with the client

== 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. Once requirements have been formally approved, changes should be made on the basis of formal requests for change (RFCs), which have to reviewed in terms of impact (on costs, time and quality) before they are implemented.

Activities

* Setting up a change management procedure
* Logging requests for change (RFCs)
* Analysing/reviewing RFCs in terms of their impact on costs, time and quality
* Implementing RFCs if accepted
* Communicating changes to the stakeholders

== Evaluating and standardising 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. To ensure that standardised requirements are relevant, it is critical to maintain, manage and improve them on the basis of project evaluations.

Activities

* 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)
* Guiding project teams in the use of requirement libraries/templates in their projects
* Conduct post-occupancy evaluations of projects and incorporate the ‘lessons learnt’ into requirements for new projects

== Summarizing ==

Requirements management is a fairly new phenomenon in the construction sector, and although it overlaps with the existing practice of [[Briefing|briefing]], its scope is wider. Requirements management covers the definition, analysis, communication and verification of all project requirements, through all [[Project_stages|phases]] of a project. Especially in large and complex projects, there is much to be gained from systematic requirements management, including avoiding design defects, budget overruns, and delivery delays.

--[[User:BriefBuilder|BriefBuilder]] 15:24, 19 Apr 2021 (BST)

Requirements management

2021-04-19T14:24:03Z

BriefBuilder:

= What is requirements management? =

The concept of Requirements Management (RM) is relatively new to the construction industry, but it is well established in other engineering disciplines such as software development and aerospace engineering. The concept can be defined as follows:

Requirements management is the process of gathering, structuring, communicating, analysing and verifying the requirements for a facility, with the purpose of ensuring that this facility will fulfil the needs of the stakeholders who will use, own, acquire and operate it.

Requirements management clearly overlaps with the concept of [[Briefing|briefing]], but there is a difference in scope. While briefing traditionally focuses on the development of a building programme in the early phases of a project (i.e. the [[Preparation_and_briefing|briefing phase]]), requirements management is a continuous process in which requirements are defined, refined, updated and verified throughout all phases of a facility’s life cycle.

Another defining aspect of requirements management is that it not only focuses on the client’s functional and spatial requirements—as briefing primarily does—but also on the technical and operational requirements concerning the building’s [[Building_services|technical systems]] and elements, the [[Construction_process|delivery process]], and the [[Facility_management|operation]] and [[Building_maintenance|maintenance]] of the facility. As such, requirements management is targeted at architect, plus all the actors involved, such as project managers, engineers, expert consultants, (sub)contractors, suppliers, asset managers and service providers.

Because of its broad scope, requirements management is often facilitated by [[Requirements_management_application|database tools]] like [https://www.briefbuilder.com/ BriefBuilder] that allow project teams to manage a multitude of different requirements in a systematic way.

= Why is requirements management important? =

Requirements are the basis for any design or engineering project. They define what is expected, needed and required from the project in relation to important quality aspects such as [[Usability|usability]], [[Building_sustainability|sustainability]], [[Security|safety and security]], [[Human_comfort_in_buildings|comfort]], [[Wellbeing_and_buildings|health]], [[Design_flexibility|flexibility]], efficiency and user experience.

Especially in complex construction projects (e.g. hospitals, labs, infrastructure), there is a lot to gain from a systematic approach to requirements. Such projects typically have to comply with a multiplicity of requirements, which makes it difficult to maintain 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|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.

= Activities =

Effective requirements management consists of the following activities:

* Gathering requirements: collecting and eliciting requirements from project [[Stakeholder|stakeholders]]
* Structuring requirements: creating a clear and logically organised set of requirements
* Communicating requirements: communicating requirements with the design/delivery team
* Analysing requirements: reviewing the clarity and feasibility of requirements
* Linking requirements to BIM models: linking requirements to objects in 3D-design models
* Verifying compliance: checking whether solutions are compliant with the defined requirements
* Managing change: logging and evaluating changes and requests for change (RFCs)
* Evaluating and standardizing requirements: creating standardized requirements for new projects

Each of these activities is briefly explained below. The exact order and content of these activities depend on the complexity of the project and the chosen tender procedure.

== Gathering requirements ==

The first step is to collect and elicit the needs and requirements of the project’s [[Stakeholder|stakeholders]] (i.e. the [[Construction_client|construction client]], [[Facility_manager|real estate/facility managers]], [[Building_user|users]], interest groups). This can be done by means of workshops, interviews, surveys, the examination of reference projects and document analysis. These activities are classic [[Briefing|briefing]] activities, preferably conducted in the project’s briefing stage. But requirements can also be gathered in a more ‘agile’ way, on an as-needed basis, at later stages in the project.

Activities

* Stakeholder mapping/identification
* Workshops/interviews with stakeholders
* Occupancy and evaluation studies of the ‘as is’ situation
* Analysis of reference projects
* Document analysis of internal or external standards

== Structuring requirements ==

In this step, the information that has been collected in the earlier step—which is often quite ‘fuzzy’—is structured and refined. The goal is to produce a single, clear and well-organised set of requirements. Vague requirements are made specific. Inconsistencies are resolved. Missing requirements are added. Duplicate requirements are removed. For simple projects, this exercise can be done in Excel or Word. For more complex projects it will be useful to have a database tool that can handle large numbers of requirements.

Activities

* Making breakdown structures of requested spaces and/or systems
* Making requirements ‘smart’ (i.e. adding explicit values and units of measure)
* Identifying and solving possible inconsistencies, removing duplicates
* Prioritizing requirements (must-have vs. nice-to-have)
* Reviewing the total set of requirements with stakeholders

== Communicating requirements ==

Needless to say, it is essential to communicate requirements to those who will be designing and building the project. This can be done by means of reports, diagrams and [[Room_data_sheet|datasheets]]. Different actors will be interested in different requirements; an architect, for example, may be primarily interested in spatial requirements, a mechanical engineer in the technical requirements. When communicating requirements, it is crucial that they are up-to-date. Requirements should preferably be accessible via an online platform rather than hidden away in a plethora of emails and reports, so that everybody has access to the same set of up-to-date requirements.

Activities

* Giving project actors access to requirements (via documents or an online model)
* Updating requirements, managing versions and communicating differences between versions (also referred to as baselining)
* Creating dedicated overviews or reports for different actors

== 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 a tender process. It means that all the disciplines involved go through the entire set of requirements and flag requirements that they regard as unclear or risky in terms of costs or feasibility. These outcomes are then fed back to the client as input for further improvement of the requirements.

Activities

* Making a risk analysis of the requirements set
* Reviewing the clarity of requirements
* Identifying possible omissions or contradictory requirements
* Discussing possible improvements with the client
* Allocating requirements to the various project actors (contractor, architect, etc.)

== Verifying compliance ==

[[Verification|Verification]] is the process of checking whether a design proposal or built solution is [[Compliance|compliant]] with the defined requirements. Typically, it is the design team and/or the contractor who is responsible for this. Verification can be done using a simple compliance matrix, but it can also be a more comprehensive procedure based on specifications concerning verification methods (e.g. calculations, simulations, inspections), verification moments, and the documentation that needs to be provided (e.g. test reports).

Activities

* Developing a verification plan
* Assigning verifications to various disciplines/actors
* Carrying out verifications in different phases
* Monitoring progress and overall compliance rate per phase
* Identifying and solving compliance gaps

== Linking requirements to BIM models ==

If captured in the right format, requirements can then be linked to [[BIM_model|BIM models]]. The advantage of doing so is that the verification of design solutions can—in part—be automated. In particular, requirements concerning room quantities, room sizes and the placement of [[FF%26E|FF&E]] items in rooms can easily be checked. Quantitative requirements concerning walking distances and [[Human_comfort_in_buildings|indoor climate]] can in principle also be verified automatically, but that is very much dependent on how the design team has set up its BIM models.

Activities

* Creating data exports of requirements that are ‘readable’ for BIM models
* Executing ‘clash controls’ between design solutions and requirements
* Discussing outcomes with the client

== 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. Once requirements have been formally approved, changes should be made on the basis of formal requests for change (RFCs), which have to reviewed in terms of impact (on costs, time and quality) before they are implemented.

Activities

* Setting up a change management procedure
* Logging requests for change (RFCs)
* Analysing/reviewing RFCs in terms of their impact on costs, time and quality
* Implementing RFCs if accepted
* Communicating changes to the stakeholders

== Evaluating and standardising 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. To ensure that standardised requirements are relevant, it is critical to maintain, manage and improve them on the basis of project evaluations.

Activities

* 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)
* Guiding project teams in the use of requirement libraries/templates in their projects
* Conduct post-occupancy evaluations of projects and incorporate the ‘lessons learnt’ into requirements for new projects

== Summarizing ==

Requirements management is a fairly new phenomenon in the construction sector, and although it overlaps with the existing practice of [[Briefing|briefing]], its scope is wider. Requirements management covers the definition, analysis, communication and verification of all project requirements, through all [[Project_stages|phases]] of a project. Especially in large and complex projects, there is much to be gained from systematic requirements management, including avoiding design defects, budget overruns, and delivery delays.

--[[User:BriefBuilder|BriefBuilder]] 15:24, 19 Apr 2021 (BST)

Requirements management

2021-04-19T14:21:32Z

BriefBuilder: Created page with "= What is requirements management? = The concept of Requirements Management (RM) is relatively new to the construction industry, but it is well established in other engineering ..."

= What is requirements management? =

The concept of Requirements Management (RM) is relatively new to the construction industry, but it is well established in other engineering disciplines such as software development and aerospace engineering. The concept can be defined as follows:

Requirements management is the process of gathering, structuring, communicating, analysing and verifying the requirements for a facility, with the purpose of ensuring that this facility will fulfil the needs of the stakeholders who will use, own, acquire and operate it.

Requirements management clearly overlaps with the concept of [[Briefing|briefing]], but there is a difference in scope. While briefing traditionally focuses on the development of a building programme in the early phases of a project (i.e. the [[Preparation_and_briefing|briefing phase]]), requirements management is a continuous process in which requirements are defined, refined, updated and verified throughout all phases of a facility’s life cycle.

Another defining aspect of requirements management is that it not only focuses on the client’s functional and spatial requirements—as briefing primarily does—but also on the technical and operational requirements concerning the building’s [[Building_services|technical systems]] and elements, the [[Construction_process|delivery process]], and the [[Facility_management|operation]] and [[Building_maintenance|maintenance]] of the facility. As such, requirements management is targeted at architect, plus all the actors involved, such as project managers, engineers, expert consultants, (sub)contractors, suppliers, asset managers and service providers.

Because of its broad scope, requirements management is often facilitated by [[Requirements_management_application|database tools]] like [https://www.briefbuilder.com/ BriefBuilder] that allow project teams to manage a multitude of different requirements in a systematic way.

= Why is requirements management important? =

Requirements are the basis for any design or engineering project. They define what is expected, needed and required from the project in relation to important quality aspects such as [[Usability|usability]], [[Building_sustainability|sustainability]], [[Security|safety and security]], [[Human_comfort_in_buildings|comfort]], [[Wellbeing_and_buildings|health]], [[Design_flexibility|flexibility]], efficiency and user experience.

Especially in complex construction projects (e.g. hospitals, labs, infrastructure), there is a lot to gain from a systematic approach to requirements. Such projects typically have to comply with a multiplicity of requirements, which makes it difficult to maintain 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|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.

= Activities =

Effective requirements management consists of the following activities:

* Gathering requirements: collecting and eliciting requirements from project [[Stakeholder|stakeholders]]
* Structuring requirements: creating a clear and logically organised set of requirements
* Communicating requirements: communicating requirements with the design/delivery team
* Analysing requirements: reviewing the clarity and feasibility of requirements
* Linking requirements to BIM models: linking requirements to objects in 3D-design models
* Verifying compliance: checking whether solutions are compliant with the defined requirements
* Managing change: logging and evaluating changes and requests for change (RFCs)
* Evaluating and standardizing requirements: creating standardized requirements for new projects

Each of these activities is briefly explained below. The exact order and content of these activities depend on the complexity of the project and the chosen tender procedure.

== Gathering requirements ==

The first step is to collect and elicit the needs and requirements of the project’s [[Stakeholder|stakeholders]] (i.e. the [[Construction_client|construction client]], [[Facility_manager|real estate/facility managers]], [[Building_user|users]], interest groups). This can be done by means of workshops, interviews, surveys, the examination of reference projects and document analysis. These activities are classic [[Briefing|briefing]] activities, preferably conducted in the project’s briefing stage. But requirements can also be gathered in a more ‘agile’ way, on an as-needed basis, at later stages in the project.

Activities

* Stakeholder mapping/identification
* Workshops/interviews with stakeholders
* Occupancy and evaluation studies of the ‘as is’ situation
* Analysis of reference projects
* Document analysis of internal or external standards

== Structuring requirements ==

In this step, the information that has been collected in the earlier step—which is often quite ‘fuzzy’—is structured and refined. The goal is to produce a single, clear and well-organised set of requirements. Vague requirements are made specific. Inconsistencies are resolved. Missing requirements are added. Duplicate requirements are removed. For simple projects, this exercise can be done in Excel or Word. For more complex projects it will be useful to have a database tool that can handle large numbers of requirements.

Activities

* Making breakdown structures of requested spaces and/or systems
* Making requirements ‘smart’ (i.e. adding explicit values and units of measure)
* Identifying and solving possible inconsistencies, removing duplicates
* Prioritizing requirements (must-have vs. nice-to-have)
* Reviewing the total set of requirements with stakeholders

== Communicating requirements ==

Needless to say, it is essential to communicate requirements to those who will be designing and building the project. This can be done by means of reports, diagrams and [[Room_data_sheet|datasheets]]. Different actors will be interested in different requirements; an architect, for example, may be primarily interested in spatial requirements, a mechanical engineer in the technical requirements. When communicating requirements, it is crucial that they are up-to-date. Requirements should preferably be accessible via an online platform rather than hidden away in a plethora of emails and reports, so that everybody has access to the same set of up-to-date requirements.

Activities

* Giving project actors access to requirements (via documents or an online model)
* Updating requirements, managing versions and communicating differences between versions (also referred to as baselining)
* Creating dedicated overviews or reports for different actors

== 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 a tender process. It means that all the disciplines involved go through the entire set of requirements and flag requirements that they regard as unclear or risky in terms of costs or feasibility. These outcomes are then fed back to the client as input for further improvement of the requirements.

Activities

* Making a risk analysis of the requirements set
* Reviewing the clarity of requirements
* Identifying possible omissions or contradictory requirements
* Discussing possible improvements with the client
* Allocating requirements to the various project actors (contractor, architect, etc.)

== Verifying compliance ==

[[Verification|Verification]] is the process of checking whether a design proposal or built solution is [[Compliance|compliant]] with the defined requirements. Typically, it is the design team and/or the contractor who is responsible for this. Verification can be done using a simple compliance matrix, but it can also be a more comprehensive procedure based on specifications concerning verification methods (e.g. calculations, simulations, inspections), verification moments, and the documentation that needs to be provided (e.g. test reports).

Activities

* Developing a verification plan
* Assigning verifications to various disciplines/actors
* Carrying out verifications in different phases
* Monitoring progress and overall compliance rate per phase
* Identifying and solving compliance gaps

== Linking requirements to BIM models ==

If captured in the right format, requirements can then be linked to [[BIM_model|BIM models]]. The advantage of doing so is that the verification of design solutions can—in part—be automated. In particular, requirements concerning room quantities, room sizes and the placement of [[FF&E|FF&E]] items in rooms can easily be checked. Quantitative requirements concerning walking distances and [[Human_comfort_in_buildings|indoor climate]] can in principle also be verified automatically, but that is very much dependent on how the design team has set up its BIM models.

Activities

* Creating data exports of requirements that are ‘readable’ for BIM models
* Executing ‘clash controls’ between design solutions and requirements
* Discussing outcomes with the client

== 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. Once requirements have been formally approved, changes should be made on the basis of formal requests for change (RFCs), which have to reviewed in terms of impact (on costs, time and quality) before they are implemented.

Activities

* Setting up a change management procedure
* Logging requests for change (RFCs)
* Analysing/reviewing RFCs in terms of their impact on costs, time and quality
* Implementing RFCs if accepted
* Communicating changes to the stakeholders

== Evaluating and standardising 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. To ensure that standardised requirements are relevant, it is critical to maintain, manage and improve them on the basis of project evaluations.

Activities

* 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)
* Guiding project teams in the use of requirement libraries/templates in their projects
* Conduct post-occupancy evaluations of projects and incorporate the ‘lessons learnt’ into requirements for new projects

== Summarizing ==

Requirements management is a fairly new phenomenon in the construction sector, and although it overlaps with the existing practice of [[Briefing|briefing]], its scope is wider. Requirements management covers the definition, analysis, communication and verification of all project requirements, through all [[Project_stages|phases]] of a project. Especially in large and complex projects, there is much to be gained from systematic requirements management, including avoiding design defects, budget overruns, and delivery delays.

File:RequirementsManagement.png

2021-04-19T14:12:53Z

BriefBuilder: uploaded a new version of "File:RequirementsManagement.png": Reverted to version as of 14:09, 19 April 2021

File:RequirementsManagement.png

2021-04-19T14:10:07Z

BriefBuilder: uploaded a new version of "File:RequirementsManagement.png": Reverted to version as of 14:07, 19 April 2021

File:RequirementsManagement.png

2021-04-19T14:09:43Z

BriefBuilder: uploaded a new version of "File:RequirementsManagement.png": white background

File:RequirementsManagement.png

2021-04-19T14:07:03Z

BriefBuilder: uploaded a new version of "File:RequirementsManagement.png"

File:RequirementsManagement.png

2021-04-19T14:06:20Z

BriefBuilder: uploaded a new version of "File:RequirementsManagement.png": Reverted to version as of 13:53, 19 April 2021

File:RequirementsManagement.png

2021-04-19T14:05:12Z

BriefBuilder: uploaded a new version of "File:RequirementsManagement.png"

File:RequirementsManagement.png

2021-04-19T14:04:32Z

BriefBuilder: uploaded a new version of "File:RequirementsManagement.png"

File:RequirementsManagement.png

2021-04-19T13:53:47Z

BriefBuilder: