Rationale for Rationale

This is the eleventh in a series that explains the thinking behind the Volere [1] requirements techniques— previous and future articles explore aspects of applying these techniques in your environment.

This article focuses on the often-asked question: why, when I ask for requirements, do people give me solutions and what can I do to get the real requirement?

Suppose you are a business analysis trying to discover the local government’s requirements for clearing snow from roads and footpaths. You ask the road-engineering supervisor for his requirements and he tells you, “We want more staff dedicated to snow clearance”.

But is that really the requirement? It sounds more like a solution, but you cannot be sure of the problem. When you ask, “Why do you need more staff?” the supervisor tells you that, when the conditions are extreme there are not enough people to shovel the snow and spread salt and gravel on the sidewalks. Now the real problem starts to emerge – you now understand that under certain snow conditions, sidewalks have to be made safe for people to walk on within a short period of time. One way – the supervisor’s way – of solving the problem is to have more people to shovel the snow. However, now that you understand the problem – clearing the sidewalks – there must be other solutions to choose from.

Instead of using manual shovels perhaps a few small mechanical snow shifters (rather like lawn mowers for snow) could be used to clear the sidewalk with less person power. Or, if you were in Iceland, you could take advantage of the copious geo-thermal energy and install heating pipes under the sidewalks to melt the snow. Perhaps you could farm the problem out to the neighborhood kids, and pay per metre of sidewalk cleared (the kids would have to prove they actually did it with before and after smartphone photos). There are so many possibilities that you can come up with providing you understand the problem.

But a clear statement of the problem is not usually what you hear first. Just like the road engineering supervisor, most people are likely to give you their solution, and not state the problem to be solved. So why does this happen?

Naturally enough we all see the world in terms of our own personal, tangible world. We do not, generally speaking, think in abstractions. Instead, we give our attention to the concrete things that we can see, touch and hear – things that are real for our view of the world. So when we want to make an improvement to our world, we look at how things work now and ask for some incremental improvement. This, as in the case of the road engineering supervisor, usually results in a solution rather than a statement of the underlying problem. And often it will not be the best solution because the requestor lives in his own world and is probably not aware of other possibilities for solving his problem.

We have heard analysts despair over peoples’ lack of ability to state the real problem, “How can they expect to get a good solution when they don’t tell me their real requirements?” But it’s wiser to face the reality that the stakeholders who have the requirements are not trained analysts and are unlikely to realise, unaided, that they are asking for a solution, not stating the requirement.

Our experience has been that the most effective approach is to accept the fact that people ask for solutions, and then make the abstractions that are necessary to uncover the real problem.

We suggest that you start by accepting whatever the requestor asks for. Don’t discount what they have asked for, and don’t say (out loud) that it is a solution not a requirement. Instead ask, “Why is this important to you?”. Make it clear that you are trying to understand the overall business impact and it’s likely that you will make some mistakes unless you understand how this requirement fits into the overall business.

Sometimes you need to ask why more than once:

Stakeholder: “I need this extra total on the screen”

Analyst: “Why is this important to you?”

Stakeholder: “Because I need to compare the figure with the previous month”

Analyst: “Why do you need to make this comparison?”

Stakeholder: “So that I can identify the best selling product and make sure there is enough stock.”

By asking these why questions the analyst is getting closer to the stakeholder’s real requirement: to be able to monitor the best selling product of the month and ensure that there is enough stock. And once the analyst has this level of understanding she might be able to do much more to help the stakeholder to find and solve the real problem.

Perhaps for this stakeholder it would be more useful to make a progressive daily analysis and projection of which products are selling best and compare these trends with the inventory; the purpose being to raise a stock alert if needed. The stakeholder probably won’t ask for these things because he is limited by how things work at the moment in his world. It takes analytical thinking to look past the perceived constraints and discover the real problem and the opportunities that presents.

One of the components of a Volere atomic requirement is the Rationale – a statement that explains why the requirement is important to the requirer. This justification of the requirement is not only useful to the business stakeholder and the analyst, but is also vital input to making the best development and testing choices.

Unless you know why something is needed, and why it is important, it is very difficult to choose between alternative ways of achieving it.

Taking the idea of rationale further, it is also very valuable to record the rationale for making a particular design decision:

“We considered alternatives A, B and C. We chose B because it will provide the fastest responses given our current systems architecture, and performance requirements are the most critical to this part of the solution.”

Additionally a trail like this is very helpful to the many people who need to maintain the system into the future. Keep in mind that whatever it is that you are building today, it needs to last and be maintained for probably a decade. Without an understanding of why design decisions were made, maintainers could well make changes that have disastrous side effects.

More information is available:

• in three books written by James Robertson & Suzanne Robertson, the most relevant to this article is Mastering the Requirements Process – third edition: Getting Requirements Right.
• in Volere seminars and consulting

Authors: Suzanne Robertson and James Robertson, The Atlantic Systems Guild