Design patterns

Table of Contents

Changes

With environmental dynamics constantly causing changes, projects often decide to include changes in their Systems Engineering (SE) model. This helps clarify the project’s scope and assess the changes’ impact. As a result, changes can lead to modifications of specifications (e.g., requirements) or changes in the design (e.g., objects). Often, processes between the client and contractor support the formal communication on changes. For example, a contractor can submit proposed changes to the client through a variation request (also referred to as a change request or a variation order request), which must be reviewed and approved by the client. Changes accepted by the client are shared through a variation order (also referred to as a change order), which officially amends the contract. In SE models of projects, the terms change and variation are often used to support similar processes. For clarity and simplicity, the term change will be used hereafter.

Based on observations at projects, the basic model consists of a type element named Change. Typically, the type element Change includes type properties to store the name and description:

  • the type property Name has a data type of Single line text (to contain a brief title for identifying the change);
  • the type property Description has a data type Text (to provide a more detailed description of the change).

Scope

Most changes target elements from the SE model. Depending on the ambition level, projects implement different design patterns in their model to keep track of the elements subject to changes and the type of modification they are concerned about.

Changes describing modifications of type elements

Most projects support processes in which changes can lead to the modification (also referred to as alteration) of various type elements from the SE model, such as requirementsobjects, and documents. When analyzing elements in the SE model, a user can be triggered to create a change for them. For example, when you realize that a requirement that is specified in the original contract needs to be altered. As a result, the related changes provide traceability from the perspective of the elements.

In the model, a type relation, modifies, is created between the type element Change and another set of type elements. In practice, the cardinality of the type relation is set to Multi because multiple elements can be the subject of a change. Finally, it may be useful to set the range of the type relation to Collection when the meaning of the type relation (e.g., modifies) is the same for the various type elements within the context of the change.

TIP: By using the relatable elements view, a user can create changes directly from the perspective of an element whose type element is related to the type element Change.

NOTE: Setting the range of the type relation to Collection only supports five type elements. When more than five type elements are the subject of a change, it is advised to set the range of the type relation to Standard and use distinct role names for each type relation.

Changes describing different types of modifications for type elements

Projects sometimes want to describe the type of modification for some type elements of the SE model that are subject to change. The advantage is that this allows users to filter the different types of modifications more easily. In practice, this is mainly applied to requirements. As a result of a change, it is described whether requirements are (planned to be) added, updated, or removed.

In the model, a type relation, adds, is created between the type elements Change and Requirement. In practice, the Cardinality of the type relation is set to Multi. As a result of a change, multiple requirements can be added. Similarly, a type relation, updates, is added to the model between the type elements Change and Requirement to describe updated requirements, and a type relation, removes, is added to the model between the type elements Change and Requirement to describe omitted requirements.

Changes with more detailed modifications of type elements

When projects want to track modifications of certain individual elements in more detail, they can decide to include modifications as dedicated elements to the SE model. The advantage is that modifications of individual elements (e.g., requirements) can be described in more detail in the context of the overall change. This not only answers what has changed (e.g., which requirements) but also answers how and why the change was made in more detail.

In the model, a middle type element Modification is created for the type element Change. Typically, the cardinality of Modification is set to Multi to allow users to create multiple modifications as part of a change. The target relation of Modification is set to Requirement. As a result, modifications can only be created for combinations of a change and a requirement. Typically, the type element Modification includes type properties to store the category, remark, and status:

  • the type property Category has a data type of List (to classify the type of modification). Examples of typical list values include Addition, Update, and Removal;
  • the type property Remark has a data type of Text (to contain an optional comment on the modification);
  • the type property Status has a data type of List (to indicate the lifecycle of the modification). Examples of typical list values include Actual and Rejected.

TIP: The compare mode can be used as a complementary tool for identifying and validating modifications stored explicitly in the model.

Lifecycle

