Problem domain
Contents
Introduction
In this section, we explore and document the problem domain in such a way that we can derive an assessment framework for solutions.
The approach is based on the following principles:
- Outcome-driven analysis: what is the expected contribution of any solution
- Systemic approach: where does the solution fit in the bigger picture
- Tradeoff analysis: how do the inherent design decisions of a solution affect the realisation of the various requirements, how do multiple solutions compare
Outcome-driven Analysis
In order to be able to assess a solution, one needs to know the requirements it has to fulfill. These requirements need to be relevant and significant and have to define the problem completely.
To achieve this, some guidelines for formulating requirements are required:
- The requirements need to be complete from a requirements type perspective,
- The requirements need to be complete from a scope perspective,
- The requirements should be derived from expected outcomes,
- The requirements need to be specific and measurable,
- The requirements need to be selected on their significance,
- The requirements should not unnecessarily constrain solution scenarios.
Types of requirements
To any system, there are three categories of requirements:
- functional requirements (what the system should do),
- quality attribute requirements (how well the system satisfies the needs) and
- constraints (non-negotiable requirements, i.e. what it must be adhered to).
The aim is to design a system that will deliver the functionality in such a way that the quality attribute requirements are met and that it fits within the constraints. This implies that a set of requirements cannot be complete without covering these three types.
Scope perspective
Requirements should address the full scope of the problem. This encompasses an internal dimension (the features inside the solution) as well as an external dimension (the way the solution contributes to the ecosystem it is part of). The scope can only be understood when looking at the full system (see ‘systemic approach’) and understanding the role of the solution within this system.
Outcome-driven requirements
Besides needing to address the full scope, requirements should address nothing but the scope and should not unnecessarily constrain possible solutions.
There is virtually no limit to the requirements that can be stated. Among others, stating characteristics of a known solution as a requirement is a common pitfall, as is stating requirements that are not relevant for the problem at hand.
The way to avoid unnecessarily constraining the solution is to derive the requirements directly from the outcomes that need to be achieved for the problem. We will look into these expected outcomes as a frame to select the significant requirements.
Specific and measurable
Making requirements formulation specific and measurable is a tough challenge. Techniques like quality attribute scenarios exist but are notoriously time-consuming and therefore only applied to the most significant requirements. We choose to seek clarity in formulation with less emphasis on measurability. Iterations of this documentation might address this aspect.
Significance
For most real-world problems, no solution can be designed that meets all requirements (see trade-off analysis). The design approach is then to design for the most significant requirements - the ones that yield the most value and have the highest impact.
Not unnecessarily constrain the solution
Requirements should be solution-neutral and constraints should be external - things that are not under the control of the designers of the solution. Anti-patterns are disguising a solution as a requirement (“it should capture Bluetooth signals”) or defining arbitrary constraints (“it must use Bluetooth for proximity tracking”).
There is of course value in prior knowledge, like knowing or being convinced that only technology A or B is feasible. The proper place for that is in == solution patterns == - where solutions are documented with their inherent trade-offs that can be transposed to the problem at hand. Proximity tracking through Bluetooth is such a solution pattern, decentral architectures, just like centralised architectures, are solution patterns. They can be considered as part of a solution of how to preserve privacy, but they are not requirements themselves.
Systemic Approach
Any technological solution has to fit in a broader ‘system’, in our case this is the context of the current COVID-19 crisis, to combat the spread of the disease. This system encompasses participants and their interactions, resources and their allocation, processes, the technology supporting the processes, the relationships between those components and the way value is generated and measured. This holistic approach is necessary to align the components with the objectives of the whole and to avoid local optimisation in one component at the expense of global optimisation at the level of the system as a whole.
Applied to the problem domain at hand, global optimisation is to be pursued at the level of effectively combating the pandemic, not at the level of for instance contact tracing only.
Trade-off Analysis
Technology is famously unruly. By that, we mean that there is rarely just one solution for any given set of requirements. Trade-offs (i.e. a decision that favorably impacts one requirement at the expense of another requirement) are unavoidable. A common pitfall is to compare solutions based on pros and cons. This will rarely be successful. People can debate forever about why any given solution is better and the other solution is worse without ever reaching an agreement, or leading to a haphazard agreement - an agreement with suboptimal trade-offs or a consensus that is made by people who were unaware of the trade-offs.
For more complex problems the analysis of the trade-offs should be front-and-center. This requires having a complete view of the requirements, understanding their relative priorities, and designing the system for meeting the highest priority requirements first. The approach is then to generate multiple solution sets that meet the prioritised requirements in different ways. Doing this will reveal the trade-offs inherent to the solutions. Decision making is then about carefully choosing trade-offs.
Keep in mind that there is always the possibility that there is no solution with acceptable trade-offs. In that case, the only option is to revisit the requirements or to forego the solution.
