Requirements without expert knowledge

There is a discrepancy between theory and practice when dealing with requirements. In theory, there are techniques, tools and best practices that almost certainly lead to functioning, accepted solutions. In practice, there are often quality deficits in delivered systems and products that should have been discovered in the course of requirements management. Why is it so difficult to detect system errors? And why, despite all the standards and rules, can serious errors even occur in delivered products today?

Dealing with requirements in practice

In many organisations there are developers and architects who have been developing systems, products or services for many years. These employees are experts in their fields. They know exactly what they have to do and how. They are good at estimating what a new solution should offer and how extensive the development of this solution can be. They have acquired this knowledge over many years, it is their qualification, their professional experience. If you ask such people to describe a new system, you may receive a slight shake of the head, some general epics or features, and in very few cases a description of the system context or a requirements diagram. Writing down what is supposed to come out in the end makes little sense to these people. Everyone involved knows this, and so little attention is paid to the alibi description. Here the client and the project manager trust the skills of the employees. Although the procedure is more reminiscent of driving in the fog with eyes closed, there is hope that the driver knows the way well.

What happens if the development process requires a review of the requirements? Often a meeting is scheduled with the project manager, the architect, a tester and possibly a developer. Without a moderator, without a timebox, without an agenda or rules. After an hour, only a few requirements have been discussed and a common understanding of the challenges and the approach is still a long way off. It is clear to everyone involved that it cannot work this way, so the author of the requirements inherits the task of improving the quality of the described requirements. Thus, the same person is again sitting at a task he does not want to fulfill and which does not correspond to his qualification. How will the quality of the requirements – in terms of comprehensibility, completeness, consistency, traceability, etc. – look like?

The other way to requirements

In my experience, the causes of product defects are rarely found in the requirements, although many defects are caused by misinterpretation of the requirements. This happens because the author leaves room for interpretation and considers assumptions to be generally valid. Both are rarely discovered in the review. In addition, there is another contradiction: system developers are fervent about creating technical solutions to technical problems. That is what drives them, that is their expertise. So how is such a specialist supposed to specify an idea in advance that in reality can only emerge in the course of development?

The solution to this contradiction lies in the exchange of “how” with “what”. Or in other words: Requirements must be free of solutions – and this is precisely not the strength of system developers and system architects. They are simply the wrong people to contact when formulating requirements, because they always think in terms of solutions. But if they are not the right people to contact, who is best suited to formulate requirements? The answer is surprisingly simple: If requirements are to be free of solutions, the author does not have to be an expert in system development. He only has to question the customer when entering the requirements, until the requirements are formally and correctly written down. This requires a certain talent for language, a proximity to formalisms and a good deal of perseverance in order to persuade the client to make precise specifications.

The turnaround in requirements management

In many organisations, describing requirements is a task for highly qualified specialists. In my opinion, this will change in the future. It will be a task for highly structured people with special talents who need to have almost no technical background. For example, people with special predispositions, such as Asperger’s syndrome, have abilities in which they are clearly superior to all other people. These abilities can be used to grasp requirements free from solutions.

Of course, the number of documented requirements increases significantly on the way to pure, formally correct requirements. In practice, however, this is irrelevant; the tests show that this way of handling requirements is much more efficient. Even if in a comparable situation the number of requirements increases by a factor of 6, the creation is faster by a factor of 3. The review is then completed in record time, because requirements are read in a completely different way, and clear yes/no decisions can be made more quickly – which is the real purpose of reviews. And because the “what” is clearly defined by this process, system architects and system developers can once again devote their full passion to the “how” – the passion with which they find technical solutions to technical problems.

What does t2informatik actually do? One click and you'll know.