Do we really need Requirements Management?

Based on analysis and statistics from several organizations today, we know there is a critical need to adopt a requirements management practice. Let’s start by providing a definition in a simplistic manner. Requirements management represents the process of eliciting, prioritizing, documenting and agreeing on product requirements.

So now, what is the perception of product managers about the importance of this activity in an effective product management process? More specifically, what is the rationale behind adopting a structured approach for the definition of these customer needs? The justification for requirements management is to ensure that organizations meet the expectations and needs of its customers as well as its external and internal stakeholders. However, this is easier said than done. Even when organizations adopt an engineering approach towards software development, the most common pitfall is the customer's ability to verbalize what they want and need in a software product. So the overriding problem is how to ensure that the consumer needs are accurately articulated and analyzed by the product management team before they sent off for development.

We know and understand the importance of this up front elicitation and analysis activity, but we rarely spend the time required to do a good job. On one project I managed, the customer was very upset that we were spending so much time documenting their requirements for a website. Every time they would voice their concern I would ask them a simple question: Do you want the product to do what you expect it to do? Or is just any solution good enough for you. I asked that every time, without fail, when they complained. Of course they wanted it to do what they expected. I kept telling them that they needed to trust me, and believe that this work was essential to getting them the software product that they wanted and their customers would use. They relented. After a few requirements sessions the customer came up to me after a meeting and said “You are absolutely right about this. We have to do this.” Her change of heart came because we found a flaw in our logic that had not been verbalized by them. It was a simple thing. We were going through a use case on transferring funds and had an alternate path when the customer had only one account. The customer asked a simple question. Why do they even see the transfer funds option if they have one account? Good question. So we went back and rewrote the parent use case to remove that option for those customers. I pointed out how easy it was to correct that logic now instead of after they got the product in their hands. I also pointed out that there would be many more of these discoveries that we could correct in the requirements. That customer and I became great friends. The product was delivered and they were happy. There were some bugs and problems. I wish I could say it was bug free. But there were no major issues that required a lot of rework. When I moved on and a new analyst was working with them to document requirements for an upgrade, I heard the customer say “We want to spend time on these requirements so we get the right product at the end.” I felt that a huge battle had been won.

So all I can say is stick to your guns. Don’t let you customers tell you that you don’t need to spend time on requirements elicitation and analysis. Help them understand why they do need these activities and why the time will be well spent. Every time you find a problem and correct it in the requirements remind them of the time and money you just saved. We have an obligation to not only document and analyze requirements, but to help our customers understand why requirements management is critical for them as well.

I think it is obvious from this discussion that I believe in requirements management as a critical piece of any development project. I cannot, with a good conscience, work any other way. I hope that is true for you as well.

By: Marcia Stinson

The Mystery of Requirements

Many times in writing or reviewing requirements we tend to be a little “sloppy” in our writing. We need to remember that are not writing a mystery. What are some qualities of a good mystery novel?

• There is an underlying theme to the mystery.
• There are a lot of great characters involved.
• There is a clear setting where the story takes place.
• The final few chapters hold the climax of the story.

In other words, the author gives us clues all along, but it isn’t until the last few pages that we suddenly understand what the author has been trying to tell us all along.

Let’s take this approach with requirements. What makes requirements a mystery?

• There is no underlying theme. In other words, there is no clear reason, business or otherwise, why we are even doing this project.
• We get some of the characters involved, but we tend to miss some too. Making sure we have included everyone who is impacted by the project in any way is an important component.
• We’re not sure where the story takes place. To make a comparison, we don’t know where the product will be deployed or who will be using it. We need to know the setting.
• We are not persistent in understanding all of the clues the users give to us. There are lots of clues if we just pay attention. Users and stakeholders give us clues in many ways. Sometimes the clue may be in the way they respond to our questions in a nonverbal manner (i.e. rolling their eyes, crossing their arms, etc.). They may state assumptions about what they are thinking, yet another kind of clue for us. Sometimes a clue may lie in unspoken requirements that we have to try and get the users to verbalize for us. And sometimes the clues are in the form of a solution. When the users give us a solution they are really giving us a clue that they have a problem they are trying to solve. We must strive to understand what that problem really is.

The end of a mystery is exciting and gets our blood moving. We’re not sure until the last few pages that we really understood everything. If we manage projects in the same way we are in trouble. Software development should not be a mystery to us. We can’t wait until deployment to make sure that we solved the problem correctly. We want our requirements to be as clear and correct as possible from the beginning.

So here are some simple guidelines for writing requirements in a simple and concise statement, and removing some of that mystery.

• Every requirement should be a complete sentence. (i.e. a subject, verb and predicate with a period at the end) Remember our old English classes when we actually diagrammed sentences?
• Every requirement should describe clear success criteria. (The user shall be able to view the Audit Log Report.)
• Every requirement should state a single action and objective. Watch out for excessive use of “and” and “or”. For example:(If is the last Friday of the month and the payment is due on the 31^st, and if the 31^st is the last Friday of the month, then submitting the payment on that day after 6pm eastern time will result in a late payment.) I challenge to understand that one!
• A requirement should not have an escape clause. (The System shall determine the number of login attempts except when the user has clearly entered an incorrect username.)

Let’s make sure our requirements are not a mystery!

By: Marcia Stinson