Who cares about requirements?

Tom Breur

12 October 2014

The customer is always right! Isn’t he?

There seems to be a perennial dance between business and IT around “requirements”: business people wonder why IT finds their needs so hard to understand, and IT folks complain that business people don’t know what they want.

Part of the problem is that “requirements” and “needs” are often mistaken for solutions. “It should look like XYZ” is not a requirement. It’s an implementation specification. One of the undesirable side effects this habit carries is that it limits our thinking. It leads us to pre-existing notions of what should ‘work.’

Specification by Example suggests we “derive scope from goals” which is fundamentally different from “building what was requested.” The former is based on collaboration. The latter fails to take responsibility for our work. Development teams sometimes need to “push back” when their customers say they “want something like XYZ” by asking clarifying questions like “Why do you need XYZ?”, “How will that benefit our bottom-line?” Etc.

Adopting this habit has (at least) two advantages. Firstly, it helps you get behind the immediate request. It helps to delve deeper into ‘true’ needs. Secondly, you regain responsibility for the solution. Scope is not something that is ‘forced’ upon us. We choose to accept a goal. We’re not victims of our jobs.

Instead of merely implementing requirements, it behooves professional developers to try and achieve a greater understanding of the (real) problem. That way you help to actually solve those problems, and not “just” meet requirements. How’s that for adding value?