Red Pen, Black Pen

Or: How to succeed at a requirements review meeting.

If you work in software development (and I include management and testing), then it's safe to say that you have a requirements problem. In fact, if my experience holds at all, most of your problems are requirements problems, whether you realize it or not. Any and every trick that helps with requirements is helpful, but the simpler the better. The simplest one I know of involves pen and paper.

If your responsibilities include digesting requirements documents, then I have a piece of advice that's saved me countless hours and more than a couple follow-up meetings: First, get yourself a red pen. Second, any time there's a reading of the spec documents (group, or individual) bring your red pen AND another pen (blue, black, it doesn't matter). Third, color code your comments.

After the reading of the specifications or requirements, you're going to discuss the outcome with others, and adjust other documents (like the schedule, the task list, the test plan) accordingly. As time progresses, your recall of the review will become progressively fuzzy in your brain. Even walking out of a long review meeting, you've probably forgotten at least one critical detail, and even if you've written it down, it's easy in scanning a document to miss black comments on black print. If all of the critical notes are made in a high-contrast color, then the odds are working in your favor.

The process is pretty straightforward. All of the 'bad news' you find in the spec is either written or circled in red. Bad news usually means one thing: schedule slip. This can include things like:

• Clarifications
• Addenda
• Surprises ("hey, why didn't I notice that before?")
• Open questions (surprises we haven't met yet)
• Your own commentary on how a requirement should be executed

Good news, spelling corrections, and simple clarifications can be made in the neutral color.

If you're reading the spec professionally, then you're probably also responsible, in some fashion at least, for time lines and estimates based upon that specification. Every change or discovery in the document that wasn't covered by previous readings represents a three-fold risk to the success of the project. One, surprises represent more work than you previously signed up for. Two, early surprise is much better than late surprise (pain avoidance kills). Three, a high number or degree of surprises indicate a systemic problem with requirements gathering, organization, or hand-off. Identifying that problem should be a high priority for the team, and fixing it should be a high priority for management.