How much $ can be saved by doing requirements right?

[AlanAJ]

Originally Posted by achen

...savings from doing requirements right?

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:

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?

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.

[MTalbot]

Originally Posted by AlanAJ

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.

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?

[gescober]

Originally Posted by MTalbot

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?

Well, are these really "wrong" requirements? If your requirement was, "The system shall provide a field for the 'End User Licensing Agreement' to which the user must agree before proceeding." And, if you specified that the EULA is a field that was alphanumeric and 1024 characters long; you've pretty much specified the requirement correctly and completely. The actual content is irrelevant - you just need a place sufficient to hold it. The lawyers can add their scribblings later.

So, I don't know that you ever specify "wrong" requirements. You can identify the object, it's attributes, and how it's used within the system. You can have "unstable" requirements, in which case, I track a Stability attribute on the requirement itself. Or, you can have incomplete requirements, in which case, I probably track a Completeness attribute or Status attribute on the requirement.

For example, I could have my requirements for the EULA, but not know how big the thing is going to be - which makes it an incomplete requirement. I could not know whether there's going to be a EULA - perhaps, it's going to be free software or maybe there's going to be multiple EULA's, but the product manager hasn't made up his mind yet - in which case, the requirement is unstable.

Early on in a project, I consider incomplete or unstable requirements simply part of the slop that is requirements gathering. When you get closer to baselining and people start needing solid requirements for planning or estimation, then I start reporting out incomplete/unstable (bad?) requirements out to the project manager as risks to be managed.

If you can get an architect to identify requirements with significant architectural risk, then you can use that as a risk multiplier for the requirement. e.g. An architectural significant requirement that has high instability is a pretty big risk.

To circle back, I guess what you need to do is to characterize what's bad about a requirement - unstable, incomplete, etc. - and put that in context with what risk the requirement represents to the project. Not knowing how big a field is, is not a big risk. Missing the fact that you need a licensing agreement and that the user has to agree to it may be a bigger deal. Any requirement change that causes a database redesign? Heh - better figure that one out right away.

[AlanAJ]

Originally Posted by MTalbot

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?

Well...

...as a rule, all my requirements start out this way. And in reality, it's pretty safe to assume that they end that way too! (That's just the Precautionary Principle.)

I am not by nature a pessimist, but every requirement has a "confidence level" of between 0% and 99%. All requirements begin at 0%. I only increase the percentage after I've written the requirement. Then again after it's been checked. And so on throughout its lifetime. Proactive planning means I also agree one or more target levels for each requirement. The difference is accounted for in two ways: in part it's the work I have left to do, in part it's the risks, assumptions, issues and dependencies that are logged elsewhere and referred out to. In the example given, confidence is reduced by a dependency on an incomplete task: changes in the status of this task will affect the confidence level.

[jallen]

See attached. It is fairly straight forward and can serve as a model you could perhaps tailor to your specific situation.

[MGoyal]

hi jallen, i don't think the attachment made it. do you mind reposting?