Requirements engineering and requirements management have inspired many books, speeches, training seminars and conferences. The consensus in the industry is that meticulously following particular rules (almost) always guarantees success. There may sometimes be debate about the details but most people are in agreement. In my job as a consultant, on the other hand, I often encounter the following results:
• 80% of quality problems in requirements right up to and including a product’s release.
• Products get released despite critical “deficiencies” in the implementation chain.
What accounts for this discrepancy between theory and practice? Why do most engineers often despair when it comes to the issue of “requirements”? And why is the end of a project often stressful?
One of my favorite tasks (I like it so much I made it my career) is ferreting out problems in a system. Many would find this to be quite tedious, but I enjoy tracking down sources and purify them, the process always makes things simpler. Process oriented thinking is how one can avoid falling back into old patterns of behavior. But why is it so hard to find a system error? And how can it be that serious errors continue to make their way into the final product?
Practically dealing with requirements
Some engineers have spent the past few years exclusively developing systems. Those engineers know exactly what to do and have a good sense for what a new system should offer and what it will take to create it. That is the expertise, know-how and experience they bring to the table. And that is just as it should be. It doesn’t make much sense to write down what the final result will be. The best would be for an engineer to describe a few alibi requirements so that the workflow can be superficially maintained. All the participants know that’s true and consequently no-one takes a very close look at these requirements. The entire project is a lot like a driving into fog at full speed because everyone already knows the way anyway. Or at least that’s whay they think. Their motto is: “We’ve always done it this way and we always will.” Instead of going through the fog one could also opt for a more scenic route along the system landscape. Road signs (process instructions) warning signs (reviews) hem in various phases (agile development) and one or two gas stations (mile stones / pit stops) can be visited along the way. The journey is one of the the goals, another is avoiding erroneous developments.
Now the development process dictates that a review of the requirements needs to take place. So the project manager will call for the author of the requirements, the system architect and a tester to meet. After an hour they will tend to find that they have only looked at the first 10 requirements and only four requireemnts enjoy any measure of consensus. Everyone can see that things aren’t working and that the deadline will be missed. Then the author will be told to retroactively improve the quality of the requirements, while simultaneously continuing to develop his part of the system.
Which would bring us back to the beginning. Again we find ourselves in a situation in which someone is doing a job that doesn’t match their qualifications. The result can only be bad.
A system engineer’s passion
The roots of errors are often sought in the requirements. However over the years, and during many projects, I have found that errors can be traced back to poor interpretations of requirements, which can only happen when the author has unintended assumptions. That is to say: assumptions that no-one noticed until now. But what is the key to a possible solution?
A system engineer is passionate about creating technical solutions to technical problems. That is where her creativity lies. And this system engineer needs to define an idea from the get go, in other words deliver a description that can be validated but which in reality only arises in the process. She could actually develop the system herself, which would be a faster option.
Trying to develop anything without the use of requirements is not an option in most companies anymore. There is no way of getting around requirements. In general this gives rise to vague and flowery texts. Writing formally pure requirements is tedious and often boring. I, for one, have never met a system engineer who enjoys writing thousands of pure requirements.
The better path towards requirements
The confusion comes in mistaking the “how” for the “what”. In short: Requirements need to be unburdened by solutions – which is not the system engineer’s task, in fact: System engineers not the people who should be writing requirements!
So who are the right people then? The answer is actually surprisingly simple. Because requirements need to be free of solutions, the author need not be a specialist in the area. The requirements author’s only task is to question the client’s requirements in a structured way long enough that these can be formally written down. This requires a certain level of linguistic flair as well as a love for formalities and a measure of stubbornness (if the client’s head is too far in the clouds). It’s also helpful to have a forensic sense for the areas in which the client likes to be “flowery” and to avoid a single assessment.
Basically the participants need to be aware that in a ordered process there is an assessment that is not yet final. Only then, if the first assessment is proved wrong can a new assessment replace the old one. Formal, structured requirements are the only functioning way of carrying out process oriented development. And here too will the “stubbornness” be a required skill because otherwise it would be so tempting for engineers to try to take a short cut.
The paradigm shift
Describing requirements is currently seen as the responsibility of highly qualified engineers. In my opinion this task will be carried out in future by highly structured people with special talents who have almost no technical background. For example people with Asperger Syndrome, people who stand head and shoulders above their peers when it comes to certain skills. These skills can be used to create “pure” requirements unburdened by solutions.
Seeking “pure” requirements tends to increase the number of requirements but that shouldn’t matter. Many tests in the field show that this way of dealing with requirements is much more efficient. Even if this process produces six times as many requrieemnts, with this method you could deal with them three times faster. The review can take place in record time because these kinds of requirements are read in a completely different way. Which leads to a much more definitive yes/no decision – and that is why we even have reviews. Because this process makes the “what” clearer, the engineers can passionately focus more on the “how” – the passion here refers to the passion for finding technical solutions to technical problems.