Methods to specify information requirements in digital construction projects

Comparison criteria

Before we did the comparison, we defined the criteria for it. The choice was built on standards and available use cases that can be found in the buildingSMART’s Use Case Management Service (UCMS). Below is the summary of our comparison criteria:

• Standardised – is the method formally defined in a standard?
• Applicability – can a requirement be assigned to elements it applies to, for example, a wall or a pipe?
• Fields
  • Information type – can a requirement query specifically for a property, material, or else?
  • Data type – can a field be required to be a text, number, boolean or else?
  • Unit of measure – can value be of a particular unit, such as kilogram?
  • Description – plain text descriptions are handy for unambiguous contractual definitions. Does the method allow for adding it?
  • References – The global community speak different languages, uses other units and has other names for similar concepts. What IFC calls ‘thermal transmittance’, the ETIM classification calls the ‘U-value’. While experts can interpret such ambiguities, machines and software developers can not, so references to a common standard are desired to help avoid misunderstandings.
• Value constraints
  • Equality – asking for exact literal values
  • Range – numerical values might be limited to defined range boundaries, as in the case of relative humidity, which is expected to be between 0 and 100 percentage units
  • Enumeration – allowing for multiple possibilities
  • Patterns – variance of notation validated using Regular Expression patterns. For example, a value should start with the letters XYZ followed by any capital letters
• Content
  • Existence – When no element matches applicability, whether the model should pass such validation depends on how a method specifies information existence. Propositional logic only deals with the truth value of propositions and logical connectives. Still, to fulfil use-cases needs, the method should also support first-order logic, allowing to make statements concerning a population by introducing universally (∀) and existentially (∃) quantified variables. For example, the universal requirement ‘all walls need a length property’ would be satisfied with the lack of any wall but fail if only one of many walls does not have a length property. In contrast, the existential requirement ‘a wall with a length property must exist’ would correspondingly result in opposite failure and success.
  • Documents – The requirement for content existence can also extend to documents such as attached files, drawings and images.
  • Structure – a requirement could specify how an element or data should be structured in relation to other objects. For example, is it enclosed in a larger assembly or contained within the spatial construct? Structure applies to spatial composition and how the data is structured in the model hierarchy.
• Geometry – Requirements can also refer to spatial information.
  • Representation – In many cases, it is sufficient that geometry is described with boundary representation or mesh, but in some, it is needed that representation describes embedded logic, explaining how the volumes were procedurally extruded. An example of such a requirement is the SIMBA use case from the Norwegian Statsbygg, which demands that the IfcSpace object extends from the upper surface of a floor slab to the underside of a slab above.
  • Detailedness – Information requirements can also demand a particular level of detailedness, meaning what needs to be modelled and to what precision. The more schematic model usually takes less memory and time to create, but a more granular one can provide more details necessary for the later design stages.
• Metadata – The context of a requirement is given by providing metadata.
  • Purpose – according to EN 17412-1, validation differs from general verification by having a specific intended purpose.
  • Actors – Some use cases need to specify an actor to assign the responsibility for fulfilling the requirement to a person or role.
  • Process map – use cases might derive requirements from workflows, so a method should support mapping a requirement to a process map with data exchanges.
• Other
  • Expressiveness – these include the expressiveness of standards, meaning the breadth of ideas they can describe and how ambiguous they are.
  • Dependency – on industry classifications and schemas that define the semantics
  • Technological agnosticity – the complexity of transcribing a standard from one file format or implementation to another. The European Interoperability Framework discourages over-restrictive obligations to use specific digital technologies.
  • Governance – Finally, there are questions about the method's governance: how it is managed, standardised and transparent, whether it is coordinated and how easy it is to influence change.

Comparison

Our results show that no single solution covers all the aspects of the analysis of use cases. Despite overlaps, each method has a different intended purpose and should be selected consciously. All described methods have reasons for existence and play an important role in the ecosystem. However, because their boundaries are hazy, they tend to be misused, causing disappointment and limiting digitalisation performance. We present a summary of the comparison in the two tables below. The first table shows aspects that are either supported, partially supported or not covered by a particular method. The second table shows a grouping of methods with regard to the criteria.

The differentiators identified by this research are explained in the next section.

Table 1. Information requirement support in the described methods.