Conditions for Incomplete Requirements Models

When is a requirements model incomplete? The answer depends on the requirements modeling language (RML) used to make the model. Therefore, when you choose an RML, you are also choosing its own definition of when a model is incomplete. 

The reason that conditions for model incompleteness are important, is that you cannot claim that you are done with requirements modeling as long as the model you are making is incomplete. It follows that you can influence how someone uses the RML to make models, that is, if you are proposing an RML together with a method for how to use it (or a new method for an existing RML), then incompleteness conditions are a way to build some recommendations of the method into the modeling language. It is a way to more tightly integrate the modeling language and the method for how to use it.

Let’s say that your requirements modeling language is Eric Yu’s i-star [1], and suppose that your method for how to use i-star says that one should ensure that for every goal in the model, there are tasks which suggest how to achieve that goal. How could that be translated into the language? One way to do this, is to say that every model made with i-star using your method needs to satisfy the following necessary condition for completeness (necessary, as you may want the model to satisfy some other conditions as well): There should be a path from at least one task to every goal in the i-star model.

In KAOS, an explicit incompleteness criterion concerns how far you need to refine goals [2,3]. Namely, goals need to be refined to actions assigned to software agents or people.

If the RML is Techne [4], then one of completeness criteria is that all mandatory goals are satisfied. 

In all three examples, relationships defined in the RML play a key role in incompleteness. Since we can map relationships to edges in a graph, we can define conditions for completeness as properties of the graph that can be created from a requirements model. If the requirements model in KAOS is a forest (i.e., many graphs in which every two nodes are connected by exactly one path), then the completeness condition above translates into asking that the leaves of all trees are labeled as actions assigned to software agents or people.

Some RMLs involve the specification of model elements as propositions in a formal logic (of those mentioned above, KAOS and Techne do so). In that case, there is another criterion for completeness, one that’s hard to satisfy: a requirements model rewritten as a set of propositions in a formal logic cannot be evaluated for completeness, its logical closure should be. In principle, then, we would need to evaluate completeness not of the requirements model, but of the logical closure of the model rewritten in the formal logic used.

References

1. Yu, Eric SK. “Towards modelling and reasoning support for early-phase requirements engineering.” Proceedings of ISRE’97: 3rd IEEE International Symposium on Requirements Engineering. IEEE, 1997.
2. Dardenne, Anne, Axel Van Lamsweerde, and Stephen Fickas. “Goal-directed requirements acquisition.” Science of computer programming 20.1-2 (1993): 3-50.
3. Van Lamsweerde, Axel. “Goal-oriented requirements engineering: A guided tour.” Proceedings fifth ieee international symposium on requirements engineering. IEEE, 2001.
4. Jureta, Ivan J., et al. “Techne: Towards a new generation of requirements modeling languages with goals, preferences, and inconsistency handling.” 2010 18th IEEE International Requirements Engineering Conference. IEEE, 2010.