- TrIpLeZoNe -

Requirements-Led Project Management: What Is the Value of Requirements?
I've been discussing lately on Project Management, and getting requirements from the clients, and how to go about doing it. Here's a sample chapter from the book "Requirements-Led Project Management" on "What is the Value of Requirements?". This chapter will help you analyze the requirements of your project at hand, and decide how to proceed in light of the investments required to make it work.

Whenever we make an investment—some stocks, a new car—or do some work, we like to think we get something in return for the money or effort expended. In this chapter, we look at your investment in requirements and what you can expect in return. And though all men may be considered equal, all requirements are not. Some requirements are crucial to the product, while others are gold-plated luxuries. We discuss how business people and requirements analysts can determine how much to invest in requirements, by focusing on the value of requirements to their organization.

How true is that statement? Very, in my opinion. And frankly speaking, most business people don't know the difference between requirements that are "CRUCIAL" (or needs as discussed previously) and requirements that are "GOLD-PLATED LUXURIES" (or wants as discussed previously) when it comes to software requirements and applications. Here's another quote from Steve McConnell which stands so true.

"Improved software practices provide returns ranging from 300% to 1900% and average about 500% ... The reason for these exceptionally high returns is ... improved practices [that] have been available for decades, but most organizations aren't using. Risk of adopting these practices is low; payoff is high."

—Steve McConnell, Professional Software Development

Here're more excerpts from the book, which I find very useful.

Building the Right Product

Building the right product means finding what is really needed, and not just what people say they want. It also means getting it right the first time, and not having to drag through the long repair activity that many projects suffer. Requirements gathering is about finding this right product and specifying it unambiguously to the developers.

This is very true, and always missed out by everyone. You must remember to find out what is really needed (see the "need" again?) and not what people say they want (see the "want" again?). And another important keyword is specifying it "unambiguously" to the developers. Remember! Your developers NEED to know the entire picture of the project, and not just what their part does. And the developers NEED to understand the purpose and the "needs" for that particular requirement on the project. Thus gathering while gathering requirements, you must always try follow this template.

Requirements

Justification  

Need/Want

where Requirements are the requirements in simple easy to understand, non-technical words that everyone can read; justification is the explanation why you need/want this requirement and how it applies to the business (business value) and whatever that can justify the feature is required; need/want is to catalogue it as either a need or a want, so you can sort your requirements list. Usually there will be very few wants in your list.

Requirements Analysis are the people who actually find out in details how to implement the particular requirement. I think that's what Firedancer is trying to tell me.

Another quote from the chapter which is rather good.

Requirements have value because they enable the builders to concentrate on developing the product instead of guessing about missing or ambiguous requirements, then having to retrace their steps and undo incorrect interpretations.

I think requirements gathering is much of an art and skill than anything that can be picked up easily. This quote is particularly true (I'm very sure) everywhere that we as developers have been guessing about missing and ambiguous requirements, and keep re-correcting the wrong interpretations.