Defining process requirements

Contents

Important: to be able to define process requirements, you must activate the process module in the modules menu.

In large construction projects, requirements will not only concern the built object itself, but also the processes that need to be performed by the contractor/design team to realise it (e.g. particular design tasks or engineering activities).

In addition, there are likely to be requirements concerning the deliverables that need to be produced during the project (e.g. BIM models, certificates, warranties, test reports).

Both are important as they help to create a shared understanding of what needs to be done and delivered in each phase of the project.

In BriefBuilder, there are two ‘trees’ (decompositions) available for capturing such requirements:

a process tree (what has to be done?)
a deliverables tree (what has to be delivered?).

The process and deliverable decompositions can be found under requirements / process, in the navigation menu

Both will be discussed below.

Processes & activities

In the process tree, you can define what processes and activities have to be done by the contract party. It consists of two types of objects:

	Process	A general process that has to be taken care of by the contractor/design team (e.g. landscape design or interior design). Can be subdivided into sub-processes or activities.
	Activity	A specific activity or task that has to be executed by the contractor/design team, typically with a distinct deliverable (e.g. requesting permits or doing a particular test). Lowest level of the tree. Cannot be further subdivided.

In the tree, processes and activities can be structured according phasing or discipline or a combination of both. This can be done by using the folders (). See below for a simple example.

Example of how a ‘process tree’ can be used to define what kind of activities are expected in relation to interior design. You can use BriefBuilder’s label feature to indicate whether activities are optional.

Please note: processes are sometimes mixed up with we call services in BriefBuilder. The difference is as follows:

Processes are the activities/tasks that have to be done to realize and complete the project (e.g. design activities, construction work).

Services are the activities/task that a party has to deliver once the built structure is in use (e.g. maintenance, operation, cleaning, security).

Process requirements

For each process and activity, you can define requirements concerning how or when they need to be executed.

This can be done by creating properties on the detail view of a process/activity (just click on Add property button), or by defining standard properties (via the requirements settings menu). Typical examples of such properties are:

Frequency	How often does an activity need to be executed?
Start/end date	Is there a particular time frame for the activity?
Standards	Are there specific norms or regulations that have to be complied with?
Method	Is there a particular protocol or method that needs be applied?
Staffing	Are there requirements that apply to the people that will perform the activity (e.g. certification) ?
Approval	Is there a particular approval process or approval period?

See below for a simple example of what kind of requirements a client may have formulated concerning the activity Workshops with end users.

In this example, the description and properties are used to specify what the client expects from the design team in relation to user involvement.

A more technical example can be seen below. It is an example of a test activity (a ‘soak test’) that is part of a commissioning process.

Please note that you can link activities to specific spaces or systems or elements to which they apply. In this example of the soak test, this is done in the table Relevant systems/elements. This table specifies for which systems the test has to be executed.

To link an activity to a particular technical system or element, click on Select.

Furthermore, it is possible to link processes and activities to deliverables (see below), which are typically the outcome of an activity. This can be done in the table Deliverables.

To link an activity to a particular deliverable, click on Select

Please note: using the deliverables ‘tree’ is only relevant when you have detailed requirements concerning deliverables (see examples above). If not, you can instead choose to simply add a standard property called ‘deliverable’ to the aforementioned activities.

Deliverables

The deliverables tree can be used to define what kind of documentation needs to be delivered during the different project phases. Think of documents (drawings, warranties, permits, plannings documents), but also of BIM models, mock-ups or product samples.

The tree consist only of one type of object (‘deliverable’). You can use the folders () to organise the deliverables according to type, phase, or discipline. See below for a simple example.

For some deliverables, you may want to add specific requirements concerning their content of format. This can be done by creating properties on the detail view of a deliverable (just click on Add property button), or by defining standard properties (via the requirements settings menu). Typical examples of such properties are:

Format	Is there particular file/data format that is required? E.g. Pdf for documents or Ifc for designmodels.
Submission time	When do the deliverables have to be handed over/sent?
Standards	Are there specific norms or regulations that have to be complied with?
Contents	What needs to be in the document?
LOD	Is there a particular level of detail/development that is required for BIM models?
Approval period	How long does the construction client have to approve the material?

See below for a simple example of requirements for an end of stage report.