By releasing STIMULUS 2017, Argosim continues revolutionising requirements engineering. After introducing simulation of textual requirements to the market with STIMULUS 2015 and automatic detection of requirements conflicts with STIMULUS 2016, STIMULUS 2017 also brings new breakthrough technologies to improve the development process of real-time embedded systems.
Argosim’s ambition is to address the five pillars of requirements engineering such as defined by all safety-critical standards: requirements shall be non ambiguous, correct, consistent, complete and testable. While STIMULUS already tackles the first three quality criteria, the latest release now provides new features to check both completeness and testability of real-time embedded system requirements.
STIMULUS 2017 brings effective answers to these two challenges.
“Are my system requirements complete?”
When specifying a system, every architect is facing the difficulty of finding missing requirements, which is known as the elicitation problem. Unfortunately, a lack of requirements may end in unexpected -if not dangerous- behaviours. On the other hand, too many requirements will end in a very complex system specification that will be difficult for designers to handle.
STIMULUS 2017 enables the visualisation of unspecified behaviours to address this issue.
At simulation time, STIMULUS will now show dashed lines where signal behaviours are not defined by any requirements, meaning that STIMULUS can freely choose the values at those instants or periods of time.
These dashed lines are likely to point to holes in the specification that architects will then complete, but it may also be the case that unspecifed behaviours simply give designers some freedom in the implementation.
“Have I tested my system enough?”
When writing test scenarios, validation engineers try to cover all possible behaviours of the system such as running modes or sequences of actions in order to guarantee its compliance to requirements. At the same time, they also try to keep to a minimal set of tests because test maintenance is both very costly and error-prone.
STIMULUS 2017 provides requirement coverage metrics to address this issue.
At simulation time, STIMULUS will now display the requirements that have been activated at least once by some test scenario. Besides this, requirements observers will continue to turn red on any violation, or stay green as long as the requirement is satisfied.
STIMULUS indicates the coverage of requirements using colours:
- orange, indicating that requirements have never been activated. Another test scenario needs to be written or your current scenario needs to be completed.
- green, indicating that requirements have been activated at least once. If all requirements are green, then your test campaign is complete.
- mix of green and orange, indicating that requirements are partially covered. You need to focus on the orange requirements in order to complete your scenario.
Combining these new features with the many existing ones makes STIMULUS 2017 even more efficient in debugging and testing embedded system requirements.