·

Are Refinement and Decomposition Equivalent?

Ivan Jureta

In requirements modeling languages, refinement and decomposition show up as two relationships over requirements. Both terms are also, somewhat confusingly, used to refer to processes for changing the information in a requirements model. Although they have different origins, and appear in different modeling languages, they are actually not independent relationships. I will argue below that decomposition is a special case of refinement.

Following classical requirements engineering literature, I’ll assume below that we have some set of requirements R and domain knowledge K; together, I’ll call them “the problem”. To solve the problem, a specification S needs to be defined, such that K and S entail R. In that context, here is how Zave & Jackson [1] use the term refinement; it is a process of changing R and S until K and S entail R. 

The analogy to program refinement is clear if you also read Wirth’s “Program development by stepwise refinement” [2]; an excerpt is below.

Wirth mentions decomposition in the second paragraph in the excerpt above, as a way to progress through steps when doing refinement. 

Going back to requirements, and if I follow the analogy that Zave & Jackson mentioned, then I have to take the following seriously: if I say that a requirement R1 is decomposed into R2 and R3, then I also said, according to analogy with Wirth’s program refinement, that R1 is refined by R2 and R3. 

In short, if you accept that the refinement of requirements (the process of refinement), is analogous to the process of program refinement, then any case of decomposition is a case of refinement. 

Refinement and decomposition are equivalent if every refinement is also a case of decomposition. Is that the case?

If we still sticking with the analogy to Wirth’s program refinement, then it turns out that every refinement of a requirement is also a decomposition of the requirement, and vice versa. This is the case if, again we keep the analogy, and if we agree with Wirth in the following claim.

Let’s now look at how the idea of refinement is adopted and adapted in goal-oriented requirements engineering. Below is how Darimont & van Lamsweerde define goal refinement [3]; for all practical purposes in the present text, I’ll assume that “goal” is synonym with “requirement” (although this is a simplification, as van Lamsweerde takes a slightly different view [4], where a requirement is a goal that can be assigned as a responsibility to an agent, whereas there can be goals which cannot – and therefore need to be further refined until they can be called requirements).

A goal (requirement) G is refined by goals (requirements) G1, G2,…, Gn if and only if the following four conditions are satisfied (the excerpt below is from [3]):

The entailment condition requires that the refining requirements (G1…Gn) are sufficient to conclude the refined requirement G. The minimality condition says that we cannot remove one or more requirements in G1…Gn and still refine G with what’s left, i.e., there is no simpler refinement of G than G1…Gn, all are necessary. The consistency requirement is needed because in its absence, an inconsistent set of refining requirements would satisfy any requirement; this is because of the principle of explosion of classical entailment [5]. Finally, the fourth condition says that we are not simply replacing a requirement with another one, but with more than one.

Eric Yu included decomposition in the i-star modeling language, an oft-cited requirements modeling languages [6]. It is defined as follows [7].

What is apparent from goal refinement, is that if you understand “decomposition” to mean that you are replacing G by more than one other requirement, then indeed, you could argue that whenever you refine a requirement, you are in fact decomposing it.

So refinement and decomposition are synonymous, in case you literally look at the number of requirements.

A more nuanced approach is to ignore numbers of propositions or requirements, and instead observe that refinement can result in a change of the requirement. Consider the following example, a requirement for a system that needs to perform some computation within a threshold amount of time:

R: Time to compute the result should be under 100 ms.

Now, let’s say that the computation can be broken into three steps, A, B, and C. We could indeed say that we decomposed R if we refine it into R1, R2, and R3 which are as follows:

R1: Step A should be performed in under 30 ms.

R2: Step B should be performed in under 50 ms.

R3: Step C should be performed in under 20 ms.

If I write the implication “R1 and R2 and R3 implies R”, then the goal refinement conditions hold, and refinement and decomposition are equivalent over R, R1, R2, and R3.

But let’s say that the relevant stakeholders now said that they want the computation to be done in under 70 ms. I could refine R to state this change. Namely:

R4: Time to compute the result should be under 70 ms.

K1: Stakeholders changed their mind and are asking that the computation is done in 70ms instead of 100 ms. 

If I add the implication “K1 and R4 imply R”, I have satisfied all goal refinement requirements, and I can say that I refined R. But can I also claim that I decomposed R? I would argue not, and so we end up with a possibly confusing conclusion, that if refinement is defined as goal refinement is, then decomposition is a special case of refinement. I do take that conclusion seriously, as there are no reasons that I see, based on the definition of goal refinement, for why the refinement or R with R4 and K1 is incorrect. So program refinement and requirements refinement are not equivalent, and the analogy of the latter to the former is, as is clear above, debatable.

References

  1. Zave, Pamela, and Michael Jackson. “Four dark corners of requirements engineering.” ACM transactions on Software Engineering and Methodology (TOSEM) 6.1 (1997): 1-30.
  2. Wirth, Niklaus. “Program development by stepwise refinement.” Pioneers and Their Contributions to Software Engineering. Springer, Berlin, Heidelberg, 2001. 545-569. (The paper first appeared in 1971.)
  3. Darimont, Robert, and Axel Van Lamsweerde. “Formal refinement patterns for goal-driven requirements elaboration.” ACM SIGSOFT Software Engineering Notes 21.6 (1996): 179-190.
  4. Van Lamsweerde, Axel. “Goal-oriented requirements engineering: A guided tour.” Proceedings fifth ieee international symposium on requirements engineering. IEEE, 2001.
  5. Priest, Graham, Koji Tanaka, and Zach Weber, “Paraconsistent Logic”, The Stanford Encyclopedia of Philosophy (Summer 2018 Edition), Edward N. Zalta (ed.), URL = <https://plato.stanford.edu/archives/sum2018/entries/logic-paraconsistent/>. 
  6. 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.
  7. Yu, Eric. “Modeling Strategic Relationships for Process Reengineering.” Social Modeling for Requirements Engineering 11.2011 (2011): 66-87.