Vesa Purho
Development Manager, Nokia

Many of us are familiar with the situation in which we have given our requirements for a new tool or document and what we receive fulfills all those requirements but still is more or less not what we actually wanted. There are many aspects related to creating requirements: selecting sources of requirements and techniques for eliciting them, creating guidelines for documenting them, and mapping the requirements to the specification documents for traceability. But in this article, I concentrate on the importance of asking why.

“Why” is a very important word in requirements management, and it must be repeated many times to get to the bottom of the various statements that are first given as requirements. As an example, here are actual requirements we collected for our new single-sourcing environment. They concern configuration management:

  • Creation of a new configuration and updating of a configuration must be quick and easy: creation of a configuration, freezing, publishing.
  • Must be possible to copy-and-paste and drag-and-drop wanted modules at wanted levels from another configuration.
  • Configuration management and creation possible through user interface.
  • Possibility to import an XML configuration in the system.

The last two are already partly contradictory. One wants a user interface to create the configuration, and another wants to create the configuration as an XML file and import that into the system. Of course, those could be complementary solutions but do we want, or have resources, to build two ways of creating configurations? However, the main question is, are these all unique and independent requirements? The last three are actually implementation proposals, so what is the requirement behind them? The first one does not offer an implementation alternative, so it is a requirement of sorts, but what is “quick and easy?”

If you receive these kinds of requirements, it would be a good time to start using the “why” word. The discussion might go something like this:

     “Why do you need to import an XML configuration in the system?”

     “So that I can create the configuration in an XML editor.”

Recognize that you must not stop after the first “why.”

     “Why do you want to create the configuration in an XML editor?”

     “Because that’s the way we have done it so far in our old system, and the user interface in the existing one is horrible.”

     “Why is the current user interface horrible?”

     “Well, there is no drag-and-drop, so making any changes to the configuration is difficult and laborious, and also the way to approve the modules in the tool is ridiculous.”

     “So if the user interface was better, you would not necessarily need to be able to do the configuration in an XML editor?”

     “Well, I guess so.”

     “So in essence, what you require is that making changes in the configuration and changing the status of the modules has to be easy?”


Now we have ended up with a requirement that does not imply any particular solution. As you can see, it is essentially the same as the first of the requirements, and if you were to have a similar discussion with the people who presented the other requirements, you would probably end up with a similar result. You would have effectively reduced the number of requirements from four to one, which is good, as there probably will be a lot of requirements, and managing them takes resources as well. The more there are, the more there is overlap and contradiction among them.

As mentioned earlier, the result is not yet quite satisfactory, as there still is the word “easy,” which may mean different things for different people. Then you have to start asking the “what” questions, “what do you consider as…” or “what are the characteristics of…” but that is an issue I’ll discuss in my next article.

The “why” is a very powerful and important word in many situations. When an SME says “this has to be in the user manual,” you should ask “why does the user need this information?” It may well be that it has to be in the manual but when asking “why” you may end up putting the information in another place in the document than originally proposed. Or, instead of putting in that information, you end up developing something else that more effectively corresponds to what the user actually needs instead of what the SME says is needed when thinking from the product point-of-view. Sometimes the SMEs don’t have an answer to the “why.” That may then lead you to talk to marketing or product management to get the customer requirements behind some feature or to other sources of information to confirm what the users actually need, which in turn will make the users happy.

Asking the “why” lengthens the time it takes to collect the requirements, and you may not feel comfortable starting to question what people have told you, but it is an essential step to move forward in the design phase and to come up with a collection of understandable and concise requirements.

This article is the personal opinion of the author and does not necessarily reflect the opinion or practice of Nokia.