TRAID: Tasks, Risks, Assumptions, Issues, Dependencies

In the end, I went for the "Less is More" approach. I kept trying to add more, but that just led to a whole heap of other things that I would also need to say.

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!

Seilevel Forum

Just-in-Time Requirement Specification

http://requirements.seilevel.com/messageboard/showthread.php?p=2216#post2216

Tom Gilb's Forum

I've been contributing to Tom Gilb's forum for longer than it has existed. Some of the posts are a little difficult to find so long after the event. There are apparently 10 of them, but I can only find these 6...

Re: Theory on why it is hard to distinguish Requirements from Design, in Project Management & Product Development

Re: Gilb 88, in Project Management & Product Development

Re: Re: Definition, in Inspection, Quality Control & Defect Prevention

Re: Definition, in Inspection, Quality Control & Defect Prevention

Re: Classifying defects as Major/minor in Inspection, Quality Control & Defect Prevention

Design Methods, in Design, Industrial Design, Solutions

I also have a Gilb wiki home page, which links into my Gilb wiki contributions.

Forum Posts

I should get round to extracting specific forum posts soon enough, but contributions so far have been principally to:

Tom Gilb's website, http://www.gilb.com

The Seilevel Requirements Discussion forum, http://requirements.seilevel.com/messageboard/forumdisplay.php?f=3

LinkedIn Answers

Rob Gourdie is kind enough to publish on his blog my answer to a question of his on LinkedIn. See http://robgourdie.blogspot.com/2007/03/need-for-residual-risk-in-projects.html

Another answer of mine on knowledge management was picked as best response by Peter Nguyen: http://www.linkedin.com/answers/career-education/career-development/CAR_CRD/31514-2896748

See also my answer at http://www.linkedin.com/answers/business-operations/project-management/OPS_PRJ/29527-174352

Are you LinkedIn?

My network just exceeded 1.25 million. Check me out at http://www.linkedin.com/pub/1/382/421

If you came here from LinkedIn, please leave a comment here to say so. Thanks.

And so it begins

This is my first post to this blog.

Over the next few days, I shall create copies of, or links to, existing web content I have created.

To begin with, there are my wikipedia contributions: http://en.wikipedia.org/wiki/Special:Contributions/ARAJ.