Just-inTime Requirement Specification

Slightly edited for formatting, my original post follows...

[quote=achen]...savings from doing requirements right? [/quote]

I think you have to talk about "savings from getting requirements right sooner".

MTalbot is right that the costs of getting things wrong can be incalculable, but only if wrong requirements are actually implemented. It is quite straightforward to talk about the (estimated) cost of fixing a requirement during design, say, versus during acceptance testing. Only rarely, if at all, is it cheaper to fix requirements later rather than sooner.

Averaged statistics are not particularly helpful, however. Some defective requirements can be fixed almost as cheaply at the end of development. And I'm not just referring to "cosmetic" defects. Take, for example, legal caveats or wordings prescribed by statute. If we know early on that these are required but not exactly what is required, we can generally proceed with development at little additional risk while the precise text is hammered out by an army of lawyers, copywriters, focus groups and officials. Often all we really need to do is plan accordingly.

So for every requirement we can repeatedly apply what I call the "so what?" test:

[QUOTE]
This requirement may be wrong, so what?

The answer is often that it probably doesn't matter very much at this stage.

So when will it begin to matter more?
[/QUOTE]

Finalizing a requirement before it begins to matter very much saves you next to nothing. Delaying development while you try to finalize such requirements, on the other hand, can cost a very great deal, both in terms of "burned" resources and delayed, or increased risk of late, implementation.

As a general rule, we do not want to use up valuable elapsed time now unless there is a fair prospect that it will save us more elapsed time in the future. Too often, this debate refers only to cost in terms of (mythical) manhours, overlooking the simplest of critical path analyses. Even if, as is usually the case, getting the requirement right now does cost several times less in terms of effort, this "saving" may be more than outweighed by the costs of an extended critical path.

<<<--post ends

This received some positive feedback. "I think this is actually a really great point. In an SRS, how have you typically handled or called our requirements that you know are incomplete/wrong at the time of writing?"

Now I guess I'll have to come up with an answer!