Nonconformities

In practice, construction projects incorporate nonconformities into their Systems Engineering (SE) model as part of the quality management process to clarify how deviations from requirements and verifications are signaled, corrected, and prevented in the future. For example, contractors develop overviews that list identified nonconformities and the control measures for correction and prevention to be reported to the client.

Based on observations at projects, the basic model consists of a type element named Nonconformity, which typically includes type properties to store the name and description:

• The type property Name has a Single line text data type (to contain a brief title for recognizing the nonconformity).
• The type property Description has a Text data type (to provide more details on the nonconformity).

Observation

When multiple people are involved in identifying nonconformities, projects often keep track of who observes the nonconformities and when. This makes the process transparent and clear, and provides a means of determining who to contact for additional information.

Observer

Most projects that aim to track who has observed a nonconformity relate it to a specific person. Occasionally, a project might choose to use a project role instead of a person as the observer of a nonconformity, often to prepare for potential future changes in the project workforce. However, a significant drawback of this approach is that it becomes much harder to determine which individual observed the nonconformity at a specific time in the past, making it challenging to identify and contact the right person for further information. For this reason, relating nonconformities to a particular person is recommended.

In the model, a type relation, is observed by, is created between the type elements Nonconformity and Person. In most cases, the cardinality of this type relation is set to Single. Restricting the observer to one person clarifies who can provide additional information when questions arise.

TIP: By setting the type element Person as the Type of elements to link with users (optional) and enabling the option Element linked to current user as default to element for the type relation, nonconformities created by users are automatically linked to the corresponding person connected to the logged-in user.

Date of observation

Many projects record who observed the nonconformity and log the observation date. This practice further facilitates obtaining detailed information from the observer later.

Typically, the type element Nonconformity includes a type property to store the date of observation:

• The type property Date of observation has a Date data type (to track when the nonconformity was identified).

TIP: By setting the default value of the type property Date of observation to Current project date, newly created nonconformities are automatically assigned the current date, as defined by the project’s local time zone.

Lifecycle

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

If some nonconformities 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 nonconformities will be displayed by default in the views.

Source

Various files and documents are typically the origin of a nonconformity or communicate related information. Examples include documentation from which the nonconformities have been derived or emails that contain correspondence regarding the nonconformities. Referencing the actual file or documents helps users quickly access more detailed information about the nonconformity.

Single file uniquely stored for a nonconformity

Sometimes a document is only relevant in a single context. For example, an email has been received that addresses a specific nonconformity. If the file is specific to a single context, it can be directly uploaded into Relatics. In these cases, the advantage of storing the file directly in Relatics outweighs the benefit of storing the file in a central Document Management System (DMS) or network drive. In case only a maximum of one document per nonconformity is expected, projects often use properties to allow files to be uploaded for a nonconformity.

Typically, in the model, the type element Nonconformity includes a type property to store an attached file:

• The type property Attachment has an Attachment data type (to contain a file).

Multiple files uniquely stored for a nonconformity

Projects often use dedicated elements in their SE model if numerous files can be attached to a nonconformity. In addition to storing multiple documents, another advantage is that other metadata (e.g., a description) can be stored to complement the uploaded file.

In the model, a derived type element Attachment is created for the type element Nonconformity. Typically, the cardinality of Attachment is set to Multi as multiple files can be added. Additionally, the setting Act as inner element is enabled for the derived type element. Since most users are not interested in seeing a complete overview of attachments for all nonconformities, an Attachment is usually considered an inner type element. Typically, the type element Attachment includes type properties to store values for the file and description:

• The type property File has an Attachment data type (to upload a file).
• The type property Description has a Text data type (to contain an optional comment regarding the uploaded file).

Source documents reused by nonconformities

In many cases, projects reuse documents in their SE model. For example, multiple nonconformities can be related to the same source document. By relating all nonconformities to the same document, it becomes instantly traceable from the document’s perspective which nonconformities are applicable. In many projects, reused documents are stored in a centralized DMS or network drive that supports advanced file and document management.

In the model, a type relation, has source, is created between the type elements Nonconformity and Document. In most cases, the cardinality of this relation is set to Multi. This allows documents to be reused for multiple nonconformities.

Typically, in the model, the type element Document includes type properties to store a title and a hyperlink:

• The type property Title has a Single line text data type (to contain a name for identifying the document).
• The type property Hyperlink has a URL data type (to refer to the location of an external file). The advantage is that a user can click on the hyperlink to view the file stored in a DMS, shared network drive, or online resource directly.

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.

Specification

In some cases, during the plan development phase or requirement analysis, projects may discover that a system requirement cannot be met before any verifications have been planned. In such situations, it may be valuable to create nonconformities specifically for system requirements.

System requirements with unique nonconformities

Projects sometimes consider creating unique nonconformities for each system requirement. This has the advantage of keeping the SE model relatively simple. However, a disadvantage is that nonconformities cannot be reused for other system requirements or other elements from the model (e.g., verifications).

