Big Freaking Requirements Documents !

The typical requirements document is a long, sprawling piece of literature. Within it, one might find a title page, table of contents, change history, complex headers and footers, legalese, confidentiality notices, and, if you're lucky, maybe even requirements. It's length is probably due to the fact that it tries to be everything to everybody. But the problem is that the document isn't read entirely by any single person, except perhaps by the analyst who wrote it in the first place.

And parts of these documents are only relevant to certain people. High-level overview stuff is great for managers, but developers could care less about the project's "vision"; and testers only require certain parts themselves. (Though one might argue that they should read this stuff, in order to provide context for the job at hand).

In theory, having all of the requirements in one document makes everything easier to find, as well, and to see how all the pieces fit together. In practice, however, the document becomes difficult to manage as it grows over time, and these linkages fall apart.

 

The question that I always seem to ask myself when take a peek at a customer's requirements document template for the first time is, "why must us humans unnecessarily complicate our lives like this?"

One of the core reasons, I believe, is that managers still want to put their monogrammed gold pen's ink on something tangible, sign on the dotted line, and have everything recorded so that somebody (namely the BAs that report to them) can be held accountable in case something goes wrong... which will happen, because nobody understood, or questioned the contents of the document in the first place.

Luckily, from where I sit, I believe that the typical printed requirements document is nearing its death. And the good news is that this eventuality is closer than most people think. Yes, for some companies this dream will be further away than for others, but Blueprint has actually witnessed this happening at some of the more progressive companies that we've worked with (thus restoring my faith in humanity).

Tools for the Business Analyst, like ours, help to take requirements and break them down into managable deliverables, suitable for consumption by various stakeholders with different needs, while *still* maintaining cohesiveness.