· ·

Requirements Evolution, Change, and Update

Ivan Jureta

What could it mean that a “requirement evolves”? Is it the same to say that a requirement evolves and that it changes? How are requirements evolution and change related to updates of sets of requirements? 

The term “evolution” has rigorous definitions in biology. A textbook one is as follows (it is carried over from [1], and comes from [2]):

“[biological evolution] is change in the properties of groups of organisms over the course of generations…it embraces everything from slight changes in the proportions of different forms of a gene within a population to the alterations that led from the earliest organism to dinosaurs, bees, oaks, and humans.” 

If we carry over the term “evolution” to combine it into “requirements evolution”, it looks like we are trying to refer to a special type of change of requirements. 

What is special about it? 

“It is essential to understand that biologists recognize many ways that evolution can occur, evolution by natural selection being just one of them, although it is often held to be the most prevalent one. Evolution can also occur through genetic drift, mutation, or migration.” [1]

What is meant by natural selection?

“Here are the three principles that form the ‘logical skeleton’ of ‘Darwin’s argument’, according to Lewontin (1970: 1):

Different individuals in a population have different morphologies, physiologies, and behaviors (phenotypic variation). 

Different phenotypes have different rates of survival and reproduction in different environments (differential fitness).

There is a correlation between parents and offspring in the contribution of each to future generations (fitness is heritable)” [3]

As requirements are social constructs, hence evidently without agency, what remains for requirements evolution is that it may refer to change through which the “fitness of a requirement” increases. 

Let’s look at what “fitness” might mean in the context of Darwin’s argument, mentioned above.

“In an intuitive sense, ‘fitness’ can refer to the correspondence between the shape of an object and an empty volume it is placed in: a square peg fits into a square hole. In a more abstract fashion, one might refer to the properties of an entity and how they correspond to the constraints of its context. In a biological setting one could focus on an organism’s traits and how they correspond to various aspects of the environment the organism is living in. Following biological usage, call this concept ‘ecological fitness’. (It has also been called ‘vernacular fitness,’ cf. Matthen and Ariew 2002.) The ‘vernacular’ definition is fraught with difficulties. Suppose, following Dennett (1995) we characterize the relation ‘x is fitter than y’ as follows:

x is fitter than y if and only if x’s traits enable it to solve the ‘design problems’ set by the environment more fully than y’s traits do.

One may ask, What are these design problems? How many of them are there? Is there any way of measuring the degree to which x exceeds y in their solution? Answers to these questions simply reinforce the threat of tautology that faces the theory. To begin with the notion of “design problems” is vague and metaphorical; or, if treated literally, design problems will all be relative to the overarching objective of leaving more descendants. Thus the definition may simply hide the original problem of distinguishing fitness from reproductive rates, instead of solving it.” [4]

If requirements evolution is equivalent, as it seems to be, to the evolution of requirements, then it is change of requirements where requirements change to increase fitness. Let’s take the fitness relation above, attributed to Daniel Dennett, and say that x and y are requirements. 

We get the following:

Requirement x is fitter than requirement y if and only if x’s traits enable it to solve the ‘design problems’ set by the environment more fully than y’s traits do.

Below, I’ll call the sentence above the “naive requirements fitness relation”.

This rewriting begs more questions. If x and y are requirements, what should it mean that they “solve the ‘design problems’ set by the environment”? 

The widest meaning of “the environment” above that I have, is that it covers both the stakeholders who provide requirements, and anything that will constrain, and therefore cannot change through satisfying requirements. That second part, what is immutable relative to a solution to requirements, corresponds to domain assumptions in classical requirements engineering terminology [5] and in my prior work with John Mylopoulos and Stephane Faulkner [6]. You can think of domain assumptions as propositions that will remain true even after the solution has been implemented and is up and running; the solution will not change the environment in such a way that it invalidates any of these assumptions, at least this is what the point is when you classify a proposition in domain assumptions.

If we take that wide reading of “the environment”, then “design problems” oddly enough cover requirements from the stakeholders, because these are the design problems, or in general, problems to solve in the first place.

This mixup of design problems and requirements can be resolved by rephrasing 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.