In the model, a derived type element, Nonconformity, is created for the type element System Requirement. Typically, the cardinality of Nonconformity is set to Multi as multiple nonconformities can be added. The properties of the nonconformity are similar to those described in the model pattern in the introduction.

NOTE: Project experience suggests caution. Nonconformities should only be created for system requirements not part of a verification. This approach helps avoid redundancy and ambiguity when the corresponding system requirements already have nonconformities via the verifications.

System requirements with reusable nonconformities

Projects often model nonconformities to be autonomous in the SE model. As a result, nonconformities can be reused and do not have to be created redundantly (e.g., in the context of system requirements).

In the model, a type relation, results from, is created between the type elements Nonconformity and System Requirement. In most cases, the cardinality of this relation is set to Multi. This enables broadly applicable nonconformities to be reused across multiple system requirements.

NOTE: Project experience suggests caution. Nonconformities should only be created for system requirements not part of a verification. This approach helps avoid redundancy and ambiguity when the corresponding system requirements already have nonconformities via the verifications.

Compliance

In the standard process, a nonconformity occurs when a system requirement is not met during the verification of an object. In such cases, it may be decided to: Update the design (i.e., the object) to ensure compliance with the requirements, revise the requirement if it is unfeasible, or provide additional evidence to achieve compliance during verification.

Verifications with unique nonconformities

Projects often verify system requirements against specified objects. For example, a contractor typically creates a verification plan outlining all system requirements and object combinations, including the associated phase and method. Subsequently, the actual verifications are documented in a verification report, which includes the results and, if applicable, an explanation. If the result of a verification indicates that a system requirement is non-compliant, a nonconformity may be created for that verification.

Sometimes, projects consider creating unique nonconformities for each verification. This has the advantage of keeping the SE model relatively simple. However, a disadvantage is that nonconformities cannot be reused for other verifications or other elements from the model (e.g., system requirements).

In the model, a derived type element, Nonconformity, is created for the type element Verification. Typically, the cardinality of Nonconformity is set to Multi, as multiple nonconformities can be added. Additionally, the setting Act as inner element is enabled for the derived type element. Since most users are not interested in seeing a complete overview of nonconformities for all verifications, a Nonconformity is usually considered an inner type element. The properties of the nonconformity are similar to those described in the model pattern in the introduction.

Verifications with reusable nonconformities

Most projects make nonconformities autonomous in the model. The advantage is that nonconformities can be reused for multiple verifications. When a nonconformity applies to multiple verifications, it must not be duplicated. Another benefit is that overviews and use cases dedicated to nonconformities can be used, for example, for analysis purposes.

In the model, a type relation, results from, is created between the type elements Nonconformity and Verification. In most cases, the cardinality of this relation is set to Multi. For instance, verifying a system requirement might fail for multiple specified objects. In such cases, it may be decided to formulate a generic nonconformity related to each corresponding verification.

Control

When projects manage nonconformities, control measures are often implemented. These measures help mitigate risks, such as failed verifications, to prevent them from escalating into significant problems for the project.

Nonconformities with unique control measures

Most projects create control measures specific to a single nonconformity. This has the advantage of keeping the process and the SE model simple, especially when a control measure has been implemented for one nonconformity but not another.

In the model, for the type element, Nonconformity, a derived type element, Control Measure, is created. Typically, the cardinality of the derived type element is set to Multi, as multiple control measures can mitigate a nonconformity. Normally, the type element Control Measure includes type properties to store values for the description, type, and status:

• The type property Description has a Text data type (to provide a detailed explanation of the control measure).
• The type property Type has a List data type (to classify the control measure). Examples of list values include Corrective and Preventive. A corrective control measure addresses an issue that has already occurred, while a preventive control measure focuses on avoiding similar issues in the future.
• The type property Status has a List data type (to track the lifecycle of the control measure).

Nonconformities with reusable control measures

Sometimes projects consider making control measures autonomous in the SE model. An advantage is that control measures can be reused for other nonconformities and other elements in the SE model (e.g., risks). A disadvantage is that it is more difficult to track which nonconformities the control measure has been implemented for, as it is unclear which related control measure the status applies to.

In the model, a type relation, controls, is created between the type elements Control Measure and Nonconformity. In most cases, the cardinality of this relation is set to Multi. This enables control measures that apply to multiple nonconformities to be related as such.

Result

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

In the model, a type relation, is result of, is created between the type elements Change and Nonconformity. In most cases, the cardinality of this relation is set to Multi. This allows broadly applicable changes to be linked to multiple nonconformities.

Additionally, a type relation, affects, is created between the type elements Change and System Requirement. Similarly, the cardinality of this relation is set to Multi. This enables broadly applicable changes to impact multiple system requirements. From the perspective of the system requirement, this model pattern provides complete transparency, offering a clear rationale for the changes made to the requirement.