Design patterns for a Systems Engineering model for verification in the construction industry

In the construction industry, the methodology of Systems Engineering (SE) is gaining more and more interest to help manage the complex reality of a project. A fundamental pillar of SE is the process of verification, however it’s often difficult to establish the right pattern of verifications for your project. This article helps provide you with insight in how Relatics can be applied to support the process of verification for construction projects and proposes different solutions in Relatics.

Relatics can accommodate the most simple to the most state-of-the-art solutions for systems engineering projects. But, as every large project has its own characteristics, there is no such thing as a one-solution-fits-all-projects. Please note that this article was not intended as a menu with a limited number of prescribed solutions to choose from. Instead, read it as a source of inspiration for developing your own solutions for verification.

This article mainly uses the term “verification”, however feel free to read “inspection”, “test”, “review”, “evaluation”, etc. instead.

The first section develops a basic SE model in Relatics step by step. The sections following take this basic SE model as a starting point and make small adjustments. The consequences of these adjustments are investigated, and each section ends with a discussion about where the model is applicable.

The design patterns in this article are:


In any SE approach, requirements take a central position. This is why the relation <is imposed on> in the SE model below departs from [Requirement] and arrives in [System object].

Essential in SE is the concept of a system consisting of subsystems. Such a subsystem, in turn, consists of its own (sub-) subsystems. Recording this breakdown of a system results in a hierarchical structure called the system breakdown structure (SBS). A project team builds their SBS by creating <is part of> relations between SBS children and SBS parents.

The central question of verification is: to what extent do we comply? As a first attempt to keep track of this, a property {Verification} is defined with values “OK” and “NOK” representing the possible outcomes of an executed verification.

Suppose that a requirement is imposed on different system objects. A requirement can be marked as verified not before each of the involved objects is addressed. As a result, the verifying of a requirement may be splitted across different places and/or different moments. In that case, one property {Verification} is too limited to keep track of the verification of the requirement.

In the SE model below, the {Verification} property is replaced by a <was verified for> relation. This supports recording precisely which system object have been addressed in verifying a requirement.

A team member who verifies can just state that a requirement was verified for a specific object (and record as such) but to convince others, additional evidence may be desired. To facilitate this, the next section develops the above SE model one step further.

SE model
The SE model that has been introduced above is still a bit too limited for complex projects, because it does not support to record evidences. For this reason, the <was verified for> relation is ‘exploded’ into a so-called middle element.

The property {Evidence} is not fully developed here, but it shows the idea: for each verification, the project team is able to record evidence.

It may seem redundant to include both the <is imposed on> relation and the [Verification] element in the SE model. After all, after the project is finished, all <is imposed on> relations can be derived from the verifications. However, it is important to note that requirements are typically entered and imposed on system objects prior to planning (let alone executing) verifications. In the initial stages of the project, the project team can only rely on the <is imposed on> relation and thus it cannot be left out of the SE model.

Now [Verification] is modeled as middle element, the possibilities are endless. For example, properties {Phase} and {Method} can be added to [Verification] to enable the project team to verify a requirement for the same system object in different project phases using different methods. With a <is executed by> relation, the project team can record who has to execute which verification. In general, the project team can record additional information around a verification as they like.


  • The above screenshot shows two properties “Status” and “Outcome”. One could consider merging these two properties into one single property “Outcome” with values “Open” (default), “OK” and “NOK”.
  • Users do not want to be constantly confronted with failed verifications. However, they also do not want to delete them completely, as these may provide valuable insights later in the project. To address this dilemma, an elegant solution is to enable auto-archiving. Failed verifications are automatically moved to the archive, reducing the attention they attract from users while still keeping them accessible.

As explained in the previous, an SBS is structured along a course-to-fine decomposition and helps to understand and overview a system and helps in communicating requirements. This is why project teams often use an SBS framework to organize their requirements. In fact, some clients even require contractors to use their SBS.

When the client requires a project to follow an SE approach, the contractor has to deliver a so-called verification matrix. A verification matrix provides an overview of the project’s requirements and evidence about to which extent these requirements are met.

The prescribed SBS and verification matrix make that the above design pattern is widely applied, especially among project contractors. It allows recording verification results in both a very specific and comprehensive way.


