Improving Requirements (Strengthening Waterfall)

One of the weaker phases in waterfall product development is the area of requirements.  Unclear or incorrect requirements are recognized as a major cause of grief on projects, if not outright disaster.

What is your feeling about the relationship between the requirements document and the ultimate product delivered?
How readily does the requirements document map to the required functionality?
Does it include a description or list of functionality that is out of scope? (“Thou shalt not…”)

In general, part of the problem is that there’s no real QA process on the requirements document, typically, only a user sign-off.  That’s an approval, not a QA process.  If the document is much over 10 pages, this is about as useful as handing someone a globe to use for direction to someone’s house for a holiday dinner.  You’re lucky if you even wind up in the right town, let alone the right neighborhood.

Typical waterfall environments have a QA function, usually for testing the finished product  Too often they only get involved late in development, often after all coding is allegedly done.  Why restrict their role so much?

Get them involved sooner, and involved with the analysts creating that requirements document. Involved, meaning interacting and talking directly to each other.  QA is designing the tests and should be able to identify unclear areas of the requirements, perhaps even missing parts. To flesh it out further, the QA group designs the tests based upon the requirements, and the business (not the BA who did the requirements) then reviews the test structures for completeness and accuracy, closing the feedback loop on the requirements document.  That process is independent of coding; it can start before any coding.

Another wobbly area is the clarity of the requirements for the developers.  Of course, clarity is only important when the document is actually read.

Another way to have some QA process for requirements is to have something similar to a peer review for coding, but in this case, instead of code, it is the requirements that are reviewed.

Come up with your variation of a QA process for requirements, one appropriate to the culture of your organization and resources available.