|
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?"
"Yes."
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.
|
