Editorial Note: I originally wrote this post for the SmartBear blog. You can check out the original here, at their site. While you’re there, have a look around at posts and knowledge from other authors.
I remember working in a shop that dealt with medical devices some years back. I can’t recall whether it was the surrounding regulatory requirements or something about the culture at this place, but there was a rule in place that required peer review of everything.
Naturally, this meant that all code was reviewed, but it went beyond that and extended to any sort of artifact produced by the IT organization. And, since this was a waterfall shop, that meant review (and audit-trails of approval) of the output of the requirements phase and the design phase, which meant requirements and design documents, respectively. I can thus recall protracted meetings where we sat and soberly reviewed dusty documents that made proclamations about what “the system” shall and shan’t do. We also reviewed elaborate sequence, flow, hierarchy, and state design artifacts that were probably obsolete before we even reviewed them.
If I make this activity sound underwhelming in its value, that’s because I routinely felt underwhelmed by its value. It was a classic case of process over common sense, of ceremony over pragmatism. Everyone’s attention wandered, knowing that all bets would be off once the development started. Sign-offs were a formality — half-hearted and cursory.
But is it worth throwing the baby out with the bathwater? Should the fact that waterfall shops waste time on and around these documents stop you from producing them and subsequently reviewing them? Is it worth reviewing requirements and design documents?