In practice, 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, along with 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 includes type properties to store the name and description.
Typically, the type property Name has a data type of Single line text (to contain a brief title for recognizing the nonconformity), and the type property Description has the data type Text (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 identifying 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 difficult to identify and contact the right person for further information. For this reason, it is recommended to relate nonconformities to a specific person.
In the model, a type relation called is observed by is created between Nonconformity and Person. In most cases, the cardinality of this type relation is set to Single. Restricting the observer to one person ensures clarity about who can provide additional information.
Note that 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, any nonconformities created by users will automatically be linked to the corresponding person associated with the logged-in user.
Date of observation
In addition to recording who observed the nonconformity, many projects also log the observation date. This practice further facilitates obtaining detailed information from the observer at a later time.
For the type element Nonconformity, a type property called Date of observation is added to the model. Typically, this property is assigned the data type Date, enabling the capture of the specific date when the nonconformity was identified.
Note that for the type property Date of observation in the type element Nonconformity, the default setting can be configured as Current project date. This ensures that newly created nonconformities are automatically assigned the current date, as defined by the project’s regional settings.
Lifecycle
When monitoring the handling of nonconformities 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 makes it easier to filter out irrelevant nonconformities.
If some nonconformities are expected to become irrelevant to the project over time, it is advisable to configure the Status property as a Life cycle property for the type element Nonconformity. This can be done by setting the Life cycle property of the type element Nonconformity to the type property Status. Furthermore, 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
In the standard process, a nonconformity occurs when a system requirement is not met during 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 determined to be unfeasible, or provide additional evidence to achieve compliance during verification.
Verifications
Projects often verify system requirements against specified objects. For example, a contractor typically creates a verification plan that outlines all combinations of system requirements and objects, 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 a verification indicates that a system requirement is non-compliant, a nonconformity may be created for that verification.
In the model, a type relation called results from is established between the type elements Nonconformity and Verification. Typically, the cardinality of this relation is set to Multi. For instance, a verification of a system requirement might fail for multiple specified objects. In such cases, it may be decided to formulate a generic nonconformity linked to each of the corresponding verifications.
System requirements
In some cases, during the plan development phase or requirement analysis, before any verifications have been planned, projects may discover that a system requirement cannot be met. In such situations, it may be appropriate to create nonconformities specifically for system requirements. However, project experience suggests caution: nonconformities should only be linked to system requirements that are not part of a verification. This approach helps to avoid redundancy and ambiguity.
In the model, a type relation called results from is typically created between the type elements Nonconformity and System Requirement. The cardinality of this relation is usually set to Multi, enabling broadly applicable nonconformities to be reused across multiple system requirements.
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.
In the model, a derived type element called Control Measure is created for the type element Nonconformity. The cardinality is set to Multi, as projects may develop multiple control measures to address the same nonconformity.
The type element Control Measure includes the properties Description, Type, and Status. The Description property typically has the data type Text to provide a detailed explanation of the control measure. The Type property uses the data type List, with values such as Corrective and Preventive. This categorization aids in filtering control measures. 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 Status property also uses the data type List to track the lifecycle of the control measure.
Result
A nonconformity may indicate that the disadvantages of updating the design outweigh the advantages. In such cases, projects can propose updating the system 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 called is result of is established between the type elements Change and Nonconformity. The cardinality is typically set to Multi, allowing broadly applicable changes to be linked to multiple nonconformities. Additionally, a type relation called affects is created between the type elements Change and System Requirement. Similarly, the cardinality for this relation is set to Multi, enabling broadly applicable changes to impact multiple system requirements.
From the perspective of the system requirement, this model pattern provides full transparency, offering a clear rationale for the changes made to the requirement.
