What About Requirements Documents?

My last post was about why Use Cases should still be considered alive and well as an analysis technique in Agile projects. That begs the question: if people can dismiss Use Cases as old fashioned and a waste of time, is there any place left for traditional Requirements documents?

I am not a fan of Big Requirements Up-Front. Fat requirements documents based on the premise that if you don’t ask, you don’t get, tend to accumulate very long feature lists. Crafted early in a project, they risk becoming disconnected from what the front line users will actually use. We try to mitigate this risk by prioritizing the features.  But anyone who has been through the exercise of separating a few hundred features into categories by priority can quickly agree on three things: it’s necessary, it’s difficult and it requires more ruthlessness than most of us can muster.

The MoSCoW technique is a popular way to try and simplify the process by distributing the list into four categories, something like this:

• Must Have (some team members really want it)
• Should Have (someone else really wants it)
• Could Have (really useful but nobody believes they will actually get it)
• Won’t Have (nobody cares)

The process depends on having a reasonably complete feature set up-front.  The problem is that taking a group through this kind of exercise  with a big feature list is a long and tiring exercise for everyone involved. If that isn’t enough, it often doesn’t work very well. Without good ground rules about what the categories mean (hopefully more objective than the ones listed here) there is a very real chance of getting it wrong, leading to much time and effort wasted, building things people never use and leaving out things they actually need.

The situation doesn’t change much when the aim is purchase of a commercial off-the-shelf (COTS) package. There is a strong temptation to write extensive feature lists in order to set up an “objective” comparison among vendor offerings. Purchasing departments like this approach because the evaluation looks like such a systematic way to get best value in a big ticket purchase. In fact, vendors who compete in the same market space often have very similar feature offerings, something that has been demonstrated to me almost every time a set of RFP responses came back. It’s easy for the comparison to end in a tie when everyone offers the same features. Final product selection is more likely to be decided on differences in execution of a handful of use cases that a few key stakeholders really care about.

So, what’s the alternative? If, like me, you tend to favour incremental delivery there’s a lingering problem about putting boundaries around what to deliver. There is, after all, more to delivery than construction, and especially in large projects, there’s a bigger story to be told than can be represented on a set of index cards. Part of that story is a nod to key stakeholders that the things that matter most to them are being addressed.

Here is where we encounter our old friend, the Requirements Document. Dressed a little differently perhaps, trimmed down and definitely playing a new role we have a “System Vision” document. Produced at the end of a period of exploration it captures the what and the why of a project at a high level. The System Vision articulates outcomes that matter to key stakeholders: what the solution does for them but not necessarily how it does it. It goes into just enough detail to help people see a picture of what they are about to build, and it might touch on some non-functional aspects that constrain what ultimately what will be viewed as a “good” result.

In Disciplined Agile Delivery, Scott Ambler describes this as a key gate point. At the end of the Inception stage the project is poised to move into construction, and its culture is about to shift to a preoccupation with deadlines, budgets and issue management. Requirements discovery will continue, new features will be added, others will drop off and priorities will shift. The Vision document can aid the ongoing process of managing change by providing a snapshot what people understood before the construction noise began. Coupled with a good requirements management process it provides a reference point for evaluating the changes that inevitably will come.