A couple of important changes happened above relative to the naive requirements fitness relation:

  1. I equated “design problems” to the set of requirements that need to be satisfied. This is the set R1, i.e., R union x. In general, it is the set before x evolves into y. 
  2. Fitness involves comparison of “overall satisfaction”, which I equated to expected utility of a solution; the idea is to say that requirements evolution is about the change of the problem you are solving. It is important to understand that. Phased differently, it means that requirements evolution changes the problem, because it changes the set of requirements to satisfy, and because it changes the problem, it leads to a better overall solution to that new problem, relative to the old one. Perhaps an easier way to look at this idea, is that you start with one problem statement, for which you can do at best some solution S1 which yields expected utility U1, and so after some thought, you see you can change the requirements in such a way that it leads you to a solution S2, which yields U2, and this evolution of requirements is interesting only because U2 is higher than U1.

There are some appealing ideas above. One, the fitness relation over requirements gets a precise definition, via expected utility of solutions (more on this here). Two, requirements evolution is defined as a specific type of requirements change, related to the increase in fitness, rather than referring to any change of requirements. 

But there are also apparent problems with this conceptualization of requirements evolution. Although linking requirements change to expected utility is interesting, it is not clear (and certainly does not correspond to my own experience) that expected utility can be assessed in the way described above, every time we are considering a change in the problem we are solving, i.e., every time we are intentionally changing requirements. Then, there is the obvious tension between the intent in biology with natural selection, and what I’m doing above with the idea of fitness; it seems to me better to use evolution in biology as inspiration, but not use the term “requirements evolution”, and instead use a term detached from the ideas in biology – for example, to talk about fitness-improving requirements change, even utility-improving requirements change. 

This gets me to the second term in the title, requirements change. Clearly, fitness-improving requirements change is a specialization of requirements change, the latter referring to any change to a given set of requirements to satisfy. Not all changes in requirements are fitness-improving in the sense I gave to this above. For example, a requirement may change because domain assumptions changed, and made a requirement impossible to satisfy; in which case we will have to replace that now impossible requirement with a new one. You could stretch fitness-improvement to cover this too, by asying that utility of satisfying an impossible requirement is null, hence it must be replaced. Whether you agree or disagree with this is something I leave up to you.

Finally, the third term in the title is requirements update. I associate requirements update with operations for changing the contents of a set of requirements, or if it exists, a requirements knowledge base (i.e., the set of requirements and a procedure to compute consequences from that set). If there is only a set of requirements, update refers to having the ability (operations) to add or remove items in the set. If there is a knowledge base, this is slightly more complicated, and I leave it for another text (just how complicated depends on what it means to be a consequence from a set of propositions that we call requirements). 

Requirements evolution, change, and update, if you agree with the general ideas above, are related as follows: requirements evolution is a special case of requirements change which improves fitness, change is about replacing a requirement with another one (regardless of why this is done, fitness improvement being one case among many), and requirements update is about addition to, or removal from the explicit requirements (those in a given set of requirements) and/or implicit (computed consequences) requirements from a given set.

References

  1. Millstein, Roberta L., “Evolution”, The Stanford Encyclopedia of Philosophy (Winter 2021 Edition), Edward N. Zalta (ed.), URL = <https://plato.stanford.edu/archives/win2021/entries/evolution/>.
  2. Futuyma, Douglas J., 2005, Evolution, Sunderland, MA: Sinauer Associates.
  3. Gildenhuys, Peter, “Natural Selection”, The Stanford Encyclopedia of Philosophy (Winter 2019 Edition), Edward N. Zalta (ed.), URL = <https://plato.stanford.edu/archives/win2019/entries/natural-selection/>.
  4. Rosenberg, Alexander and Frederic Bouchard, “Fitness”, The Stanford Encyclopedia of Philosophy (Fall 2021 Edition), Edward N. Zalta (ed.), URL = <https://plato.stanford.edu/archives/fall2021/entries/fitness/>.
  5. Zave, Pamela, and Michael Jackson. “Four dark corners of requirements engineering.” ACM transactions on Software Engineering and Methodology (TOSEM) 6.1 (1997): 1-30.
  6. Jureta, Ivan, John Mylopoulos, and Stephane Faulkner. “Revisiting the core ontology and problem in requirements engineering.” 2008 16th IEEE International Requirements Engineering Conference. IEEE, 2008.