Requirements Set in Stone and Software Made of Concrete

This post was previously on the Pathfinder Software site. Pathfinder Software changed its name to Orthogonal in 2016. Read more.

Twas the night before Christmas, and 500 pages of detailed requirements had been produced. No line of code had been written, not even by a mouse.

It sounds great in theory: You produce requirements up front, getting them so detailed that they cannot be misunderstood, you vet them with a full committee of stakeholders who will be impacted (except your customers.) Then you give it to the developers. The result: you can get a really precise cost and timeline, you’ll save on expensive development time, and your CFO will sleep soundly at night.

It’s a nice fantasy, but it’s wrong. It’s a fundamental misinterpretation of how software development works. In fact, it’s a guaranteed way of increasing your costs and producing bad software.

Here’s why:
If you’re developing software, you’re coming up with a new solution to a problem, or solving a new problem altogether. Otherwise, why are you building software, rather than buying it?

Traditional requirements definition processes are a spectacularly bad way of understanding stakeholder needs, and coming up with, conveying and vetting a solution for these types of problems. You will miss certain requirements, you will over specify others, and some of them will never get used. Your stakeholders will only be able to provide feedback of limited value until the working software is actually in their hands. At that point, you will finally start getting valuable feedback that you can push through as change orders. When you’re developing new software, you can’t know everything up front. Software development projects are characterized by progressive learning. The further we progress in the design, specification and development of a software product, the more we understand the user’s needs, the technical implementation, the availability of new technologies, the competitive market, the responsiveness of third party vendors and a host of other factors.

When you’re developing new software, you can’t know everything up front. Software development projects are characterized by progressive learning. The further we progress in the design, specification and development of a software product, the more we understand the user’s needs, the technical implementation, the availability of new technologies, the competitive market, the responsiveness of third party vendors and a host of other factors.

In an agile process, you do just enough design up front to get a high-level iteration plan and start the first development iteration. The developers interact with the designers, so they can advise on what kind of designs are difficult to implement and which are easier. This saves time and money, and can improve the user experience. Getting working software in front of stakeholders and end users early and often is a much more effective way of vetting requirements and eliciting feedback.