Gathering Requirements

What is today’s ‘best practice’ for requirements definition?

That is a question I received yesterday. I would welcome your thoughts and comments.

There are three issues that I would highlight as critical in today’s requirement gathering process. One is volatility, one is technology, and the third is inclusiveness.

The point about volatility is that business needs and conditions are constantly changing. Therefore it is in many cases illusory that requirements will ever be complete or reach ‘steady state’. Therefore the gathering and validation process never ends and contracts must acknowledge this reality. By enabling a controlled and disciplined process to manage change, we can avoid the confusion and contention that comes with rigidity.

The point about technology is that we must recognise not only that it has dramatically affected the nature of requirements (and expectations of users), but it can also be used to streamline and bring quality to our requirement gathering and validation process. Web-based systems can simplify outreach; they enable polling and ‘crowd sourcing’ to establish both needs and priorities. And the right system can offer instant feedback on whether our initial requirements wer in fact correct and met needs.

The final point – inclusiveness – builds on the previous two. Because of rapid change and the availability of web-based tools, our process can be (indeed, must be) far more inclusive of the wide range of stakeholders. Gone are the days when Procurement can act as a barrier between user and provider. Instead, they must facilitate and manage interactions between them. The alternative is for Procurement to take complete accountability for getting requirements right – and that would mean measures that punish them each time they are wrong.

These are brief ideas which I hope will solicit your additional thoughts on how we improve the quality and accuracy of requirements definition.