Monday, October 13, 2008

Business Analysis Articles & Systems Analysis Articles

Resources


Article Archive


Articles and White Papers


Current Articles | Categories | Search | Subscribe (RSS)

» Requirements

Statistics:Article Rating (292 Views) (0 Comments)
Posted by: admin on Monday, May 14, 2007
Categories: Requirements Analysis (BABOK KA)

Maybe it was that southern drawl.

Or maybe it was because I got mad.

I'm not sure why I still remember this moment so clearly, but I do.  It happened when I was at Spyglass, over ten years ago.  Several of us developers were in a meeting with Steve Stone, then recently-hired as director of the Champaign office.  We were talking about a possible new feature.  Steve, in his Alabama accent, asked,

"So is that a requirement?"

A couple years later, I realized that I misunderstood the question.  I didn't have enough project management background to know the particular way that he was using the word "requirement".  For me at the time, the word "requirement" had connotations of absolute necessity.  So when Steve asked the question, here is what I heard:

"So is this feature something that absolutely must be in the next release of the product?"

On top of that, I'll confess I was sort of generally crabby at that point in my life, especially with respect to Steve Stone.  Instead of promoting me or one of the other lead developers to run the Champaign office, Spyglass had hired Steve from the outside.  In fact, Spyglass asked me to interview Steve, but only after the interview did they tell me I had actually been interviewing my new boss.

Anyway, I was in a generally foul mood when I misunderstood this question.  I suppose that's why I answered Steve by saying something like this:

"How the @%$* should I know if this feature has to be in the product or not?  You're new here, so let me explain how things go.  Management moved the headquarters to Chicago after years of promising that they never would.  Here in Champaign, nobody tells us anything.  We've got no marketing people except the team who spent 3 months deciding which Pantone color is the right shade of red for our company logo, which nobody ever sees because our product is an OEM component.  The only way we ever know that a feature absolutely must be in the product is when one of our Sales Guys calls up and tells us that he already promised it."

Steve was a very patient man.  I assume anybody who lived in Alabama would have to be.  :-)  He just smiled as he listened to my rant (footnote 1).

But my career with Spyglass didn't last too much longer after that.  A few months later, in a moment when I was ready to throw another tantrum, I decided to just quit instead.

And I went out on my own and founded SourceGear.  We started out doing contracting projects.  One of our first clients asked me for a Software Requirements Specification (SRS) and a Traceability Matrix.  That wasn't a very good day.

But not long after that, I learned what the word "requirement" means when used in the context of software project management.

And I learned what Steve Stone had really meant when he asked that infuriating question.  When Steve said:

"So is that a requirement?"

What he was really asking was:

"So it sounds like we just identified something that should become part of our spec.  You guys have a spec around here somewhere, right?  Who is responsible for updating that spec to capture this new item?"

(Poster's note: Great article on requirements from the developer's perspective.  Read the full article)

Author: Eric Sink

Read More ...

Comments
Currently, there are no comments. Be the first to post one!
You must be logged in to post a comment. You can login here
Syndicate  


Privacy Statement  |  Terms Of Use
Copyright 2006-2008 by Modern Analyst Media LLC