Outdated belief #1: Requirements are instrumental

Building software-intensive systems from scratch is far from trivial. One of the main reasons is that it’s hard to capture concisely and precisely what the system should look like in terms of functionality. Even if all stakeholders individually have a clear understanding of what they want, it doesn’t mean that the expectations are aligned. In many cases, there are conflicting needs and wishes that need to be managed.

Traditionally, this is addressed by embarking on a requirements elicitation process where the needs and wishes from all stakeholders are captured, conflicts are identified and resolved, resulting in a clear and crisp requirements specification that precisely states what the system should provide in terms of functional and non-functional behavior.

The challenge with requirements engineering is that it has at least three inherent problems. First, the assumption that capturing requirements and then building the system will result in everyone being happy is fundamentally false as requirements change all the time. The rule of thumb in software engineering is that requirements change at a rate of 1 percent per month. For a complex system with 10,000 requirements (not atypical for the industries I work in), that means 100 new or changed requirements per month. Assuming a development project lasting 36 months (a typical car project), that means 3,600 new and changed requirements – an overhaul of more than a third of the requirements.