Capturing verifications of requirements unambiguously

In high quality projects, verifications and tests are explicitly captured to be able to prove that the result meets the specifications. How verifications of requirements are described differs on the project and depends on the processes and needs. This article describes one of the possible ways to capture information about verifications. The examples in this article are related to verifications of design components that are part of a system. The principles are also applicable to for example verifications of products or services.

Design components and requirements

Multiple requirements can be related to a single design component of a system. An example is a design component that has to meet both a reliability requirement and a safety requirement. On the other hand, one requirement can be related to multiple design components. For example, a safety requirement that applies to two design components.

To know in the end if a design component of a system meets its related requirements, a verification has to be explicitly captured.

Do you capture verifications for requirements or for design components?

A logical idea is to capture the verification for a design component of a system. However, the problem that occurs is that no distinction can be made for the related requirements. For example, for Design Component 1 it has been determined that it does not meet the requirements (see the left-hand side of figure 1). In this situation it is unclear whether the verification applies to the reliability requirement, the safety requirement or both requirements.

Capturing the verification for the requirement is neither a solution to the problem. The reason is that if a requirement is not met, it is not possible to make a distinction for the design component. Suppose that in the example this time the safety requirement is not met (see the right-hand side of figure 1), then it is impossible to say which design components of the system are concerned.

If verifications cannot be stored for requirements or for design components, what is then the best place to store verifications?

model2_amodel2 b

Verifications are about the combination of requirements and design components


The answer is that a verification says something about the combination of a requirement and a design component of a system.

By capturing the verification on the relation between a design component and a requirement, it can be tested for each combination if the result meets the specifications. The example shows that the requirements for Design Component 1 were not met (see figure 2). Now it is clear that the reliability requirement has been met, but the safety requirement has not been met. More specifically, only for Design Component 1.

Verifications of requirements and design components in Relatics


In Relatics it is possible to use two relations and a middle element as one composed relation. When a requirement is related to a design component of a system, then a new element is created in between. In this case it could be a verification. The screenshot below illustrates how in this example information regarding verifications for design components and requirements are managed.

More information?

Do you want to experience how simple and effective verifications for products, services or systems can be captured in a tool using the above principles? Request a demo or contact us via +31 180 413 047 or