A few years ago someone told me the following story that occurred, as a matter of course, at a client’s company:
A new sports convertible caused repeating customer complaints on account of leaks in the rear window. In spite of the fact that it had been designed for speeds up to 50 mph some new cars had dented seals. Was there really someone driving faster than 50 mph in reverse? The engineers were scratching their heads. They had no clue as to what caused the dents. They performed additional tests, trying to verify whether the requirement had been satisfied. They could not find the mistake.
Eventually it transpired that sometimes the cars were transported on wagon trains and that the cars were facing backwards. Since these freight trains sometimes are going faster than 50 mph the riddle was solved.
I cannot prove or guarantee validity of this little story. Maybe it is just another urban myth; still, it shows how important it is to think about how faulty requirements arise.
Of course the requirements should not have been included in the specification sheet of the vehicle, let alone implemented. But is the requirement faulty as a rule? I do not think so. What is important is to consider the entire context of the situation, in this case the scenario in which the convertible is used.
The defect of the vehicle came into existence because an important aspect of the context was not taken into account: how the vehicle is transported to the retailer. And there may be even more transport scenarios for this vehicle, e.g. on a motorail train. And maybe other factors have an impact on the rear window such as the increasing frequency of occurrence of windstorms. I am not aware of car manufacturers having included these factors into their specification sheets.
Different contexts yield different requirements for the same product feature. It is the responsibility of product management to prioritize and aggregate these requirements. Compromises have to be made, a typical example are requirements of controlling that in many cases are unpopular among engineers. In general, car manufacturers are very good at managing different contexts of requirements.
For example, it is important to construct cars in such a way that they can be repaired easily. Some manufacturers put much effort into this, some do not.
In the little story one little scenario has not been considered. In other words, the system context was not chosen wide enough. The result was the implementation of a requirement that was correct in one context but incorrect in a number of other contexts.
It is my estimation that this is the most common reason for faulty requirements: failing to include all relevant aspects.
The context decides about the nature of a requirement
Cases in which the context of a requirement is misinterpreted are even more difficult, which happens quite often when dealing with abstract concepts such as business processes and IT solutions. These things are characterized by invisible structures that you cannot feel or touch. They are intangible and hard to comprehend, which causes people to form their own individual picture of it in their heads. Everything that is said and written down – requirements included – is related to this particular context. Even if the requirements themselves are precisely defined everyone will create his or her own concept of it on the basis of the individual background of knowledge.
How different this background can be reveals itself though the interface between IT and other departments. Both of these groups do not have homogenous world view. How does a certain business process work? Where does it start? Where does it end? This problem becomes particularly clear when different disciplines are working together, such as sales and production, or data protection and work council.
Misunderstandings causing controversy over requirements is a drag but not necessarily harmful. Cases in which a conflict is not recognized as such are far more dangerous. Everyone interprets a requirement on a different background and at his or her convenience.
Very often, these kinds of conflicts are discovered late in the development process. Solution are expensive and the cause for much trouble and stress resulting in rotten compromises that make nobody happy. Since implementation is well on its way changes cannot be applied with a justifiable effort.
Reducing the probability for misunderstandings
There is no ideal path to avoiding these kinds of misunderstandings, at least none that is applicable in real life. I do not think that these mistakes can be avoided, but the probability can be reduced.
When eliciting requirements it is paramount to keep an eye on the context and on the background on which persons are creating requirements. A different understanding of the context is not a bad thing in itself, on the contrary. Differing knowledge and a differing understanding of things may complement each other in very useful ways. But if the context knowledge is conflicting or if some requirements cannot be comprehended by some it is the requirements manager’s job to create a common understanding.
In my own experience, these kinds of misunderstandings are a common “feature” of abstract and complex projects. To avoid them I rely on graphical representations. Elements and interrelations of all project contributors are made visible and communicated. You can literally point your finger at something that was only a loose concept before. Mind you, it is not easy to create usable visualizations. It has to be easy to understand while at the same time being precise in what it needs to portray. It must not be trivial.
All of this requires the ability for abstract thinking and a lot of practice. But there is one characteristic that every requirements analyst must have: an honest interest in people and the urge to really understand the background and context of the individual person.
Read more at http://www.bungert.berlin/blog/.