When monitoring the handling of changes over time, adding a type property Status to the model with the data type List is often beneficial. Examples of typical list values include Proposed, Approved, and Rejected. This makes it easier for users to filter out irrelevant changes. In most cases, the list value Proposed is set as the Default. As a result, every newly created change will be automatically assigned the status value Proposed.

If some changes are expected to become irrelevant to the project over time, it is advisable to configure the type property Status as a Life cycle property. Optionally, by enabling the Auto archive setting and selecting appropriate archive values (e.g., Rejected), only relevant changes will be displayed by default in the views.

Source

Changes can result from other elements in the SE model. For example, organizations, variation requests, variation orders, variation notices, nonconformities, and documents are in practice related to changes by projects as the origin.

Organizations

In basic change management processes of projects, the initiator of a change is tracked. In most cases, this concerns organizations, although it can also concern persons, depending on the project processes. As a result, it is traceable where a change originates from.

In the model, a type relation, is initiated by, is created between the type element Change and Organization. In practice, the cardinality of the type relation is set to Single. This enforces multiple changes to be made when multiple organizations suggest similar changes. This optimally supports traceability as the original input can be matched to the corresponding organization.

Variation requests, variation orders, and variation notices

In advanced change management processes of projects, often a distinction is made between variation requests (also known as change requests or variation order requests) and variation orders (also known as change orders). Some projects also include variation notices in their SE model (also known as change notices).

A contractor can propose changes to a client through a variation request. The client reviews and approves the variation request, and when accepted, the changes become part of a variation order, which officially amends the contract. During the project’s lifecycle, clients also identify changes to the original contract, which are directly shared with contractors through variation orders. Sometimes, contractors use variation notices to formally notify the client that potential changes to the original contract are to be expected. This proactive form of communication helps to mitigate potential future costs.

In the model, the following type relations can be part of the model:

  • A type relation, is requested in, is created between the type element Change and Variation Request. In practice, the cardinality of the type relation is set to Multi as changes can be submitted in multiple variation requests over time.
  • A type relation, is ordered by, is created between the type element Change and Variation Order. In practice, the cardinality of the type relation is set to Multi as changes can be shared in multiple variation orders over time.
  • A type relation, is noticed in, is created between the type element Change and Variation Notice. In practice, the cardinality of the type relation is set to Multi because changes can be communicated in multiple variation notices over time.

Nonconformities

A nonconformity may indicate that updating the design has disadvantages that outweigh the advantages. In such cases, projects can propose updating the requirements through a formal change process. Most projects use a structured change management process, where nonconformities serve as one of the inputs.

In the model, a type relation, is result of, is created between the type element Change and Nonconformity. In practice, the cardinality of the type relation is set to Multi, allowing broadly applicable changes to be linked to multiple nonconformities.

Documents

Documents describing a change (e.g. an email, a textual file, a spreadsheet, etc.) are often made part of the SE model. This enhances the changes’s traceability, allowing users to verify its existence and access more detailed information.

In the model, a type relation, has source, is created between the type element Change and Document. In practice, the cardinality of the type relation is set to Multi since multiple files can be the source of an action over time.

TIP: By setting the ownership of the type element Document to External application, you can work with external data. In this example, the set of documents in Relatics can be automatically synchronized with the list of documents in the project’s DMS.

Result

Often, projects analyze the consequences of a change in the change management process. The impact of the change is described in various categories (e.g., financial, time, quality, safety, risk, and environment).

In the model, a derived type element Impact is created for the type element Change. Typically, the cardinality of Impact is set to Multi to allow users to create multiple impacts for a change. Additionally, the setting Act as inner element is enabled for the derived type element. Since most users are not interested in seeing a full overview of impacts for all changes, an Impact is usually considered an inner type element. Typically, the type element Impact includes type properties to store the description and category:

  • the type property Description has a data type of Text (to provide the full details of the impact);
  • the type property Category has a data type of List (to classify the impact). Popular list values include Financial, Time, Quality, Safety, Risk, and Environment.

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.