This book was my personal choice, kindly agreed to by the other members of the group. Everyone seems to enjoy the book thus far, even when I presented chapters four and five this week!

If you’re in the Phoenix area, come join us! Drop by Gangplank at 8:00pm on any Wednesday.

I don’t expect you to agree with all these facts; some of them might even upset you. Great! Then we can begin a dialog about which facts really are facts and which are merely figments of my vivid loyal opposition imagination!

In that spirit, I have selected one each of my favorite requirement and estimation facts.

RD2. When a project moves from requirements to design, the solution process’s complexity causes an explosion of “derived requirements.” The list of requirements for the design phase is often 50 times longer than the list of original requirements.

Indeed, suddenly a large body of previously-unknown work is materialized, complexity increases again, and the schedule doesn’t adjust (see ES2).  The knee-jerk reaction, of course, is to spend hour-after-hour and day-after-day coming up with an exhaustive list of requirements.  The process can be infinitely long (see  analysis paralysis) and may only reach its end by artificial means.  This problem alone may be one of the strongest arguments against waterfall-style development.

ES2. Most software estimates are performed at the beginning of the life cycle. This makes sense until we realize that this occurs before the requirements phase and thus before the problem is understood. Estimation therefore usually occurs at the wrong time.

Another good argument against waterfall.  The risk inherent in this nearly inverse ordering is significantly reduced when software is produced in a more agile fashion.  That is to say, analyzing requirements and producing estimates iteratively allows the risk to be mitigated incrementally.