2 June 2009

Fundamentals of Requirements Management

Ivar Jacobsen has proclaimed an end to methodology wars. It has me thinking about one particular part of the puzzle; managing requirements.

Fitting everything into the available time and resources is a major and constant struggle. Even when you spend months planning you still run into unintended features – things you have to build but didn’t plan to.

What helps deal with this?

Firstly a requirements manager who deeply knows and understands the client problem, and that has the trust of the client and sufficient authority to make a call on what is in or out of the product - at release 1 and at the end of the project. (See CRACK requirements)

Secondly, the ability to chunk (partition?) the work into multiple releases.  This addresses the need to deliver complete and coherent capabilities.

Need to capture a reciept number?  Sure thing, but do you have a free text field or do you integrate to the payments system?  The choice depends on time and money and competing priorities.  Both solutions are 'complete' in their own context.

Thirdly sufficient communication (and leeway) between the requirements manager and the developer team so that innovation can overcome some of the financial and schedule constraints, and so that develoeprs aren't left guessing what the right scope or success criteria are for a particular feature (see the above example.)

What else is core to successful requirements management?

Photo is from flickr


  1. Thanks for the blog about requirements management and thanks for the link to Ivar Jacobson's blog.

    Requirements management is very important. Lack of management at this critical phase of any software development effort can and usually does result in a runaway project.

    You had solicited further so here is a little something that I wrote up on doing good requirements management.

  2. I like the 4 types you have come up with. Does that cover all the bases?