Solution-space Exploration with SysML requirements
Solution-space exploration is one of the SE activities that is not always traced. It is frequent that the requirement document only contains the final choice. Today, I will present how to express alternatives in requirements.
«containment» is not a solution!
Before showing you how to do it, I must say again that «containment» is only a structural link. If you really want to use it, you won’t be able to express alternatives. Indeed all sub-requirements won’t be different than the others.
«refine» links to express alternatives
In previous post, I show you how you can derive new requirements by using the «refine» link. I stress you on using it with several sources (aka “clients”) to express the conjunction of the sub-requirements (just like the left «refine» of the following diagram). Solution-space exploration is just a synonym for refinement disjunctions.
Following figure shows that requirement R1 could be derived either by satisfying S1.R1 and S1.R2, or by satisfying S2.R1. That’s it! Simple but with clear semantic…
Alternative requirements for a traffic lights.
conclusion
You know now how to express semantically richer relationships between requirements. Later, it will allow you to automatically check links between refinements. Lamsweerde et al [1] also propose this in KAOS/GORE methodology.
In future posts, I will introduce you on how to use formal requirements directly in the model. The other things I will talk about later are obstacles. Obstacles are what made an alternative not viable or not good enough.
How about you? Do you express requirements alternatives in your SysML models? Let us know in the comments what is your way of modelling.
Further reading:
- [1] Requirements Engineering, from System Goals to UML Models to Software specifications, Axel van Lamsweerde
