Requirements Document Proliferation

Too many companies don’t document their requirements.

Worse still, too many companies over-document their requirements.

Roger Cauvin and Cote’ have started a great conversation about the proliferation of requirements documents. To follow the thread, start with Roger’s post, make sure you read the comments there as well. Then check out the post by Cote’.

The main point that they are making is that having 4 levels of requirements document is ridiculous. The four levels (shown in more detail in their posts) are:

1. MRD – Market requirements document – used by marketing people. Describes the needs of the market, like “Driving downtown takes too long. There’s a need for a better solution”
2. PRD – Product requirements document – used by product managers. Describes what a product must be capable of doing, in order to address the needs of the market, such as “Transporter must move people from rural areas to downtown in less than half the time of driving.” From the wikipedia definition, we see that the PRD has much of the same content as an FRS.
3. FRS – Functional requirements specification – used by program managers*. Describes the same thing that a PRD does. Personally, I’ve never seen both used on the same project. Here’s a good definition of an FRS at mojofat.
4. SRS – Software requirements specification – used by software developers. Describes the same thing that an FRS does. Here’s a good explanation of what’s in one from MicroTools, Inc.

Many people get so frustrated with all of these different ways to document requirements that they either look for a novel approach (or another here), or declare that requirements are counter-productive. The problem gets exacerbated when a bunch of former technologists attend a training class and start preaching the importance of (pick one of the docs above) without an understanding of the big picture. The current software-development outsourcing trend in the US has forced a lot of people to scramble to find new homes in the org chart. Cote’ is spot-on with his application of Conway’s law to this problem.

Cote’ suggests that we need a single person/team that “does it all”, flattening the hierarchy. Several people commented on a post here about CRUD requirements, and the discussion touches on a similar issue- drawing the line between requirements and design. Some of those folks came to the same conclusion. And I agree, when we can find supermen who can write code that solves valuable problems (which they identify), we can have great software. When we have to collaborate as a team of specialists, we need to include requirements documentation to get the best return on our investments.

I do disagree with Cote’ that some of these layers of documents exist to enable people who aren’t “technical enough” to participate. Different people play different roles, and care about different information. Communicating with these people, in their language, is critical.

What the heck should we do?

1. Understanding the needs / problems in the market is critical to succeeding. The build it and they will come illusion of the late 90’s has been broken. Only the companies and products that provided real value survived that shakeup. Should we document those market needs? Yes. Is an MRD the right document? Probably. Roger knows more about this than I do, and he and other folks I respect believe in the MRD. If you don’t, at least codify your understanding of the market somehow – maybe this way.
2. Building a vision for software that addresses those needs is critical to success. I left a previous employer with a philosophy tatoo that is stuck in my head like a bad song from the 80’s (Oh Mickey, you’re so fine…). That phrase is filler versus killer – and it was applied to every proposed feature for new software. Are those filler features that just take up space and time, or are they killer features that solve real problems and provide real value? Creating a software-vision designed to address market needs is an ideation process. And it should be documented. PRD, FRS, SRS – a rose by any other name. When forced to choose, I would call it a PRD, because in practice it is harder to avoid writing about implementation details than it is to avoid overlapping with market needs.
3. Designing software that achieves that vision is critical to success. We can’t leave out design. Agile approaches work well because (among other things) they do even more design – it just isn’t all “up front”. Regardless of what process you choose, build and document a design based upon the requirements.

Executive summary: Document market needs in an MRD. Document requirements for your software in a PRD. Document your designs.