Introduction

Two of the most important tasks in systems engineering are arguably understanding stakeholder needs and translating them into system requirements. This white paper discusses the early application of modeling to perform these tasks, demonstrating modeling techniques of increasing sophistication and value that range from purely descriptive models to formal proofs. The increased quality of system requirements alone justifies investment in these techniques, but the resulting models can also be used in later stages of the project to represent the needs of stakeholders more effectively. We show how requirement models can be utilized to achieve consistent and complete system requirements. Figure 1 shows the process followed in this paper to achieve these benefits.

For this case study, requirements will be derived for a machine cooling system based on the stakeholder needs described below:

These stakeholder needs are ambiguous and could easily be misinterpreted, which could result in incomplete and/or incorrect system requirements, and eventually lead to a design that fails to meet the stakeholder’s expectations. To avoid this, validating stakeholder needs is necessary.

There are modeling techniques that can help validate our understanding of stakeholder needs and converge on a set of system requirements. These methods include the use of:

1. Descriptive models
2. Simulation models
3. Formal models

We will describe each of these methods in the following sections and end with a discussion on the use of a digital thread to establish traceability between stakeholder needs and various levels of derived requirements.

Using Descriptive Models

Figure 2 describes the following scenario: If the temperature (T) is too high (T>=40), cooling is needed; if cooling is effective (T<40), cooling should be turned off; but if cooling is not effective (delay>=30), the machine needs to be turned off.

Using Simulation Models

This is important because simulation provides an unambiguous interpretation of each scenario described in the earlier sequence diagrams. It also provides a means to communicate this interpretation back to the stakeholder, explore different scenarios, and understand what their specific needs are, so that we can describe that information in the system requirements.

Now that we have a model that simulates the behaviors specified in the sequence diagrams, we can observe and discuss the outputs generated by the state machine with the stakeholders. Additionally, we can validate whether the state machine behavior is consistent with the scenarios described in the sequence diagram. In Figure 4, the green checkmarks in the sequence diagram indicate that the right events have occurred in the right order during the simulation. This confirms that the functional model behavior is correct. These results can also be used for validation with the stakeholder.

Using Formal Models

For example, requirement #1 states that when T is below 40 ˚C (T<40), the cooling system should be turned off (Turn_off_cooling == true).

An analysis using the formal methods capabilities of Simulink Design Verifier™ can now determine whether the requirements are consistent and complete. In Figure 6, the scenario where the temperature is exactly 40 ˚C has not been included and therefore this requirement set is incomplete.

Further Considerations and Uses of Requirement Models

Testing of Design Models

Formal requirement models provide a good starting point for downstream teams, both because the quality of the requirements is higher and because elements of the requirements model can be reused during design, automatic test generation, and verification. Requirement models can be used as part of unit tests to ensure that functional models are developed to meet requirements. These unit tests can be executed both interactively and as part of a CI/CD framework. Figure 7 shows that requirements 1 and 2.2 pass the test and that the other requirements have not been exercised.

Digital Thread and Beyond

Many artifacts are created and/or generated throughout the different stages of the product development lifecycle. These digital artifacts include requirements, architecture, design models, code files, and verification and validation files. It is critical to establish a traceable link between these artifacts to understand how requirements impact other requirements, models, or verification and validation activities. This link serves as the digital thread.

For example, requirements traceability diagrams can be generated automatically from the requirements and architecture models, helping provide insight into how these requirements, models, and verification artifacts are graphically linked to each other.

Figure 8 shows the digital thread where a stakeholder need is met by another stakeholder. In reality, several stakeholders will be spread across the organization covering different functional areas at various levels of abstraction. This is where a digital thread becomes indispensable. Furthermore, a digital thread facilitates the use of automated, agile, and iterative processes and infrastructure (DevOps). For example, Figure 8 shows how the verification status of a test is automatically fed back to the responsible engineer.

As organizations embark on their digital transformation journeys, the concepts of digital threads, digital twins, and DevOps play complementary roles in establishing a foundation for digital engineering. These concepts work in concert to create an infrastructure that supports the transition from traditional to digital-centric engineering practices.

Conclusion

In this paper, we have described a process wherein, based on stakeholder needs, we converged on (simulatable/executable) system requirements using simulation and formal methods. To do this, we used requirement models that could simulate (state machines), evaluate (sequence diagrams), and be formally analyzed (Requirements Table).

The use of requirement models enables automation for verification and validation activities, resulting in complete, consistent, and validated system requirements. It also improves collaboration between different teams, as they provide more information than purely descriptive or text-based requirements can.

By Alan Moore, Becky Petteys, and Stephan van Beek