Design patterns

Table of Contents

Interfaces

Projects often identify and manage interfaces for objects that interact with other objects, both within and outside the system, in functional and physical domains. It is a common practice to include interfaces in the Systems Engineering (SE) model, as it helps to understand how interfaces impact elements across different disciplines within the project. This approach fosters collaboration and prevents individual disciplines or organizations from optimizing solely for their own needs. For example, it facilitates shared understanding and agreement on interface requirements and the management of interface actions.

Based on observations at projects, the basic model consists of a type element named Interface, which includes a type property to store the name. Typically, the type property Name has a data type of Single line text (to contain a brief title for recognizing the interface).

Regarding relations, an interface commonly includes a type relation called has lead to the type element Object. This relation identifies the object primarily responsible for the interface. In most projects, the cardinality for this relation is set to Single. This prevents ambiguity and ensures accountability, even when multiple disciplines are involved.

Additionally, the model contains a type relation called has supporting to the type element Object. Since an interface typically describes the interaction between two objects, this relation complements the has lead relation by identifying the secondary object involved in the interaction. Similar to the has lead relation, the cardinality of the has supporting relation is also typically set to Single.

Setting the cardinality of both relations to Single ensures that each interface represents an interaction between exactly two objects. This approach reduces complexity and enhances the manageability of interfaces in most projects.

Dependency

Some projects configure the type element Interface as a middle type element, with the has lead type relation as the Origin relation and the has supporting type relation as the Target relation. The main advantage of this model pattern is that an interface can only exist if it is linked to both a lead object and a supporting object. The reasoning is that an interface without two objects cannot be considered a true interface.

The disadvantage of this model pattern is the reduced flexibility it offers. If there is a valid reason to create an interface but not both objects are known, you cannot create the interface until both objects are identified, which could result in lost knowledge.

Therefore, whether you set the configuration of the type element Interface to standard or derived element depends on the level of strictness you wish to enforce in the model.

Scope

It is common for an interface to describe interactions between two occurrences of the same kind. In addition to the example of an interface between two objects, projects create interfaces for other subjects, such as contracts, disciplines, or parties. The subject of an interface depends on the project’s key area of the system that is sensitive to suboptimization.

Similar to the example of an interface between two objects, the model includes a type relation has lead between the Interface type element and the type element of the corresponding subject, with the cardinality set to Single. The same applies to the has supporting type relation.

Categorization

Many projects distinguish between internal and external interfaces. An internal interface describes the interaction between two objects within the project’s scope, while an external interface describes the interaction between an object inside the project’s scope and another object outside of it.

Object versus context objects

Projects often use the term Object to refer to an object within the project’s scope and the term Context object to refer to an object outside the project’s scope. While an internal interface involves both a lead and a supporting object, an external interface involves a lead object paired with a supporting context object. A project never describes the interaction between two context objects, as this falls entirely outside the project’s scope.

In the model, a type relation called has lead is typically created between the Interface and Object type elements, with the cardinality set to Single. Additionally, a type relation has supporting is created, also with the cardinality set to Single. The Range setting is set to Collection, and for the To type elements setting, both Object and Context Object are selected. As a result, a user can select both objects and context objects as the supporting elements for the interface.

Interface with scope property

Alternatively, some projects categorize an interface as either Internal or External. This model pattern is not widely used. While it offers the advantage of quickly filtering out either internal or external interfaces, it can overlap with or conflict with the actual related objects. Therefore, in practice, the use of related objects/context objects, as described in the example above, is preferred.

In the model, the type property Scope is typically created for the type element Interface. The Scope property usually has the data type List, with list values such as Internal and External.

Lifecycle

When tracking interfaces over time, it is often beneficial to add a Status property to the model with the data type List. Examples of list values include Actual and Rejected. This allows for filtering out irrelevant interfaces.

If some interfaces are expected to become irrelevant over time, it is advisable to configure the Status property as a Life cycle property for the Interface type element. This can be done by setting the Life cycle property of the Interface type element to the Status property. Additionally, by enabling the Auto archive setting and selecting the relevant archive values (e.g., Rejected), only relevant interfaces will be displayed by default in the views.

Responsibility

When multiple disciplines or organizations are involved in an interface, it is common to include responsibility in the model. This helps clarify who is responsible for taking the lead in specifying the interface and handling related issues and actions.

Persons

Most projects choose to assign responsibility for an interface to a person. This allows users to easily filter the interfaces for which they are responsible. Sometimes, a project considers using a project role instead of an individual person to assign responsibility, in anticipation of future changes in the project’s workforce. However, a major disadvantage of using a project role is that it becomes much harder to track exactly which person was responsible for an interface at a specific time in the past. Therefore, it is recommended that responsibility for an interface be assigned directly to a person.

