Bernd Holzmueller, senior expert systems engineering at ITK Engineering, reveals how a requirements-in-the-loop approach can identify inconsistent, incomplete and incorrect behavior using simulation at a very early stage in a project.
What are the fundamentals of a requirements-in-the-loop approach?
Over the past ~20 years, several ‘in-the-loop’ approaches, including hardware-in-the-loop and software-in-the-loop, have been introduced in the industry, aiming to shift test effort from the final system to earlier development phases using appropriate virtualization of the environment for the system under test. Frontloading testing activities reduces product and development risks and costs by finding defects earlier and making testing more efficient and repeatable through automation.
Requirements-in-the-loop applies this strategy in the requirements phase of development, requiring two things:
- A formal representation of the (functional) requirements that is amenable to execution, i.e. that given a sequence of stimuli over time, a valid system response can be determined according to the requirements. The formal requirements thus define a function from inputs (and system state as determined by the execution history) to outputs of the system, providing a black-box view of the system behavior;
- A specification of assumptions and constraints about the system environment that can be used to generate stimuli.
Creating a formal and executable representation of functional requirements and performing some sort of open- or closed-loop simulation on these requirements can reveal many quality issues and errors in requirements, with a considerable impact on reducing development time and effort as well as improving product quality. This can be done either as part of the requirements’ review activities, or (even better), while the requirements are being specified to avoid creating specification errors and flaws in the first place.
This approach has been around for some time. How has the team at ITK Engineering developed it?
We applied the idea of RIL to an approach called ‘tabular expressions’ that was developed in the late 1970s by David Parnas et al. As tables are much easier to read and comprehend as well as provide a highly structured means to convey information, they can be understood and analyzed and verified by engineers more easily than mere prose requirements or cryptic formal syntax.
We created a tool supporting this approach and applied it in various system and software development projects, mainly in the context of embedded systems in the automotive and rail industries. We successfully used it as part of reviews to find ambiguities and errors in requirements, and during requirements specification to come up with a consistent and complete set of functional requirements.
In what ways was the methodology beneficial?
In many cases, the approach not only helped to clarify the intended meaning of requirements but also to simplify the specification by eliminating redundancies or changing the structure and phrasing of requirements – which also reduced development and testing efforts. In an early evaluation project, we applied RIL to a running project on which software was already being tested through HIL. A quick analysis of the requirements (3h) revealed a potential error due to an ambiguity that was confirmed via HIL and took about a week to fix. This gave us the confidence to use the approach whenever possible.
A white paper on RIL is freely available for download here.
Bernd Holzmueller, senior expert systems engineering at ITK Engineering, will discuss the methodology in the free to attend Technology Presentation Stage at Automotive Testing Expo Europe 2023 on Tuesday, June 13, in Hall 8 at 11:30am.