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 documents (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 are physical or spatial objects like walls or rooms. But also abstractions, like an organization or a project objective, can be seen as objects. In BriefBuilder, we distinguish between the following types of objects:
Geographical objects
Geographical are objects that can be used to indicate or define the location of a building or infrastructure asset.
| Area | General geographical area or zone (e.g. a city district or university campus) that can contain multiple specific locations. | |
| Location | Specific site or plot where a built asset is located or must be realised. |
These geographical objects are typically the start of a spatial decomposition of the project (see below). They are mostly relevant for urban projects and infrastructure projects that encompass multiple assets that each have their own location.
Spatial objects
Spatial objects are objects that represents an area or volume that provide for certain user functions.
| Building | A building that needs to be build/renovated. E.g. an office building or hospital 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 with a specific function. E.g. meeting room or toilet. | |
| Outdoor space | An area outside of a building with a specific function. E.g. playground or park. In an infrastructure project it may a part of a terrain like an embankment or a busstop. |
Click here for an explanation for how to define spatial objects in BriefBuilder.
Technical objects
Technical objects are tangible systems or elements that are typically of a structural, mechanical or electrical nature.
| System | An assembly or group of elements that serve a common purpose. E.g. climate system or facade. In an infrastructure project it can be a bridge or tunnel. | |
| Spatial element | A specific component or product that can be located in a indoor or outdoor space. 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 in BriefBuilder.
Strategic objects
Strategic objects are abstract, high-level pieces of information that tell something about the overall direction of 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 in BriefBuilder.
Use objects
These objects represent the functional requirements for a project, explaining what kind of uses should be facilitated.
| 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 activity | An activity or process that has to be facilitated/accommodated in a specific space. E.g. teaching or office work. In an infra project it may be driving or parking a car. | |
| User equipment | A piece of technology or other kind of artefact that is being used by user. E.g. a CT-scanner or a xerox machine that has certain requirements concerning power or ventilation. |
Process objects
Process objects are objects that can be used to describe and specify the realization 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.
| 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. | |
| 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. |
Click here for an explanation for how to define requirements for processes and deliverables in BriefBuilder.
Service objects
An object that represents a process or service that has to take place/delivered during the operational / use phases of the project. Of particular relevance in DBM (Design, Build & Maintain) projects where requirements do not only concern the built structure, but also the process of maintenance.
| Service | A process that takes place during the project’s operational/use phase. E.g. maintenance or cleaning. |
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.