In the model, a type relation has responsible is created between the type elements Interface and Person. In most cases, the cardinality of this relation is set to Single. Allowing only one person to be stored as responsible for the interface ensures clarity about who is the point of contact for follow-up actions related to the interface.

Persons of different subprojects

If a project is organized into multiple subprojects (e.g., multiple contracts), individuals from different subprojects may be involved in an interface. For example, the lead object could belong to one subproject, while the supporting object belongs to another. In such cases, it can be beneficial to track the responsibility of individuals on both sides to ensure effective communication and proper handling of issues and actions.

In the model, a type relation has responsible for lead object is created between the Interface and Person type elements. In most cases, the cardinality of this relation is set to Single. This ensures clarity and prevents individuals from feeling that they lack responsibility when multiple disciplines are involved. Similarly, the type relation has responsible for supporting object is created between the Interface and Person type elements, with the cardinality set to Single. The same reasoning regarding cardinality applies to this relation.

Specification

In the engineering process, system requirements are identified to describe the performance of objects in fulfilling their respective functions. In addition to the so-called functional requirement, another type of system requirement, known as an interface requirement, is also identified.

Interface requirements

Projects often develop internal interface specifications that list interfaces for objects at the same level within the System Breakdown Structure (SBS). These specifications include internal interface requirements that describe how two objects within the project’s scope interact through an internal interface. Conversely, projects identify external interface requirements specified by the environment. These external interface requirements define external interfaces, which describe the interaction between an object within the project’s scope and objects outside of it (context objects).

In the model, a type relation specifies is typically created between the System Requirement and Interface type elements. In most cases, the cardinality of this relation is set to Multi. This allows broadly formulated system requirements to be related to multiple interfaces. In addition to a name and text, a system requirement usually has a category. The Category type property typically has a data type of List, including values such as Functional, Aspect, Internal Interface, and External Interface. In practice, system requirements categorized as Internal Interface and External Interface are linked to an interface. This model is commonly used by clients to group similar system requirements by category in object specifications. In these specifications, the related interfaces are displayed for the system requirements.

Scope

Some projects manage interfaces in Relatics but handle most of their requirements in an external application. In these cases, projects often store only the interface-specific requirements in Relatics. Since the need to reuse requirements for other elements in the model is minimal, the interface requirements are created uniquely for each interface. Projects often use the term Scope to refer to these interface-specific requirements.

When a project is organized into multiple subprojects (e.g., multiple contracts), it is common to distinguish between the scope for the discipline or organization that is the lead for the object and the scope for the discipline or organization supporting the object. This distinction helps track different interface requirements that are formulated differently for each subproject while maintaining focus on the overarching interface.

In the model, a derived type element Lead scope is created for the Interface type element. The Act as inner element setting is enabled for the Interface type element. Since most users are not interested in seeing a full overview of lead scopes for all interfaces, the lead scope is typically considered an inner type element. The Cardinality setting is set to Single, as there is usually no need for multiple lead scopes. This makes the interface specification unambiguous.

The Lead scope type element has type properties for Text and Comment. Typically, the Text type property has a data type of Text (to contain a full description of the interface requirement), and the Comment type property also has a data type of Text (to provide additional context for the scope text).

The same model pattern applies to the Supporting scope type element. While the discipline or organization responsible for the lead object manages the requirement specification in the lead scope, the discipline or organization responsible for the supporting object manages the requirement specification in the supporting scope. This approach ensures transparency and supports control in interface management.

Control

When multiple disciplines or organizations are involved in specifying and controlling interfaces, projects often create interface-specific actions. These actions help track what is needed and by whom to complete an interface.

In the model, a derived type element Interface Action is created for the Interface type element. The cardinality is set to Multi, which allows multiple interface-specific actions to be created.

The Interface Action type element has type properties for Description, Comment, and Status.

  • Typically, the Description type property has a data type of Text (to contain a full description of the interface action).
  • The Comment type property has a data type of Text (to provide additional thoughts, such as those from other disciplines or organizations involved).
  • The Status type property has a data type of List. Examples of list values include Open, In Progress, Completed, and Rejected. This helps to monitor the lifecycle of the action.

Finally, a type relation has responsible is created between Interface Action and Person. In most cases, the cardinality of the type relation is set to Single. Allowing only one person to be designated as responsible for the interface action makes it clear who is the point of contact for follow-up.

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.