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.

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:

By |2016-12-31T18:07:04+00:00January 5th, 2011|sysml|2 Comments

2 Comments

  1. Ray Joseph January 5, 2011 at 6:30 pm

    What a great idea! I realy like the idea of paths not chosen and enumberated solutions. Placing alternative side by side gives an additional opportunity to better understand and abstract the purpose of the requires so one may better understand when a requirement estends too far into a premature solution.

    Great Job!

  2. Loïc Fejoz January 31, 2011 at 9:37 am

    I must confess this is not really my idea.

    I have done a Ph’D in formal methods for computer science. In that branch of research, refinement links have similar meaning as logical implications. This is the idea applied here.

    But your idea of using it as a test to see if the requirement implies an implementation is great too!

    Thanks Ray.

Leave A Comment