In the previous section, [Verification] was defined as a middle element between [Requirement] and [System object]. This was possible because the <has scope> relation was defined with single-cardinality. That is, a verification could have no more than one system object. In the next section, we investigate the implication of defining the <has scope> relation with multi-cardinality.

SE model
When the <has scope> relation has multi-cardinality (instead of single-cardinality), it allows different system objects to be the scope of the same verification.

Now the <has scope> relation has multi-cardinality, [Verification] cannot stay a middle element any longer. Instead, we redefine it as a so-called derived element of [Requirement].

Generating a verification matrix in this SE model is still possible. The only difference with section Design pattern 1 – Completeness, is that the same verification will appear at different crosspoints.

Suppose there is a requirement about the minimum height of lampposts. After installing 56 lampposts, it may not be necessary to verify each one individually for compliance. Instead, verifying a representative set of seven lampposts would sufficiently mitigate the risk and the project can spare the effort of verifying the remaining 49. The keyword here is “risk-driven”. Compare this to the SE model of Design pattern 1 – Completeness in which a project would be ‘forced to fill in’ each of the 56 verifications, with 49 of the registered OKs being artificial and even questionable.

Ensure that the project team desires to have most of their verifications related to more than one object and that all team members are aware of this multi-cardinality. Otherwise, a user may step into the following ‘trap’. Suppose one of the lampposts is installed too deep into the ground, causing it to not comply with the height requirement. An unaware team member verifying the lamppost, may fill in a NOK in the according verification. As a result, all the other lampposts in the verification’s scope are also registered as NOK, even though these were actually OK. Therefore, it should be a rule of thumb that a verification has different system objects as its scope. If this is more of an exception than a rule, one should consider the SE model of Design pattern 1 – Completeness.

It is not a matter of all or nothing. For example, when one of the lampposts does not pass a verification, it can be excluded from the verification’s scope. In practice, a project team will plan a new verification and include the failing lamppost. After the lamppost is fixed, the project team can make another attempt to get it verified successfully.

A reason to fall back to the SE of Design pattern 1 – Completeness is when there is significant information that has to be recorded per object and therefore cannot be recorded per verification. For example if it is desired to record an evidence for every lamppost that is verified, than the SE model of Design pattern 1 – Completeness is probably more suitable.

Especially when the contractor is co-responsible for the project’s overall success, they should have a voice in what verifications to execute and which can be ‘skipped’. For example, in a Design & Construct (D&C) contract, contractors share much responsibility even after a construction has been delivered. The design pattern presented in this section is a good starting point in these settings.


In the SE model of Design pattern 1 – Completeness, the <is imposed to> relation between [Requirement] and [System object] had multi-cardinality. That is, a requirement was allowed to have relations to different system objects simultaneously.

Suppose the <is imposed to> relation is changed from multi-cardinality to single-cardinality. As a result, a requirement can have only one system object (at most). Note that this makes the relation between [Verification] and [System object] redundant. After all, if a verification has exactly one requirement as its origin (no more, no less) and this requirement can have only one system object related, then it is already known which system object is being verified. Therefore, the relation between [Verification] and [System object] is unnecessary and should be left out of the SE model. Instead of a middle element, the type element [Verification] can and should be defined as a derived element.

SE model

One can wonder, what if a requirement is imposed on more than one system objects? Having several ‘copies’ of the same requirement is obviously not the way to go. After all, managing multiple instances of the same piece of information leads to contradictions and mistakes, which in turn makes the project overdue and be confronted with failure costs.

So, how should a project team process a requirement that is imposed on different system objects? There are three options:

  • Maintain copies. Before dismissing the idea of copying a requirement, one should consider whether it is actually the same requirement that relates to different system objects. Suppose that the CEO’s aquarium is required to be placed at a height of 100 cm. And suppose that the handles of all doors in the office are required to be at a height of 100 cm also. Should the CEO’s desire to raise the aquarium by 10 cm affect the door handle heights? The answer is no. It is a matter of coincidence and the two requirements that mention a height of 100 cm are unrelated. They should be managed separately, despite their apparent similarity.
  • Move up higher in SBS. Suppose, for example, that the entrance gate on the east side of a campus is required to have a minimum height of 320 cm to guarantee that ambulances can pass through. The same minimum is required for the height of the exit gate on the west side. This is not a matter of coincidence. In fact, both gates are part of the larger traffic system. Therefore, the project wants to manage only one “height > 320 cm” requirement related to the traffic system higher up in the SBS hierarchy.
  • Identify as interface. Suppose an architect designs an office with a canteen on its top floor. The dishwasher in the canteen needs annual maintenance. During this time, a temporary dishwasher from the maintenance company replaces it. The requirements for the size of the dishwashers should be compatible with the minimum room size of the elevator. The cleaning machine and the elevator do not have a common higher-level system. This is an example of a system interface between the elevator and the dishwasher. It would take too far to cover system interfaces in this article, but one should consider verifying from a system interface’s context instead of verifying separate requirements.

