User Requirements – The Lesser Known Facts

Introduction

Often the requirement engineers get important guidelines like:

“Get extensive user involvement”

“Projects don't fare well when they don't have extensive user involvement”

Albeit being true, these statements seem to be overstated. Getting the requirements from the users is not an easy

task for the requirement engineers. Various issues need to be considered before involving the users to gather the requirements, like:

1. Do the users really know what they want?

2. Can they express the requirements effectively even if they know what they want?

3. Is it easy to express the requirements in such a way that the other person understands it correctly?

For example, consider a story of a blacksmith: There was a blacksmith who complained: "I am not well, and my work is too warm. I want to be a

   stone on the mountain. There it must be cool, for the wind blows and the trees give a shade." A wise man who had power

  over all things replied: "Go you, be  stone."  And he was a stone, high up on the mountainside. It so happened that a

   stonecutter came that way for a stone, found this stone, and began to cut it. The stone cried out: "This hurts! I no longer

   want to be a stone. A stonecutter I want to be.  That would be pleasant."

   To cut the long story short, the wise man

   granted all the wishes of the black smith in vain. Every time the black smith was unhappy and wanted to be something

  else. Finally the wise man gave up on him. Did the black smith know his requirement? 

If he had known and could express it correctly then he sure would have been a happy man.

Conscious Requirement

Users are capable of specifying some requirements but they cannot specify all the requirements. The type of requirements that a user is most likely to
specify is what we call a
conscious requirement. A conscious requirement is something the user is particularly aware of. For example, in the above story the blacksmith’s conscious requirement was that he wanted to be in a cool place. But he had more requirements, which were not conscious requirements.
These requirements can be called as unconscious requirements.

Unconscious Requirement

The type of requirement that a user is most unlikely to specify is what we call an unconscious requirement. The user cannot mention this type of requirement

because he does not realize that he has it. Various reasons exist for this situation.

The problem of unconscious requirements happens often when the user knows a lot about the subject matter and makes assumptions that everyone else has

the same knowledge. For example, while we were developing a  software for requirements management, the Project Manager gave a requirement that the tool

should be able to show the traceability between different documents of the project. By giving this requirement the project manager thought that the team would

 be giving her the ability to generate traceability  matrix for all of the documents in the project at a time. But the team came up with the feature and was able to

show a matrix, which showed traceability between only two documents at a time. This part of the requirement from the project manager was unconscious as

she assumed that the team also knows about the traceability matrix as much as her.

One of the reasons for unconscious requirement might also be that the user is so used to having this requirement that he no longer thinks of it as a
requirement. Another reason is it is sometimes very difficult to tell someone all the details about something you know a lot about because you feel
that perhaps you are patronizing them.

Undreamt Requirement

These requirements are rather different. If a stakeholder has a fixed idea of what he believes is possible then he is unlikely to mention requirements

    that he thinks cannot be carried out within his understanding of the constraints.

    Then there are many undreamt requirements that do not even occur to the users because they cannot imagine what it might be

   like to have the product and to experience new technology. Users will not invent many of these undreamt requirements. These

   have to be invented by the engineers themselves.

    Unless we encourage requirement engineers to imagine these undreamed of requirements, they are unlikely to surface until

    later in the product's lifecycle  when people understand more about the potential uses of new technologies. By then, even

though it might have been possible earlier, it is often too late to add these new competitive features to the product.

Role of requirement Engineers

The following quote from Dewys Lasdon, appropriately explains the role of the requirement engineers :

"Our job is to give the client, on time and on cost, not what he wants, but what he

never dreamed he wanted; and when he gets it, he recognizes it as something he

wanted all the time."

The real job of requirement engineers is to improve on what they see, and usually this improvement comes as a result of inventing something that
nobody is asking for. For example, did anyone ask for the Walkman before Sony introduced it? Probably not, and yet every music lover uses it
today. Did you ask for Internet mails? No, but nobody can live without it today. Hence the requirement engineers, and the like, need to do a little
inventing to elicit the undreamt and unconscious requirements and it is a great challenge for the requirement engineers.

Conclusion

User involvement in requirements engineering is given great importance. But requirement engineers need to keep in mind that users cannot always
specify all the requirements they need. They need to be innovative in finding out the unconscious and undreamt of requirements, which will most
likely be not specified by the users.

Pankaja P K
Manager - Software
She heads the SmartWorks and ReMa teams at Accord.She also manages DO178B verification projects.
Write to her at feedback at ReMa