Requirements as Decision Criteria
Assuming two or more alternative solutions are available, to make a decision means to pick only one of these, or, equivalently here, to commit to one and ignore others. What role do requirements play in such decision making situations?
In classical decision theory [1], the best solution is the one that yields the highest expected utility; expected utility, in turn, depends on the uncertainty and utility (relatively desirability) of outcomes that the solution is assumed to result in. Each alternative solution is assumed to result in different outcomes, or same outcomes with different likelihood, where these outcomes can be compared in terms of how desirable they are relative to each other.
Classical decision analysis [2] follows the same ideas, although it is practice-oriented. It provides a method for how to collect and organize information in order to identify alternative solutions, compare them, and estimate the uncertainty of their outcomes. For example, decision analysis tries to help with how to elicit preferences over outcomes, and how to quantify uncertainty via probability.
Requirements are not a concept that appears in classical decision theory and decision analysis. Although I emphasize “classical”, I am not aware that oft-cited non-classical decision theories pay any special attention to requirements [3,4,5].
In requirements engineering, a requirement refers to a desirable property a solution should satisfy [6,7,8]. It is common to distinguish between different types of requirements, such as hard requirements which are either satisfied or not by a solution, and soft requirements (a.k.a non-functional requirements) which involve a more complicated scale for measuring how well a solution satisfies them.
If in decision analysis criteria play the role of determining if something qualifies as a possible solution, i.e., an alternative solution to consider, then a requirement has the role of criterion in a decision problem.
It is worth noting that having requirements that are related by refinement, or decomposition relations makes no difference to the above: the most detailed requirements will act as criteria, with satisfaction propagating upwards in the requirements forest. Namely, if you have a requirement R0 refined by R1, R2, and R3, and they are all leaves, then R1, R2, and R3 are criteria in the decision problem, and R0 will be satisfied by every solution which satisfies all three – R1, and R2, and R3.
References
- Schoemaker, Paul JH. “The expected utility model: Its variants, purposes, evidence and limitations.” Journal of economic literature (1982): 529-563.
- Keeney, Ralph L. “Decision analysis: an overview.” Operations research 30.5 (1982): 803-838.
- Starmer, Chris. “Developments in non-expected utility theory: The hunt for a descriptive theory of choice under risk.” Journal of economic literature 38.2 (2000): 332-382.
- Machina, Mark J. “Non-expected utility theory.” The new palgrave dictionary of economics 2 (2008).
- Harrison, Glenn W., and E. Elisabet Rutström. “Expected utility theory and prospect theory: One wedding and a decent funeral.” Experimental economics 12.2 (2009): 133-158.
- Zave, Pamela, and Michael Jackson. “Four dark corners of requirements engineering.” ACM transactions on Software Engineering and Methodology (TOSEM) 6.1 (1997): 1-30.
- Van Lamsweerde, Axel. Requirements engineering: From system goals to UML models to software. Vol. 10. Chichester, UK: John Wiley & Sons, 2009.
- 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.
