What does a good BIM requirement look like? Part II

13.10.2022

In part one of this blog series we covered the first four simple questions you can ask to assess how good your BIM requirements are. In part two of this blog series, we’ll take a look at a further four criteria for a good BIM requirement.

5. Are the data and format separated?

Requirements most often have two components: one about information and another about the format. For example:

Information: Rooms must have a name.

Format: Rooms must be exchanges as IfcSpace objects and the name of the room with the IfcSpace.LongName attribute.

BIM authors usually understand the information component very well but struggle with the format. In a good BIM requirement these two components are separated and the requirement for the format is minimized.

In the future we can simplify the requirement even further. Imagine a system that can find the room name from any property of the room object. When such a system exists, the requirement can be simplified to be: the name of a room can be exchanged using any attribute.

6. Can the requirement be validated programmatically?

Validating requirements that have been met is a crucial part of a well-functioning process. It makes sure that the BIM author has delivered what has been promised.

This also solves the question of responsibility, because the BIM author is responsible for delivering models that meet the requirements and after this the responsibility for using the models switches to the BIM user.

In practice, the only solution is to validate models programmatically, because otherwise the trust in the models, and with it their usability, erodes. For example:

The requirement is that all walls have a type that has been agreed in the project. The quantity surveyor gets, for the 3rd time, a model where half of the types are missing, or the values are clearly wrong. The quantity surveyor decides not to use that information at all.

However, not everything can be validated, and we must trust something. If there was, for example, a system that could validate that all wall types have been assigned correctly, then that same system could also assign the wall types. This again would lead to a situation, where we could drop the wall type information from the requirements.

7. Is the reason for the requirement documented?

When the reasoning behind the requirements has been documented, we can always look at the requirements critically and they can evolve.

Current BIM authoring tools have, for example, shortcomings that we must consider and live with. We can’t require anything that is currently impossible or too difficult to do.

For example in 2007, the requirement below was still valid. However, with current applications modelling slanted pipes is now possible:

Sewage pipes can be modelled horizontally because at the time this requirement is written, it is not technically possible to model them slanted.

When software evolves the requirement should be changed because the real position of pipes is useful information for example, for clash detection. If the original reason for the reduced requirement was no longer known, it would be more difficult to react to changed circumstances.

8. Is the derived information required?

Models have both original (master) information and derived information. For example:

Master information: An object has two properties: it is a wall and it is located in the exterior shell of the building.

Derived information: The OmniClass number for exterior walls is “21-02 20 10”.

We should only require original information, such as: it is a wall and it is located in the exterior shell of the building.

Derived information, such as the OmniClass number for exterior walls is “21-02 20 10” does not add any new information to the exchange and thus it must not be required.

In principle, measurement or quantities that are derived from geometry and requiring only the geometry should be enough.

When derived information is required because of shortcomings in the software used by the BIM user or their lack of skills, this should always be done knowingly. In all cases, we need an analysis of what information is original and what is derived from that original information.

Summary

In this two part blog series we covered eight criteria for good BIM requirements. You learned eight simple questions you can ask to start making your requirements better.

However you can only implement best possible BIM requirements, if you have the right tools and workflows in place.

Simplebim is the best tool available to make this happen, because unlike many other open BIM tools, it was created keeping these eight criteria in mind.

Do you want to learn more? Book a demo. We are happy to help.