1. Where the goal is not to design some complex artefact but to deliver some set of outcomes. For example, to make an organization more efficient or intelligent, to make a tax system more equitable, or to make a community more self-sufficient.
2. Where the target system is complex and governed by conflicting value systems, so that the challenge is to formulate and negotiate a series of interventions, from which a useful and acceptable change to the target system might emerge.
3. Where the agency for change is embedded within the target system, rather than being external. Anyone who gets involved in the project becomes part of the target system, and it no longer makes sense to ask the popular question "are you part of the problem or part of the solution?"
One of the attractions of the problem/solution distinction is that it helps to build agreement around a statement of the problem, and focuses the debate on different ideas and preferences for solving the problem. But to see the limitations of this distinction, we only have to look at the political sphere. There is surprisingly little difference between the political parties in their statement of the fundamental problems facing the government; but there are wide differences in the policy instruments they advocate to solve these problems. Of course, these differences are not just alternative sociotechnical designs, but are produced by different belief systems (how the economy really works, what are the root causes of crime and terrorism, and so on) as well as different value systems (what kinds of prosperity and well-being matter most).
So is there a discontinuity between highly complex and messy sociopolitical problems on the one hand and relatively simple and self-contained engineering problems on the other? To answer this kind of question, some people appeal to a simplistic interpretation of the Cynefin framework, treating it as if it were a simple 2x2 matrix mandating different problem-solving or problem-tackling methodologies according to the degree of complexity in the problem domain - but of course this kind of answer begs lots of questions about the relationship between problem and solution which a more subtle and sophisticated application of Cynefin should expose.
Any human system (including organizations) will display some degree of complexity and messiness, and it is in this context that the concept of "requirements" needs to be understood. In a separate post, I shall explore how such a concept of requirements applies to organizational intelligence.
Requirements engineering is about the interaction between five kinds of system. In the problem-solving paradigm, these fit together as follows.
- A deliverable system is designed to be a "solution" to some "problem". (In a simple case, this could be a single complex artefact or a coordinated series of interventions.)
- A target system is where the "problem" is located, and where the "solution" must fit. (In a simple case, this could be an organization unit or operational business process.)
- A value system provides the criteria justifying why the problem is a problem, and why the solution would count as an improvement. (In a simple case, there is a single sponsor whose value system is paramount.)
- A belief system, an explanatory model or theory that explains the cause of the problem and the plausibility of the solution. (In a simple case, everyone broadly shares the same belief system.)
- An intervention system, a force of people and resources mobilized to do something relevant. (In a simple world, the intervention system is a project team under the exclusive governance of a project sponsor with a unified and dominant value system.)