Design patterns

Table of Contents

Verifications

One of the main objectives of Systems Engineering (SE) is compliance. The process of verification plays a key role in achieving this, as it formalizes the detection of failures and ultimately provides evidence that all requirements have been met. This model pattern mainly uses the terms verification and inspection, however feel free to read test, review, evaluation, etc. instead.

In any SE approach, requirements hold a central position. This is why the type relation in the SE model below originates from Requirement and leads to System Object. A key concept in SE is the idea of a system composed of subsystems, each of which, in turn, consists of its own (sub-)subsystems. Recording this breakdown creates a hierarchical structure known as the System Breakdown Structure (SBS). A project team constructs their SBS by establishing is part of relationships between SBS children and SBS parents.

In practice, the same object is often verified multiple times against the same requirement. The SE model allows each verification to be recorded as a distinct element.

Including both the is imposed on type relation and the Verification type element in the model may initially seem redundant. After all, once the project is complete, all is imposed on relations can be derived from the verifications. However, it is important to understand that requirements are typically defined and assigned to system objects before planning (let alone executing) verifications. In the early stages of a project, the project team relies solely on the is imposed on relation, making it an essential part of the Systems Engineering model.

The Verification type element allows a project to record how compliance is achieved, along with supporting evidence. While the Evidence type property is not fully developed here, it serves to illustrate the concept. Additionally, Verification can be expanded with details such as the planned or actual execution dates, the methods used, and the responsible parties, among other information.

In the screenshot, you can see an overview that groups verifications by requirements and objects. This grouping is typically the result of defining Verification as a middle element.

Variation: Instead of maintaining two separate type properties, Status and Outcome, you could consider merging them into a single property called Outcome with values such as Open (default), OK, and NOK.

Efficiency

When the has scope type relation between Verification and System Object is set to allow multi-cardinality, it enables different system objects to share the same verification as their scope.

As shown in the image, Verification can no longer remain a middle type element with the multi-cardinality of the has scope type relation. Instead, Verification is redefined as a derived element of Requirement.

This model is particularly useful for project teams that want to execute verifications in a more sophisticated manner, rather than methodically working through extensive lists of checks.

Example: Suppose there is a requirement for 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 sample of seven lampposts may sufficiently mitigate the risk, saving the effort of verifying the remaining 49. The key concept here is “risk-driven”.

Compare this approach to the model as shown in the pattern “The basics“, where the project would be compelled to complete all 56 verifications, with 49 of the registered OKs being artificial and even questionable.

However, this approach requires a certain level of skill among the project team members. For example, suppose one lamppost is installed too deep into the ground and fails to meet the height requirement. A team member might naively mark the entire verification as NOK even though the other lampposts in the scope comply with the requirement.

Solution: To handle this, isolate the non-compliant lamppost from the others by creating a new, separate NOK verification. Move the failing lamppost(s) from the OK verification to the new NOK verification. Additionally, you would likely create a second new verification to re-verify the lamppost after it is fixed.

While this verification method can save significant effort, it demands careful consideration and skill from the team. In general, it should be part of the team’s collective understanding that a verification can have different system objects within its scope. If such multi-object scopes are more the exception than the rule, it may be better to adopt the previous model.

Purity

In this SE model, the is imposed on type relation from Requirement to System Object is changed from multi-cardinality to single-cardinality. As a result, a requirement can be associated with only one system object at most. Note that Verification is modeled as a derived element. In this setup, a verification has exactly one requirement as its origin—no more, no less.

Since each Verification is tied to a single Requirement, and each Requirement can be related to only one System Object, the System Object being verified is inherently known. Therefore, there is no need for a direct relation between Verification and System Object.

One might wonder: what if a requirement applies to more than one system object? Simply creating multiple copies of the same requirement is clearly not the solution. Managing multiple instances of identical information introduces contradictions and errors, which can lead to project delays and failure costs.

So, within this model, how can a project team handle a requirement that applies to multiple system objects? Here are three possible approaches:

Option 1 – Maintain copies:
Before dismissing the idea of copying a requirement, consider whether it truly represents the same requirement for different system objects. For example, suppose the CEO’s aquarium must be placed at a height of 100 cm, and all door handles in the office must also be installed at 100 cm. Should the CEO’s decision to raise the aquarium by 10 cm affect the height of the door handles? Clearly, no. Despite the similarity, these are unrelated requirements and should be managed separately.

