·

A Trigger for Requirements Change

Ivan Jureta

There is a simple condition, called “fitness improvement” that triggers (i.e., is both necessary and sufficient for) the change of a requirements model. The problem with it is that it is simple to define, but expensive to check when it verifies in practice. What is that condition, and why is checking it expensive?

In discussing the differences between “requirements evolution” and “requirements change” in another text, I concluded that, one, requirements evolution is a special case of requirements change, and two, it should occur when the change improves the fitness of requirements.

“Requirements fitness” is an interesting relationship, because it is not between requirements in the same requirements model, but between requirements in two iterations, or versions of that model. 

For example, if you have a requirements model M1, which includes requirements R1 and R2, and you have a model M2 which includes R1 and R3, requirements fitness can relate only members of M1 to members of M2, and vice versa, neither two requirements in R1, nor two requirements in M2. Requirements fitness is a relationship that matters when we change models. 

I defined the requirements fitness relation as follows.

Given a set of requirements R, a requirement x is fitter than requirement y relative to R if and only if the expected utility of the solution to R1 is strictly higher than the expected utility of the solution to R2, where R1 includes R and x, while R2 includes R and y.

We are talking here about requirements models, which usually have requirements and some other information, such as domain assumptions, elements of specification, and so on (see, for example, [1,2,3] and my book on requirements modeling language design [4]). 

Because of the variety of information in requirements models, it follows that we can generalize the fitness relation to any change of the requirements model, as follows.

Given some requirements model M1, X is fitter than Y for M1 if and only if the expected utility of the solution in M1 is lower than the expected utility of the solution in M2, where M2 is the requirements model made by taking M1, removing Y, and adding X.

The important change above is that requirements fitness is a relation over parts of models of requirements. These parts can be a single requirement, a single domain assumption, a set of requirements and domain assumptions and relationships over them, or any other combination of atoms of a requirements model, as these are defined in the applicable requirements modeling language.

The intuitive, and perhaps the most important intuitive idea in the requirements fitness relation is that if you can get to a better solution by changing the model, then you obviously should change the model.

It is straightforward to turn this relation into a condition for the efficiency of a requirements model. It could be stated as follows.

A requirements model M is efficient with regards to the requirements fitness relation, if and only if no replacement X is known for any part Y of M1, such that if Y was replaced by X, the resulting requirements model M2 is such that the solution in M2 has higher expected utility than the solution in M1.

All this seems quite reasonable. 

But consider what needs to actually be done to identify such a part Y of a given requirements model and its replacement X. Specifically, we need to know the following:

  1. Solution in M1, 
  2. Expected utility of the solution in M1,
  3. Solution to M2,
  4. Expected utility of the solution in M2,
  5. The difference between M1 and M2.

Notice how we need to know the changed requirements, the solution in it, the expected utility of the solution. It is an interesting question if it is not avoidable to know this, or to have made assumptions about all this, every time a requirements model is changed, since why else would we change it than to improve the solution we’ll end up with?

References

  1. Van Lamsweerde, Axel. Requirements engineering: From system goals to UML models to software. Chichester, UK: John Wiley & Sons, 2009.
  2. 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.
  3. 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.
  4. Jureta, Ivan. The Design of Requirements Modelling Languages. Springer International Publishing, 2015.