It all started with the recent CIO article Fixing the Requirements Mess. A comment by Christopher Creel (halfway down the page) was then put on the Requirements Defined Message Board. After reading Mr. Creel’s comments, and the other postings, I think people are missing the main problem with his argument. The rationale for holding on [...]

The November 15, 2005 issue of CIO Magazine leads with the headline “Rethinking Requirements” and includes an article titled Fixing the Requirements Mess. Now, I just know someone is going to come along and burst my bubble by revealing this is a recycled story the editors run every few months, but I was pleasantly surprised [...]

Last night I was interviewing a candidate and I asked him to tell me the value of a recent project for which he was the lead business analyst. He asked me what I meant and I clarified by asking him to tell me why was the project being done at all. He quickly replied “To [...]

I came across this the other day. It is a meme that has been making its way around the net for the past couple of years and purports to show how the mind is able to make sense out of jumbled words as long as the first and last letters are correct. Here is an [...]

Don’t blame me if the title of this seems a bit sarcastic; it’s the opening line Karl Weigers gives for his webinar, Software Requirements: 10 Traps to Avoid. Personally, I enjoyed the webinar. I thought his introduction, covering the hierarchy of software requriements (scope–use cases–functional requirements) was a good introduction that too many analysts and [...]

Earlier this morning I was working on my first blog post. If I can ever find it again, the topic will be “the most important thing”. Unfortunately you will have to wait on that posting and instead read this, my second blog post, first. All of this probably sounds a little confusing, because it is. [...]

Roger Cauvin had an interesting post the other day where he stated that “most organizations place too much emphasis on functional requirements.” The following day he expanded on this position by concluding that the overemphasis on functional requirements is detrimental to product development because “it shows the product manager dipped into design and failed to [...]