In the previous section, the solution with the “320 cm” requirement was to move it higher op in the SBS. Easily said but, an SBS does not always contain a suitable system object on higher levels. Therefore, engineering requirements and designing and restructuring the SBS proceed hand in hand in practice. This approach results in a very clean SBS, but it requires extra efforts. Furthermore, the project team should possess specific skills to manage the SBS effectively. So why bother?

A clean SBS is very useful for gaining a better understanding of a system. This is true for clients in particular, for they tend to formulate their requirements at a higher, more abstract level compared to contractors. This is why clients are very keen on a well-structured SBS. At that, a clean SBS dramatically increases the quality of communication about requirements, both during the tender phase and after the project has been awarded. These are aspects why clients may prefer the pattern in this section over the other patterns.

Specification focus

In the SE model of section Design pattern 1 – Completeness, the <is imposed to> relation departed from [Requirement] and arrived in [System object]. Suppose this relation was defined in the inverse direction.

The idea is that a relation is owned by the element it departs from. So, while in Design pattern 1 – Completeness the relation <is imposed to> was owned by [Requirement], now [System object] is owning the relation.

How subtle it may seem to switch a relation’s direction, the implications may be significant. To give an idea:

  • When a system object is copied along the SE model above, the copy of the system object has relations to the same requirements as the original system object. Compare this to Design pattern 1 – Completeness. There, relations were only copied if a requirement was copied; a system object was copied without its relations.
  • A requirement cannot be deleted, as long as it has relations with a system object. Again, compare this to Design pattern 1 – Completeness. There, a requirement could be deleted, with or without relations, while a system object could not be deleted as long as it had relations.

Following the reasoning when introducing Design pattern 1 – Completeness, imagine a very primitive process of verification where just a property {Verification} would be enough to record everything desired. Which of the two elements [Requirement] or [System object] should {Verification} be a property of? Now that [System object] is the ‘new’ owner of the relation, it would be straightforward to also define {Verification} as a property of [System object]. In essence, these adjustments reflect a shift from engineering to a focus on ‘given’ specifications.

SE model
The previous section explained why making [System object] the owner of the <is specified by> relation implies a specification focus (instead of an engineering focus). A typical use case for the project team would be: a bicycle tunnel has to be inspected; what are its specifications? The image below suggests an SE model.

Comparing to Design pattern 1 – Completeness, note:

  • While [Verification] had [Requirement] as its origin, now [Inspection] has [System object] as its origin. The implications are similar to what was explained in the previous; copying/deleting a system object will also copy/delete its inspections (as opposed to Design pattern 1 – Completeness, where copying/deleting a requirement resulted in copies/deletes of verifications).
  • In fact, the whole ‘triangular’ around [System object] has been mirrored compared to Design pattern 1 – Completeness.
  • [Inspection] can be modeled as either middle element or derived element. As a middle element, each Inspection should always have one requirement as its criterion. When modeled as a derived element, the user can decide per inspection to have none, one or more requirements.

Similar to section Design pattern 3 – Purity, one could wonder whether it is okay to have the same requirement specifying different system objects. If not, the image below suggests an alternative SE model, where [Requirement] is a derived element of [System object].

When a system is more tangible and requirements are more detailed, a project team might have a specification focus instead of an engineering focus. For example, if the client has already completed the design and engineering work, a contractor solely executes specifications. In The Netherlands, contractors of RAW contracts follow a specification-focused approach.

In general, a contractor working in a Build-only project (as opposed to a D&C project) may prefer the above design pattern. Additionally, this pattern is also highly applicable in the fields of maintenance and asset management. This is because also in these fields, objects are real and tangible and requirements, designs and drawings are more detailed and less abstract.


