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

Practice Makes Perfect – Requirements Engineering Training

When I was young my mother decided I should take piano lessons. I was five years old and barely knew my ABC’s. My teacher was an older woman who sat down my first lesson and played Beethoven’s Moonlight Sonata for me. I was so impressed. I wanted to play that piece right away. An impossible goal, of course.

There was so much I had to learn before I could play that piece. I started with one hand (one hand, are you kidding????) and learned three notes on my first lesson. Then three notes on the left hand. Then five notes. I remember thinking this would take forever. And so on. It was many years of learning and practice before I was able to play Beethoven’s Sonata.

There were some key things I had to learn to do. First, I had to learn how to hold my hands properly. Then I had to learn to read music – a few notes at a time. Then I had to learn how to read the music and then play it. And, above all, I had to practice. I practiced at least an hour every day, more in the summer. And still it took five years for me to play that piece. My teacher was instrumental in that process. She taught me techniques. She corrected me when I made a mistake. I could not have learned to play the piano without her.

So let’s tie this to Requirements Definition and Management. Asking someone who’s never written or managed requirements to follow a robust and complex requirements process is like asking that five-year-old to play Beethoven’s Moonlight Sonata. And since we often don’t provide any training or mentoring, let’s ask them to learn to play that piece on their own. That’s what we are doing when we throw our analysts into a complex requirements process.

I suggest we consider training our analysts. Let’s stop thinking we all just “know how to do our job”. It isn’t true. We can learn to play that piece on our own. I would suggest instead of taking five years, it would have taken me ten years on my own. And so it is with our requirements engineers and analysts. We can let them learn on their own. Or we can give them some training, mentoring, and time to practice.

Of course, key to making this work (no pun intended) is having some kind of process defined that we use to train our analysts. I used to hate that “process” word, but it is important. Here are some suggestions for turning your new requirements analysts into expert requirements analysts quickly.

1. Provide training for your analysts around your specific process, using your requirements and deliverables, so the training is more real.Generic classes around requirements definition and management are great, but they must be in line with the processes you are following in your organization.If you are working with an outside consultant, expect that there will some effort in customizing the training for you.But it will be worth the investment.
2. Assign a mentor to your new analysts.Let someone who has “been there done that” and has the wounds and scars to prove it help the new analyst and show them the ropes.This will help eliminate that “tribal knowledge” thinking.Let them assist in elicitation sessions, review requirements documents with the analyst, and be a resource for them.
3. Let the analyst practice. That may not seem too practical. But don’t start a new analyst on a project that is critical to the company. Or one that has so much history and controversy around it that it will be difficult to move forward. Let them “practice” on a simple and well understood project to get their feet wet.

I believe the following statement is true.

“Good analysts are grown, no trained.”

Let’s grow some good analysts.

By: Marcia Stinson