From the author of
From the author of
From the author of
The Rationale helps to overcome the possibility of inadvertently writing a solution instead of the real need. It also helps you to understand what the stakeholder really needed when she gave you that solution. In the following example the product is a machine to sell tickets for a city's metro rail system. Unfortunately, someone has given a solution rather than a requirement.
Description: The product shall provide a touch screen showing the rail network route map.
This might seem an attractive solution. Alternatively, it might not when you consider that people who are unfamiliar with the network may take a long time to find their station to the annoyance of the regular commuters who are in a hurry. Let's find the rationale by asking why the requirement is needed.
Rationale: Passengers must provide their destination for the fare to be calculated.
This rationale reveals that the real need—in other words, the real requirement—is to calculate the correct fare, which relies on the passenger's destination. How the passenger provides her destination is best left to the user experience designer and the solution architect. The touch screen might be the best way to accomplish this goal, but then again, it probably isn't.
Then we come to the Fit Criterion. This is a measurement of the requirement, that makes the solution testable, and acceptable. You can call this an acceptance criterion if you prefer; we use the term "fit" to say that the solution fits the requirement. By negotiating the Fit Criterion with the stakeholder, you (and the stakeholder) learn more about the real need. The original assumed solution was to use a touch screen. Presumably this was an attempt to make it more efficient for passengers to buy tickets. As there are many passengers using the metro, there appears to be a need for speed. We propose that the final requirement, with its Fit Criterion, looks like this:
Description: The product shall provide a touch screen showing the rail network route map.
Rationale: Passengers must provide their destination for the fare to be calculated.
Fit Criterion: 90% of passengers can buy the correct ticket within 30 seconds.It has turned out that the real requirement is for passengers to be able to accurately buy their tickets by providing a destination and do so fairly quickly and conveniently. That's the need.
At this stage, the original description is looking shaky so let's rewrite it as this:
Description: The product shall provide a way for Passengers to indicate their destination.Now the requirement is complete and describes the real need. You now leave it to the solution designers and the UX designers to come up with a solution that fits the need. Whether they use a touch screen or not is irrelevant. The designers will have succeeded if their delivered solution fits the requirement.
So why not just ask "why?" repeatedly, or write a fit criterion at the outset to prevent you from writing a description that turns out to be a solution? You can of course do that, but it is usually difficult. Stakeholders have their assumed solutions and insist those are what they want. You cannot immediately discount them. In our experience it is better to immediately capture whatever is said and use this as the starting point for interrogating the stakeholder about the rationale and fit criterion. By doing so, you both arrive at the real requirement.
When you write requirements and not solutions, you capture the real business problem. Which, after all, is the point of doing requirements discovery.