Approaches to Requirements Satisfaction

Ivan Jureta

Given a set of requirements to satisfy, and assuming they can be satisfied together, are we always aiming to find the solution that maximizes the level of satisfaction of all these requirements? Maximization of satisfaction, or more generally, finding an optimal solution to given requirements, is a common way of thinking about what we want to achieve. It is, however, not the only approach to solving requirements – I outline several, and discuss their differences. I wrote about some of these approaches in the past, in [1].

Suppose that there is a set of requirements; you can think of it as a list of statements, written in English, in the form of “the solution should do A”, “the solution should do B”, “the solution should be such that if we measure its performance on C, then we should measure at least X”, “it should be the case that D”, “it should be true that E”, and so on. In other words, you have statements that describe what should be satisfied in the future by something, generically “a solution”, that needs to be made or bought. “The solution” could be software, hardware, some combination of these, but also another kind of tool or artifact – for example, an employment contract is designed to satisfy specific requirements, coming from the employer and the employee; a survey is designed to help validate specific hypotheses; and so on.

I distinguish between the following approaches of requirements satisfaction:

  • Optimization
  • Satisficing
  • Primary Design
  • Iterative Design

With Optimization, your aim is to pick the solution which satisfies better the requirements than any other considered solution. For this approach to work, it is necessary to have more than one solution to choose from, and to have a mapping between solutions and requirements – for example, a solution S1 may satisfy a requirement R1 better than another solution S2 (such relationships need to be known). (Note that you might have one parameterizable solution, so the problem is to choose optimal parameter values – this does not change the discussion here.)

Satisficing consists of picking the first solution that manages to go above some satisfaction threshold that you set. For example, if you split requirements into mandatory and nice-to-have, then a satisficing strategy could be to pick the first solution that satisfies all mandatory requirements, and ignore which nice-to-have ones it satisfies. Satisficing comes from Herbert Simon’s work on bounded rationality [2,3,4]. A slightly different approach, although still a case of satisficing, is to replace requirements with weaker versions thereof, or approximations, and to find the optimal solution for these proxies, and accept that as the satisficing solution for original requirements. 

I associate Primary Design with cases in which there is no explicit consideration for multiple solutions, but the focus is on designing one solution to meet the requirements, and that solution is such that it is prohibitively costly or impossible to incrementally improve an incomplete variant thereof. The first solution needs to satisfy complex, and demanding requirements, and will require significant resources to make. Think of hospitals, airports, manufacturing plants, and the like. Although these can still be improved, and are expanded, restructured, and so on, across their typically decade and more long lifecycle, the intent when doing the initial design is in fact to avoid substantial revisions of that design later, when the solution is up and running.

In Iterative Design, we pick an option early on, focus on delivering a minimal viable variant thereof, and then make improvements through changes to the initial solution. This is common when the solution includes software. 

A common question is if it is possible to reach the optimal solution without optimization, through a different approach to requirements satisfaction. The problem with this is that the only way to know that you have found the optimal solution is via Optimization. Another problem is that the “optimality” of the solution you find – whichever approach you pick – is a function of what you knew and assumed when coming up with the solution. As you learn something new, as time passes, you may decide that the same requirements, at that later time, no longer apply, and revised requirements do, in which case there’s a new, even if unknown, optimal solution for these new requirements. This time-specificity of an optimal solution suggests that, in cases when requirements change, we need to prefer an approach to requirements satisfaction that can accept and can integrate the new information. 

Another topic is which relationships can there be between these approaches. For example, can each iteration in Iterative Design involve Optimization? I leave these for other texts.

References

  1. Jureta, Ivan J., Stéphane Faulkner, and Pierre-Yves Schobbens. “Achieving, satisficing, and excelling.” International Conference on Conceptual Modeling. Springer, Berlin, Heidelberg, 2007.
  2. Simon, Herbert A. “A behavioral model of rational choice.” The quarterly journal of economics 69.1 (1955): 99-118.
  3. Puranam, Phanish, et al. “Modelling bounded rationality in organizations: Progress and prospects.” Academy of Management Annals 9.1 (2015): 337-392.
  4. Klaes, Matthias, and Esther-Mirjam Sent. “A conceptual history of the emergence of bounded rationality.” History of political economy 37.1 (2005): 27-59.