I am encouraged by the the growing conversation about good requirements. For example, a recent issue of Manufacturing Business Technology had a good discussion about how quality requirements are necessary to save time and money in Best-in-class report proves out commonsense guide: minimize change (registration required).

Quoting Doug Putnam,

Change in [software] requirements is the thing that causes so many projects to go awry. It usually occurs in the last third of the project as pressure mounts to get it out the door. Teams compromise the original design and try to retrofit the changes back in, causing a lot of turbulence.

The article also states best-in-class projects are almost 3.5 times faster to market, and nearly 7.5 times cheaper. And if this isn’t a good reason for managing a project correctly, I’m not sure what is.

At the same time good requirements are becoming known as commonsense, there are a number of online conversations about the best way to capture functional requirements. I disagree with much of the discussion and will save that for a different post, but it is great to see the debate raging on.

For a couple of samples of the online debate about how to capture requirements, start by reading the following posts and comments: The interface as spec (Signal vs Noise by 37signals) and CRUDdy use cases and Shakespeare (Tyner Blain).