Traditionally, requirements are captured in voluminous pdf documents—piles of them. At BriefBuilder we do this differently. We take a model-based approach. Sounds nerdy? Don’t worry. It’s not. Or perhaps a bit. Let’s explain.
Text versus model
The AEC industry is undergoing a digital transformation, with artificial intelligence, robotics and generative design technologies radically changing the workflows of architects, engineers and contractors. On the client side, however, it is awfully quiet. Especially when it comes to the development of project briefs, little seems to be happening. In most projects, construction clients still capture their requirements in large text documents, in very much the same way as they did decades ago.
The problem with these documents is that they tend to be ill-structured and that their contents aren’t actionable. Requirements that are locked in a pdf cannot be integrated into BIM models, cannot be systematically verified and cannot be checked for completeness. Nor can they be reused in a more intelligent way than by copy-pasting texts from one document to another.
That is why we have developed an alternative: capturing requirements in an integrated requirements model. Let’s use a simple example to explain what this is.
In a traditional brief, you will find sentences like these:
“The entrance for the visitors should be at least 200 sqm in size. The area should be connected to the restaurant and the cloak room, and it should feature turnstiles and card readers.”
These are just two sentences, but they are packed with requirements. The central idea of a model-based approach is to make these requirements explicit, by creating objects (the entrance), properties (the entrance’s size) and relations to other objects (in this case relations to the restaurant, cloak room, turnstiles and card readers). See the figure below.
The above is just a diagrammatic representation of how information is captured. In the BriefBuilder software itself, it is a simple matter of picking and choosing objects and filling in the appropriate fields.
The benefit of a model-based approach is that requirements become actionable: you can more easily and systematically analyse, verify and re-use requirements. A practical advantage is that the requirements can easily be presented in different ways – in room data sheets, Excel-like overviews, or even bubble diagrams – all of these using the same data. It also enables you to exchange requirements with other applications. And, last but not least, it pushes clients to be precise and explicit about what they ask for.
Below, we will further explain BriefBuilder’s three main building blocks:
- Objects
- Properties
- Relations
Objects
An object can be understood as an ‘entity’ with distinct properties. Obvious examples are physical or spatial objects like walls or rooms, but also users or user processes can be seen as objects. In BriefBuilder, we have different kinds of objects which can all carry requirements. Some of the most important ones:
- Location: a geographical area or site where a built asset is located or must be realized.
- Connection: an infrastructural connection between two points. E.g. a road, a rail track, or a cable corridor.
- Space: a room or area inside or outside a built facility. E.g. a machine room or a meeting room.
- System: an assembly of elements that serve a common purpose. E.g. a ventilation system.
- Element: a specific technical entity with a location. E.g. a power socket, a traffic light, or a road sign.
- User: the end users or stakeholders of the built facility. E.g. the occupants or operational staff.
- Process: a specific activity that must be performed by the contractor. E.g. demolition activities.
- Service: a service that must be provided during the operational phase. E.g. cleaning or maintenance.
This is just a selection of object types, but it gives a good overview of the diversity of objects that can be captured in BriefBuilder.
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. Elements may have properties like recyclability or capacity. In BriefBuilder you can define properties yourself, using the following attributes:
- Name: the name of the property. For example, ‘energy usage’ or ‘floor area’.
- Description: a definition of what the property entails or a reference to a standard (e.g. an ISO norm).
- Comparator: a symbol (>, <, =, etc.) that defines whether it is e.g. a minimum or maximum requirement.
- Value: the required property value, which can be quantitative (e.g. 30 m2) or qualitative (e.g. ‘easy to clean’)
- Unit of measure: the unit in which a value is expressed. E.g. square meters or square feet.
The idea of using these attributes is to be as clear and precise as possible when formulating a requirement. It is also a way of making requirements ‘computer-interpretable’
Relations.
The last building block of a model-based approach are the relations between objects: how should things hang together, so to speak. Some of the most important ones:
- Assembly relations: specify the whole-part relation between objects, e.d. that road should consists of two car lanes and one bicycle lane.
- Location relation: specify the elements that should be located in a space, e.g. that a meeting room should locate a prestation screen.
- Accommodation relation: specify the users that should be accommodated in a space, e.g. that a class room should be able to accommodate 25 pupils.
- Interface relation: specify the technical interrelations between systems, e.g. between the building’s management system and the ventilation system.
- Adjacency relations: specify how spaces should be positioned in relation to one another, e.g. that the cloakroom should be close to the entrance.
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.
Summarizing
In BriefBuilder, requirements are not captured in text, but in a model of objects, properties and relations which are captured in an online model. This means no more endless badly written texts, but crisp-and-clear requirements in a digital format. This helps client to create better briefs and it provides better opportunities to integrate requirements into the design and engineering process, which reduces the risk of design defects and quality problems.