THE CASE
We need a faster coconut-cracking machine
Upper management decrees: "We want to sell more coconuts." Some other manager proposes: "Then we will definitely need a faster coconut-cracking machine !"
The proposal is concrete, costable and engineerable. What has not been established is whether cracking capacity is what prevents increased sales.
THE TRAP
Solutions make uncertainty disappear
A specific proposal feels like progress. Specificity, plausibility and authority can create the impression that Requirements Engineering has already been done.
THE FAILURE
The answer has occupied the place of the question
A proposed solution has been allowed to take the place of the problem and need it is supposed to address.
FOLLOW THE REASONING
Objective
→
Problem / Need
→
Requirement
→
Solution
THE DIAGNOSTIC
Take the machine away
Remove the proposed solution.
And then ask yourself: "Can the team still explain the desired outcome, the obstacle that currently prevents it and what actually needs to change?"
THE CONSEQUENCE
Doing the wrong thing very well
The solution can be specified, designed, verified and commissioned correctly while the original objective remains unmet.
THE RESPONSE
Keep the solution --- change its status
Does that mean all the work which has been done is in vain ? Not at all:
Keep it as a candidate. Reconstruct
objective → problem → need → requirements → candidate solution,
then assess the candidate against the established need.
QUICK TEST
Remove the proposed solution
Can the team still explain the problem and the need it is intended to satisfy?
Originally published as part of the RequiScribe Requirements Failure Field Guide, Season 01.
Top comments (0)