Clients may have requirements not only about system objects, but also about processes. Not surprisingly, also these process requirements have to be verified. In the next, the SE model of Design pattern 1 – Completeness is taken as a starting point and expanded to support the verification of both system requirements and process requirements.

SE model
The image below depicts how the <is imposed on> relation from Design pattern 1 – Completeness is ‘upgraded’ to a collection relation arriving in both [System object] and [Process].

By doing so, [Requirement] is made one step more generic in that it allows recording both system requirements and process requirements along the same type element. Analogously, the <has scope> relation was upgraded to a collection relation.

Please note:

  • Unless the <is imposed on> relation has single-cardinality, the same requirement can be related to both a system object and a process. This implies that this requirement is both a system requirement and a process requirement, which is probably undesirable. Although the chance that a project member will enter this is minimal, still the SE model allows it.

Why bother setting up a large and formal SE model, while the project team can do with a small, simple one? The collection relation <is imposed on> in the above SE model is applicable for a project where work and verifying in particular proceed similarly, regardless of whether it involves system requirements or process requirements. The SE model is pragmatic and lean and can easily be further expanded with other ‘things’ that have requirements that have to be verified. It is particularly useful for smaller, more informal projects.

For larger and more formal projects however, a more extensive SE model may be necessary. In this type of project, the client and contractor agree on the verifications in an early stage. For example, the methods used for verifications are negotiated. As one can imagine, process requirements require different verification methods than system requirements. And process verification may differ from system verification on other aspects than method, for example planning, desired expertise etc. For this reason, most SE models include different type elements [Process verification] and [System verification]. Typically, large projects have separate type elements [Process requirement] and [System requirement] in the first place.


When specifications have been developed to a great extent and/or the project is about realized construction objects like in the fields of Maintenance or Asset management, [System object] is best related to [Requirement] by a <is specified by> relation, departing from [System object] and arriving at [Requirement]. In that case, [Verification/Inspection] has [System object] as its origin (refer to Design pattern 4 – Specification).

On the other hand, when requirements are defined at a higher, more abstract level, then a project probably desires a <has imposed on> relation from [Requirement] to [System object]. They may define this relation with single-cardinality and model [Verification] as a derived element (refer to Design pattern 3 – Purity). Especially from a client’s perspective, this design pattern is very applicable.

When requirements get less generic and the involved system objects get more tangible, it may be desired to relate different system objects to the same requirement. In this case, the <has imposed on> relation has multi-cardinality (refer to Design pattern 1 – Completeness).

When a project team decides to follow a risk-driven approach, they smartly pick which verification to execute (and which they skip). On the other hand, the team can decide they don’t want to bother and just verify each combination of a requirement imposed on a system object. In the former case, the project team can save themselves a lot of recording efforts by modeling [Verification] as a derived element of [Requirement] with a <has scope> relation with multi-cardinality (refer to Design pattern 2 – Efficiency). In the latter case, [Verification] modeled as a middle element is a powerful solution (refer to Design pattern 1 – Completeness).

As a final word, this article offers different design patterns that offer direction and may inspire a project team when setting up their SE model. However, feel free to experiment and resist the urge just to pick one of these patterns and take it over in a project workspace without consideration. It cannot be said too often: there is no one-model-fits-all-projects solution. Therefore, cherry-pick aspects of different constructions and combine them to fully tailor the Relatics workspace to the project’s needs.

Relatics is the leading Model-Based Systems Engineering software application for construction projects. It is the comprehensive tool that gives professionals access to all project information and offers insight into the growing number of dependencies between all disciplines in today’s projects.

This article is a common practice and is the result of years of experience gained by our consultants in the field. Should you wish to implement this knowledge in your own projects and require assistance, please do not hesitate to contact us. Our consultants are ready to provide you with the support you need.

In this article
Please enable JavaScript in your browser to complete this form.

Download the whitepaper

Please enable JavaScript in your browser to complete this form.

Download the whitepaper

Request a demo

Fill in the below information and we will contact you to schedule a demo.

Please enable JavaScript in your browser to complete this form.
We will use this information to contact you.
Please enable JavaScript in your browser to complete this form.
Please enable JavaScript in your browser to complete this form.

Get in touch

Fill in our form and one of the Relatics members will contact you as soon as possible. Do you prefer contact by phone? Please call us at +31 180 413 047.
Please enable JavaScript in your browser to complete this form.