All too often in IT projects, a new technical application will be partly or completely rejected by the target group. From experience, the most common reason for this is the lack of requirements engineering. The service provider does not understand or grasp what the customers want, and the customers are unable to express themselves in a manner that is intelligible to the service provider. And to make matters worse, what the customer wants is not necessarily what the customer needs. And the biggest difficulty of all is to identify what is truly required, instead of just implementing what was said or how it was understood.
As long as you don't know what your customer expects, you will almost certainly make the wrong choice, unless you flip a coin to define the customer expectations – in this case your chance to make the right decision is at 50 percent. It follows, therefore, that requirements are intrinsically linked to expectations and hence to objectives as well. All these things need to be clarified before starting the project.
If you do not clarify the requirements and expectations, you will encounter resistance time and again and even more frequently as the project progresses, accompanied by the following questions and statements:
- Why did you do it that way?
- Why can’t I see X at this point?
- Who told you to put that thing there/insert that color?
- Well, our experts would have done it this way …
These questions and statements will eventually derail any project, because – sooner or later – you will be unable to provide adequate answers seeing as you neglected to record and document the requirements from the beginning.