Agoraphilia

I'm not a natural blogger.

The only reason I created this blog was as a publicly accessible link between my contributions on other people's blogs and fora.

I've found it useful, myself. But I wonder how useful others have found it...

Well, little by little we learn. Until now, I suppose I've been more concerned about the possibility than the occurrence. Now, I think it may be time to give social networking a try. I've signed up for del.icio.us and subscribed to the requirement tag. Perhaps that's why you're here?

Welcome!

My Seilevel requirements discussion posts

I feel the need, one day, to integrate the ideas in my posts to the Seilevel forum. Until that day arrives, my contributions can be found by following the link.

A random blog: Seilevel Presentation

A random blog: Seilevel Presentation

I've made a few contributions to the Seilevel forum, though I'm not convinced we're on the same wavelength.

...about checking rates

...about Tom Gilb, Agile and INCOSE 2007

...about Maslow's Hierarchy of Needs, mobile phones, trading off performance

...about decision-making processes

Three Cheers for the Worry-Stack (prioritization)

Let the Market Decide (prioritization)

...how worse can be better

...the final word on Goals vs. Businesss Objectives

...to copy or link: maintainability vs. usability

Effective Requirement Process

I waited a month before replying to a question on one of Tom Gilb's forums. This is only partly because I wanted to avoid doing the student's assignment. The main reason was so that I could canvass opinions on LinkedIn's new(ish) Answers facility. Interesting results from LinkedIn were:

1. A general distrust of KPIs (Key Performance Indicators)
2. The absence of any reference to possible KPIs, however flawed or dangerous
3. A belief in the impossibility of measuring the effectiveness of requirement processes
4. A fairly low number of responses (7). Is that because it's a hard question or an uninteresting one, I wonder.

I may yet re-open the question with my own thoughts included as clarification. For the moment I must leave a little time for others to comment on my Gilb post.

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!

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