Requirements are tools not weapons

Consider these requirements;

· The system shall properly calculate the taxes due at the time of payment.

· The system shall properly display the location and speed of inbound projectiles.

· All users will only be able to change data appropriate to their role.

They are a clear example of poor communication and are likely to lead to more poorly managed customer expectations. I doubt any requirements analyst worth their salt would consider any of these adequate. They are at best ambiguous and there is little doubt that ambiguous requirements are frequent contributors to troubled projects.

That being the case, just what is it that would make these and other ambiguous requirements better? What would make then more achievable? More importantly, what would allow us to deliver well and in such a way as to meet the needs of our customers? While I would love to propose that all requirements include their definition of a successful outcomes and the metric that defines success I am more concerned about the current trend toward wielding requirements as a weapon instead of using them as a tool to further success.

All requirements, functional, technical, user, documentation, security, performance, etc... can be measured. It's just hard. It's the kind of hard that seems to get sweep aside because it takes too much time at a time when everyone wants to just get to work . It requires non-development skills like interviewing, analysis, and negotiation. It forces teams with short timelines, little budget, and high expectations of achievement to focus on the business of the users, something they have little control over, and not themselves.

On the one extreme,failing to properly define the requirements has been pushed aside by the new generation of agile practitioners as too much upfront work or a fool’s errand. On the other extreme is the formal community who may defer development until all the "knowns are known" but have yet to engineer a litmus test for requirements quality. In the middle is a form of compromise. Requirements are not the goal. I have never seen a successful project that simply met all of its requirements. No, requirements don't define a project, they are just are one of many ways the team ... all roles including the customer ... creates tasks, discusses priorities and trade-offs, and works through the unavoidable complexity of discovery throughout the software development life cycle.

If instead of placing requirements between the team and the customer each demanding the other becomes more and more specific. You can use the activity of improving the quality of the requirements as part of the necessary and on-going communications within the team. Requirements like models are built to improve understanding. They are communication tools and much like other forms of communication when the quality if high everyone wins.

Comments

• Anonymous
  December 01, 2009
  We agree, Requirements are the Achilles heel of software development - with emphasis on narrative requirements. They cannot be tested or shown to be consistent, complete, or correct. Any requirement described in colloquial English is itself a significant analysis problem, expanding the problem domain, not solving it (as one of our customers said describing a 267 page narrative - 'it is an analysis problem not a solution!').