So you’re working on a design… Are you sure you’re building what was intended? Yes, you’re building what they asked for… or, at least, what you think they asked for, but is that what they wanted?

Requirements can be dicey; they’re based on natural language, which, as we know all too well, is subject to interpretation. According to Argosim, many companies have institutionalized styles – sentence templates, for instance – to ensure consistent, clear, unambiguous articulation of requirements. That’s not a guarantee of clarity, but it certainly helps.

What it doesn’t necessarily help with, however, is the following question: do you know if, out of all the requirements, some of them conflict or are mutually inconsistent? If one requirement is a dense material to protect against radiation and another requirement is that the material has to float, those two might not work together. Remember to use the right radiation protection to avoid any heath risks.

There has, until recently, been no way to formally check requirements for consistency and overall requirements correctness. Those two requirements above (dense + floating) are relatively vague – you wouldn’t be able to test them without the ability to extract the semantics and then simulate the physics. But many requirements are functional, and they can be expressed in a more formal manner that can then be tested.

This might sound like a nice-to-have for many electronic products. We see too many cheap consumer goods that clearly haven’t been well thought out or possibly don’t even have all of their features working properly. This would be great for that, but such products typically have cost and schedule requirements that don’t really allow for a more thoughtful process.

Safety-critical equipment, however, is a completely different matter, having strict requirements for requirements traceability. And, while some product requirements will always have a level of vagueness, functional requirements in such systems explicitly must be verifiable. This means that they should be specific enough to have their mutual consistency and other properties tested.

This is what Argosim has introduced in their STIMULUS offering. It’s a mechanism for specifying requirements, testing them for correctness and consistency, and then generating tests from them that can be used in future validation testing.

At present, the workflow is somewhat disconnected from existing flows; ideally, requirements would be specified using STIMULUS – that’s Argosim’s long-term vision. For the moment, it’s more of a collaborative process.

First, a requirements engineer will create natural-language requirements in the same way as is done today. He then hands them off to a verification engineer, who will create a model in STIMULUS using a formal language that can then be simulated. Both requirements and assumptions are included in the description. Through simulation, problems might be identified – and the original requirements engineer is then consulted for discussion and correction.

If no issues are identified, then the verification engineer can generate tests that will be used downstream to close the loop and ensure that the implementation of the requirements matched the intent. If tests aren’t generated, or if the test set is incomplete, then this is still something of an open-loop process.

You can find out more about STIMULUS in their announcement.