The time has come to eradicate requirements as a mechanism for communicating between different groups inside and between organizations. Although requirements have been used as the key mechanism to describe the functionality desired from the system since the beginning of software engineering as a field, over recent years the limitations have become increasingly clear to me. Some of these problems include:
- Whispering game: Especially in large organizations, the distance between the customer and the R&D team is very far. This means that requirements are transferred and transformed between different functions (sales, marketing, product management, etc.) and what reaches the R&D team deviates significantly from the original need.
- Jumping to solutions: It is very difficult for people describing requirements to avoid jumping to solutions instead of describing needs. This constrains the team in realizing the optimal solution and fails to employ the full creativity of the team.
- Tacit knowledge: Every non-trivial system has intricate aspects that are difficult to communicate. In my experience, requirements only communicate the obvious 10% of expected functionality or outcomes and fail to capture the 90% that is hard.
- Open for multiple interpretations: No matter how precise, many requirements are fuzzy and open for different interpretations. This leads to the classical situation where the team delivers something that is far from what the customer desired.
- Distance to the customer: Requirements are used as a solution for keeping the teams and customers apart and for the team to avoid having to learn the domain. Modern, agile software development practices have taught us that this simply doesn’t work: teams need to meet the customer, learn the domain and build empathy. This is the only way to build software that meets the needs of customers.
- Conflicting interests: Many problems in software engineering originate from conflicts within the customer’s organization where different roles and functions contradict each other. Requirements tend to obfuscate these conflicting interests between different parts of the client organization instead of help resolve these. This easily leads to a situation where the team is blamed for dysfunctions at the customer side.
Instead of requirements, we need instead to start focusing on outcomes: what does the customer seek to accomplish with a new system or new functionality in the existing system. For instance, when requesting new functionality, the focus should not be on the requirements on the functionality, but rather on the measurable changes in customer and system behavior that we’re looking to accomplish. For instance, for a free online game showing ads as a revenue generator, three factors would be important: new users, recurring users and revenue. Whatever the customer requests, the intended outcome will be to drive up one or more of these factors without (too much) negative effect on the other factors. If at all possible, these desired outcomes should be expressed quantitatively.
As most functionality added to a system will affect some factors positively and others negatively, we need to describe what the relative priority is. This requires us to assign a weight to each factor and to describe the expected outcome as a value function. For our fictive online game, the value function may look as follows:
Value_function = 0.3 * % New Users + 0.3 * % Recurring Users + 0.4 * % Revenue
When the team agrees with the customers on the factors to affect and suggestions for how this might be accomplished, development shifts from a “meet the requirements” model to an experimental mode of development where the team tries out different solutions in order to positively affect the value function for a system or a feature. This, in turn, helps the organization to shift from an opinion driven to a data-driven organization.
For those organizations that struggle to get away from requirements, there is an intermediate step: Rather than describing requirements, insist on capturing the desired functionality as test cases. This means that the customer or product manager at the beginning of every sprint meets with the team and together with the team agrees on the test cases that need to pass for the desired functionality to be realized. In fact, in this case, we use the test cases as requirements. Although only a step on the way, it does address several of the aforementioned challenges of traditional requirements.
Concluding, it’s time to let go of requirements as the mechanism to capture the functionality desired from the system.Instead, focus on outcomes, adopting an outcome-driven development model and moving towards a much more experimental approach. This blog post only scratches the surface of this topic. In the short book that I show below, I provide much more detail on how to move from requirements-driven to outcome-driven development, so do take a look.
You are right, requirements separate developers from users, while providing the project manager and customer representative with legal power.
As long as we need contracts, reqs will survive as a basis for dispute and agreement.
Reqs reduce complexity of involving diverse developers and diverse users, and the cost of Post-Deployment Therapy is usually acceptable and deamt inevitable.
You say no more requirements but then you make statements that are clearly requirements
IMHO requirements are part of the solution. Done poorly they can be part of the problem. They are part of the definition of the solution. A conops describes what the customer wants and hopefully needs. It’s the scenarios that describe function and operations.
ICD’s describe the interfaces that exist. These are hard to get right. The requirements set the verifications
Requirements always need to be accompanied by discussion about why they exist. Once you have this set done you are in a reasonable position to deliver operating code. If you can’t get at least conops and icds written then you are in experimental coding land. OK for quickies but impossible for creating complex systems