1. Home
  2. Requirements definition
  3. Defining requirements for services (e.g. maintenance)

Defining requirements for services (e.g. maintenance)

In DBFM (Design, Build, Finance & Maintain) projects, and other kinds of integrated delivery projects, requirements do not only concern the facility itself, but also services related to the facility’s operation — these are often maintenance services, but sometimes also security, catering and cleaning services.

In BriefBuilder, there is a specific ‘service tree’ (a decomposition or breakdown structure of the requested services) available for such requirements. You can use that tree to define the scope of the service contract and to capture requirements for each specific service (e.g. requirements concerning response times, staff competences, applicable standards, …)

For monitoring purposes, you can also link services to specific types of quality measurements that have to be executed (e.g. condition measurements or satisfaction surveys) and/or to possible performance failures and how these should be dealt with.

Essentially, you are then making a service level specification (SLS) or service level agreement (SLA) that can you use for tendering, verification/compliance management and contract management — all within the BriefBuilder application.

You can find the services tree in the navigation menu, under the main header Requirements

In this article, we will explain how you can define requirements for services in BriefBuilder.

Important: to be able to define requirements for services, you must activate the services tree via the settings menu.

Object types

In the services tree, you can define which services must be performed by the contract party. For this, you can use two kinds of objects:

Service group: a generic group of services that must be provided by the contractor / service provider (e.g. cleaning or maintenance).

Service: a specific service task or activity that must be delivered by the contractor / service provider (e.g. cleaning of internal areas or plant maintenance).

The services are typically part of a service group. E.g. the service façade cleaning is part the service group cleaning.

In addition, you can use folders () to organize and order the requested services and service groups.

TIP: there are classification systems that can help you with the naming and structuring of services.

For building projects, you may want to look into the EN 15221 Facility management- Part 4: Taxonomy, Classification and Structures in Facility Management.

For infrastructure projects, you may to look at the ISO 55000 – Asset management — Overview, principles and terminology, although this one is of a higher abstraction level than the aforementioned EN 15221.


The services tree is typically built up according to what is called an assembly structure: you start with groups of services and then add specific services that are part of that group.

For example: The service group maintenance may consist of the services reactive maintenance, planned maintenance of building systems and planned maintenance of terrain/grounds. See example below.

Please note: services are sometimes mixed up with we call processes 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 facility is in use (e.g. maintenance, operation, cleaning, security).


For each service(group), you can define requirements concerning how or when they need to be executed and to which part of a facility they apply. This can be done on the detail view where can find the following tables:

  • Description
  • Labels
  • Properties
  • Standard properties
  • Relation tables (various kinds)
  • Uploads

Below we will explain the use of each of these tables.


This is where you can enter a general description of the requested service, explaining its general purpose or meaning.

Please note that it is not always necessary to add a description, but it will be relevant when using terms that are rather technical. See below for an example.


Labels are not really requirements, but categorizations. You can use them to classify or categorize services/service groups.

The good thing about labels is that you can filter on them in overviews and tables, which makes it easier to define and manage requirements for services of the same kind.

For services, labels are often used to distinguish between:

  • Standard service: should always be provided, part of the standard service fee.
  • Variable service: only needs to be performed at the client’s specific request.

See example of a label above (under Description).


The property table is where you can define specific requirements. The term property should be understood as a required attribute, capability, characteristic or quality of a service. Examples of properties are frequency, method and scope.

See below for a simple example for the service reactive maintenance.

To create properties for a service (group), click on the Add property button.

TIP: If you have a long list of properties, you can easily insert a property between two existing ones by clicking on the plus icon that appears when you hoover with your mouse near the starting point of the table’s separation lines.

Standard properties

If it is possible to standardize properties across all services, you can do so by defining standard properties via the requirements settings menu. These properties are then shown on the detail view of each service (group).

Examples of standard properties for services are:

TimingDoes a service need to be performed at particular hours/days?
Response timeHow fast does a service need to be performed after it has been requested?
StandardsAre there specific norms or regulations that have to be complied with?
MethodIs there a particular protocol or method that needs be applied when executing the service?
StaffingAre there requirements that apply to the people that will deliver the service (e.g. certification)?
ApprovalIs there a particular approval process or approval period?
ReportingHow does the service provider need to report to the client about the provided service?

In the settings menu, you can define for each property what kinds of values are allowed. E.g. text, a number of specific options from a picklist (which helps to create consistency and it speeds up the specification process).

The advantage of using standard properties is that they can easily be viewed and edited in an Excel-like cross table. However, standard properties only make sense if it is indeed possible to standardize requirement names/types across different services.

Relation tables

Relation tables offer you the possibility to link specific services to other parts of the model, for example to a specific set of spaces or systems.

TIP: The relations between different kinds of objects can easily be viewed and edited in (Excel-like) cross tables.

The number of relation tables that you get to a see on a detail view is dependent on the chosen number of modules. There are the following possibilities:

Please note: the relation tables for spaces and locations, systems and elements, and equipment and monitoring are only available for services, and not for service groups; the latter are generally too generic to be linked to particular objects elsewhere in the model.

Relevant spaces and locations

You can use this table to link a service to a specific spatial part of the facility.

For example: you may want to link the activity daily indoor cleaning to the particular spaces that need to be cleaned on a daily basis. Or, perhaps you want to specify which buildings from your portfolio are part of the maintenance scope.

Relevant systems/elements

You can use this table to link a service to a specific technical system or element of the facility. For example: you may want to link the activity technical maintenance to the specific systems that have to be maintained.

Relevant design principles

You can use this table to link a service to a particular design principle. In a DBM project, there may for example be design principles concerning sustainability that are also relevant for the project’s maintenance.

Monitoring – possible performance failures

This table can be used to link a service to specific type of performance failure (e.g. performance failures of different degrees of severity), which you can then use to specify the related actions or consequences (e.g. penalties).

Monitoring – applicable quality measurements

You can use this table to link a service to a specific quality measurement activity or method that has to be used to measure the delivered performance. E.g. a condition measurement or satisfaction survey. See example above.

Relevant user equipment

You can use this table to link a service to a particular equipment item. In a lab project, you may for example want to link the activity equipment maintenance to the specific equipment items that have to be maintained.


The last table on the detail page is the one for Uploads, where can add files that you feel are relevant for a service(group). For example, particular standards or reporting formats. Be careful, however, not to ‘hide’ any requirements in these files.

You can also add a note for a file, which you can you to explain its relevance, or to explain which part of the file is of particular importance.

Was this article helpful?

Need Support?
Can't find the answer you're looking for? Don't worry we're here to help!