For those that are interested, this entry explains a bit about how we capture information in BriefBuilder.
Model-based requirements
In BriefBuilder, information is captured in a different way than in a traditional specification document.
In a traditional document (or even in most other requirement applications), requirements are formulated in prose (or ‘requirement texts’): free flowing words and sentences, usually without much structure.
In contrast, BriefBuilder captures information by means of database objects (e.g. rooms or walls or users), with particular properties (e.g. size or capacity), and relations between objects (e.g. a connection relation).
A simple example can illustrate the difference: in a traditional brief, there may be a sentence like “The entrance should be located close to the restaurant”. In BriefBuilder, the same information is captured by making two objects (restaurant and entrance) and a relation between these (a proximity relation). See the figure below.
The benefit of this way of capturing information is that the computer ‘knows’ what is being asked for (it is a so-called semantic model), whereas traditional text can only be understood by humans. This makes it possible to conduct automated checks, to exchange data with other applications, and to use requirements as input for parametric or generative design processes.
Furthermore, it pushes clients to be very clear and explicit about their requirements. No more endless badly written texts, but crisp-and-clear requirements in a digital format : – )
Below, we will further explain BriefBuilder’s three main building blocks:
- Objects
- Properties
- Relations
Objects
An object can be understood as a ‘thing’ or ‘information unit’ that has distinct properties and relationships to other objects.
Obvious examples of objects are physical or spatial objects like walls or rooms. But also abstractions, like an organization or a project objective, can be seen as objects. They are the carrier of the requirements, so to speak.
In BriefBuilder, we have different kinds of objects, which are organized in decomposition structures (called trees in BriefBuilder lingo). See below for an overview of the different trees and objects that we have.
Spaces & locations
In the Spaces & Locations tree, you can create objects that are a spatial and/or functional representation of the different parts of your project. It can contain the following object types:
| Location | A specific geographical area or site where a built asset is located or must be realised. | |
| Connection | An infrastructural connection between two points. E.g. road, rail track or cable corridor. | |
| Segment | A specific functional or spatial part of an infrastructure connection. E.g. a traffic lane or tunnel segment. | |
| Building | A building that needs to be build/renovated. E.g. an office building or hospital facility. | |
| Civil Structure | A built structure other than a building. E.g. a pump station, offshore platform or water treatment facility. | |
| Group of spaces | A grouping/clustering of spaces that forms a functional whole. E.g. a department or an entrance area. | |
| Space | A room or area inside a building or civil structure with a specific function. E.g. machine room, meeting room or toilet. | |
| Outdoor space | An area outside of a building or civil structure with a specific function. E.g. playground, an embankment or a bus stop. |
Click here for an explanation for how to define spatial and locational objects.
Systems & elements
The systems and elements represent the technical parts of a project, typically of a structural, mechanical or electrical nature.
| System | An assembly or group of elements that serve a common purpose. E.g. ventilation system, building facade or traffic management system. | |
| Spatial element | A specific component or product that can be located in a space or connection segment. E.g. a power socket or furniture item. In an infrastructure project it may be a traffic light or a road sign. |
Click here for an explanation for how to define technical objects.
Objectives & principles
Objectives and principles are fairly abstract, high-level pieces of information that tell something about the overall ambitions for the project.
| Objective | An aim or goal that has to be achieved with the project. E.g. reducing costs or improving user experience. | |
| Design principle | General concept/requirement that applies to the project as whole. E.g. inclusive design or circularity. |
Click here for an explanation for how to define objectives and principles.
Users
Users concern the different types of ‘end users’ that will occupy, inhabit or use the building / infrastructure facility (e.g. visitors, employees, travellers) when the project is completed.
| User | A type of user that inhabits the building or uses the built structure. E.g. a pupil or visitor. In infra projects, it may be a car driver or passenger. | |
| Organization | An organization or organizational part that inhabits or uses the building/built structure. E.g. a tenant organization or other kind of stakeholder. |
User activities
User activities concern the tasks, processes and activities that people conduct in/on the built facility.
| User | A type of user that inhabits the building or uses the built structure. E.g. a pupil or visitor. In infra projects, it may be a car driver or passenger. |
User equipment
User equipment concerns the equipment that the facility’s users need for their daily activities. These items are typically not part of the project’s delivery scope, but design teams may still need to know about them because
| User equipment | A piece of technology or other kind of artefact that is being used by user. E.g. a CT-scanner or a particular type of lab equipment that has certain requirements concerning power or ventilation. |
All these different ‘user objects’ (users, user activities, user equipment) are of particular importance if you wish to describe and specify the functional purpose of your project.
Processes & activities
Processes and activities are objects that can be used to describe and specify the delivery process of the project. These are typically used for defining the scope of the activities that have to be performed by the design team/contractor.
| Process | A generic group of activities that has to be performed by the contractor or design team for delivering the project. E.g. technical design or project management. | |
| Process activity | A specific activity or task that has to be performed by the contractor design team. E.g. Requesting a planning permit or writing a project management plan. |
Deliverables
The deliverables relate to the above in the sense that they are typically the final and/or intermediate outcomes of these processes and activities
| Deliverable | Document or other kind of artefact that has to be delivered by the contractor or design team. E.g. a BIM model or warranty certificates. |
Click here for an explanation for how to define requirements for processes and deliverables.
Services
These are objects that represent a process or service that has to take place/delivered during the operational / use phases of the project.
| Service group | A generic group of services that must be provided 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 service objects are of particular relevance in DBM (Design, Build & Maintain) projects and other integrated tenders where requirements do not only concern the built structure, but also maintenance, cleaning, security and other kinds of services.
Click here for an explanation for how to define requirements for services.
Properties
Each of the objects mentioned above can have its own set of properties. A property is a characteristic or intrinsic quality of an object. The properties for a space can be things like size, height or ambiance. Physical elements may have properties like material, color or durability. And processes can have properties like frequency or method.
Perhaps this is self-evident, but each property represents a requirement (which is also why they all get a requirement ID in BriefBuilder, see image below). So, for example, if a meeting room has a property called floor area and a value of 30 m2, this means that the meeting room should be at least 30 square meters in size.
It is a bit theoretical, but understanding the difference between objects and properties is important (as it can help you to define better requirements).
For example, when specifying the number of power sockets in a meeting room, you may be tempted to create a property for that room called “Number of power sockets”. The software does not stop you from doing so, but it is better to define power socket as a separate object (see here how to do that) and to link it to that room. The benefit of doing is so is that this will allow you to define properties for the power socket (e.g. type or make) and to link it to other spaces in the model.
In BriefBuilder you can define properties yourself, using the following attributes:
Name
The name of the property, indicating the quality or topic for which you want to define a requirement. For example, ‘energy usage’ or ‘floor area’.
Description
Some explanatory words about the property. Preferably, it concerns a formal definition from an accepted standard (e.g. an ISO or EN standard). For example, an explanation of how the aforementioned property ‘floor area’ should be measured.
Comparator
A symbol (>, <, =, etc.) that defines the status of the property’s value. Does it, for example, concern a minimum value (e.g. floor size > 30 m2) or a maximum value (e.g. temperature level < 20 oC).
Unit of measure
The unit in which a value is expressed. For example: is the property value for floor size referring to square meters or square feet?
The idea of using these four attributes is to be as clear and precise and explicit as possible about what is asked for. It is also a way of making requirements ‘computer-interpretable’ and useful as input for BIM models and parametric design tools.
In BriefBuilder, we make a distinction between standard properties and custom properties. Standard properties are the properties that you can pre-define in the settings menu. Custom properties are those that you add manually for an individual object.
Relations
As explained in the introduction of this entry, objects in BriefBuilder can be related to another in various ways. A room may, be example, related to another room, to user types , to spatial elements and to the activities it needs to facilitate.
The most basic relation in BriefBuilder is the assembly relation that is being used in all the trees. It captures a whole-part relationship, such as subdividing a building into spaces, or a system into elements.
All other relations concern relations between different kinds of objects. The relation between a space and a user is, for example, an accommodation relation (the space must be able to accommodate a particular kind of users). Likewise, the relation between a spatial element and a space is a location relation (spatial elements like walls and doors must be located in particular spaces).
In some cases, relations can have attributes like quantity or distance. The proximity relation between two spaces may for example stipulate that the max. distance between them should be 25 meters.
Each relation is represented by a table on the detail view of an object. You simply create the relation by clicking on ‘select object’ and select the object of your liking.
Summarizing
In BriefBuilder, requirements are not captured in text, but in a model of objects, properties and relations. By doing so, requirements become explicit rather than implicit. Moreover, they become interpretable for computers, which provides much better opportunities to integrate requirements into the design and engineering process.