Option 2 – Identify as an interface:
Consider an architect designing an office with a canteen on the top floor. The dishwasher in the canteen requires annual maintenance, during which a temporary dishwasher replaces it. Both the permanent and temporary dishwashers must meet size requirements compatible with the elevator’s minimum room dimensions. In this case, the dishwasher and the elevator lack a common higher-level system but interact through a system interface. Verifications should occur in the context of the system interface rather than as separate requirements.

Option 3 – Move up higher in the SBS:
Suppose the entrance gate on the east side of a campus must have a minimum height of 320 cm to accommodate ambulances. The same requirement applies to the exit gate on the west side. This is not a coincidence; both gates belong to a larger traffic system. In this case, the project should manage a single “height > 320 cm” requirement at the level of the traffic system higher up in the SBS hierarchy.

The third approach, “move up higher in the SBS”, is often easier said than done, as the SBS does not always contain a suitable system object at higher levels. Therefore, defining requirements and designing and restructuring the SBS should proceed hand in hand. This process requires additional effort and specific engineering expertise. So, why go through the trouble?

The effort can be worthwhile because this method typically results in a cleaner SBS. A clean SBS improves understanding of the system, particularly for clients, who often define their requirements at a higher, more abstract level than contractors. Clients value a well-structured SBS because it enhances communication about requirements during both the tender phase and post-award phases of a project. This increased clarity and improved communication quality are among the reasons clients may prefer this approach over others.

Specification focus

This model is suited for situations where a project aims to inspect whether object(s) comply with their given sets of specifications.

When the actual engineering of requirements is not within the scope of a project, there is no added value in reusing different requirements across multiple system objects. Therefore, Specification is modeled as a derived type element.

To illustrate the implications:

  • When a system object is copied in the model above, the copy inherits the same specifications and inspections as the original system object.
  • When a system object is deleted, its associated specifications and inspections are deleted as well.

For example, if the client has already completed the design and engineering work, a contractor may be responsible solely for executing the specifications. In the Netherlands, contractors working under “RAW” contracts typically follow a specification-focused approach. Generally, contractors on a Build-only project (as opposed to a Design & Construct project) may prefer this design pattern. Additionally, this pattern is highly applicable in the fields of maintenance and asset management, where objects are physical and tangible, and requirements, designs, and drawings are more detailed and less abstract.

Lean

Clients may have requirements not only for system objects but also for processes. Naturally, these process requirements must also be verified. So why set up a large, formal SE model when the project team could use a smaller, simpler one?

In this model, the is imposed on type relation is a collection relation that applies to both System Object and Process.

Similarly, the has scope type relation from Verification is also a collection relation. This allows both system and process requirements to be recorded within the same type element. However, note that the same requirement can be related to both a system object and a process, meaning that this requirement is considered both a system requirement and a process requirement simultaneously.

This approach may be suitable for smaller, more informal projects, where the risk of project members incorrectly entering such data is minimal. It may align with the project’s way of working, especially if the verification process proceeds regardless of whether it involves system or process requirements. In such cases, the lean SE model presented here is pragmatic and can easily be expanded to include other entities that have requirements (and therefore need to be verified).

For larger, more formal projects, however, a more explicit model may be necessary. In these projects, the client and contractor typically agree on the verifications early on, including negotiating the methods used for verification. As you can imagine, process requirements require different verification methods than system requirements. Additionally, process verification may differ from system verification in areas beyond methods, such as planning, required expertise, etc. For these reasons, most Systems Engineering models include distinct type elements like Process verification and System verification. Typically, large projects also separate the elements Process requirement and System requirement from the outset (refer to the Systems Engineering pattern on requirements).

Relatics is the leading Model-Based Systems Engineering (MBSE) 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.

The aim of this article, part of a series of articles, is to provide you with basic knowledge about Systems Engineering elements and its application within the Relatics 6 software. Should you wish to proceed with Relatics 6 on 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. If you miss an SE pattern in this series, please let us know.

Pioneers in Systems Engineering [book]
Insights from 50 professionals from the Dutch construction industry.

Download our free whitepaper with 7 success factors for implementing Systems Engineering on your project.

Download our free whitepaper to discover why construction projects still struggle with failure costs.

Request a demo

Fill in our form and one of our colleagues will contact you as soon as possible to schedule a demo.

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

Download the whitepaper

Please enable JavaScript in your browser to complete this form.
Addresss

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.