Requirements Management – processes and tools

It’s no secret that professional requirements engineering solutions help improving efficiency when working with requirements. They also help minimizing the number of mistakes which would typically lead to costly corrections when found in later phases of the development lifecycle.

Therefore many companies are looking for such requirements engineering solutions. But unfortunately the same rule than for almost any other type of software tools also applies to requirements engineering solutions: a fool with a tool remains a fool…

The best-in-class requirements engineering solutions like IRQA from Visure Solutions are very flexible being able to support almost any kind of requirements engineering process. Of course, we – as a tool vendor – are happy to sell you some software but we are conviced that this alone won’t help you. Instead we want to help you being successful in using our products.

So, before purchasing a requirements engineering solution please make sure that you have a proper requirements engineering process defined with certain activities assigned to certain roles. Of course, we can also share our experiences with you in this area. If you know the detailed characteristics of your process it’s much easier for you to find an appropriate solution which fits the needs of your process.

I’m quite confident that IRQA will be your preferred choice…

By: Andreas Plette

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

Trick or Treat – A Technique for Gathering Requirements?

As Halloween approaches I watch the children getting excited about their costumes and their favorite activity for gathering loads of candy. I remember teaching my little ones to say “Trick or Treat” when they go to the door. We spent weeks selecting just the right costume; we rehearsed going to the door and saying “Trick or Treat” and then “thank you’. We planned our route for Halloween night. You could call this the “Trick or Treat” process.

The result is a bag of candy – all kinds of candy that you can imagine. One of the first things we would do when we got home was to go through the bag of goodies and sort it – a pile for gum, a pile for chocolate, a pile for fruit flavored candy, and so on. Once the candy was sorted the little ones would then organize it by the favorites – so they could make sure and get their favorites first, since they weren’t allowed to eat the entire bag that night.

You’re probably reading this and thinking cute story, but what on earth does this have to do with requirements? So I will make a couple of points here.

First, if you are interviewing users and basically say “Trick or Treat – give me some good requirements” guess what you will get? You will get a hodgepodge of things that the users would like to see. Some will be important to you and some will not. You will have to sort through all of those needs and sort them into categories. We usually call those categories features. Some of those features will be pertinent to the project and some will not. So if you are beginning to gather requirements why not be more focused in the questions that you ask? Do some research and look at any information available that is pertinent to the system. Identify end users (you don’t have to trick or treat in the entire subdivision, focus on a couple streets where the really good treats are given) and set up meetings with them.

Identify processes that are affected by the project – which ones are changing, which ones are new, are any no longer needed? Ask the users what processes are working well for them? Work to understand how they are doing their job today.

Second, once you have sorted the requirements into features, you will need to prioritize those features. What are the customer “favorites” for getting done first? Sometimes we fail to really prioritize and end up working on the easy parts of the system first, instead of focusing on parts of the system that are high risk or not well understood.

At the end of the project, revisit what happened. We might ask if we went on the right streets, if we followed the process or deviated for some reason, did we get as much candy as we expected? What worked well? What changes could be made to improve the process? Did we get the expected end results? Were the users satisfied with the product?

So even though this is written with a little Halloween humor, hopefully the points made here will hit home when thinking about gathering requirements! Happy Halloween!

By: Marcia Stinson

Improving Your Requirements Definition Process

Any time a change is made to either a process or the tools that are used to support the process, there is a learning curve that will impact the time required to perform that process. As you begin to think about improving your requirements definition process, keep in mind that there will be effort associated with this change. In most cases there is decrease in productivity as the work begins to progress. This decrease is often called the “J-curve”. As users attempt to change the way they do a particular task, they reach a point where they feel it is just simply too hard to make the change. The temptation here is to revert back to the old way of doing things just to get the task completed. Without a plan for overcoming this hurdle many organizations fail short of their goal to make this change. This challenge is true for both processes and tools. There are two strategies that can accelerate skills or tools adoption.

First, there is the depth approach. In the in-depth approach a core group of people are selected and are trained on the new process or tool and continue to receive mentoring as the cross the chasm from training to work on a real project. Mentors are often outside consultants with an expertise in the specific skills area. It is important to have experts available to help practitioners begin to use their new skills on a live project. This core group is fairly small and the intention is to use them as consultants for new projects who will be using the new skills. They become experts who move from project to project to help those individuals use their new skills.

The breadth approach focuses on a sound foundation of best practice skills that will be refined over time. In this approach mentors are brought in to provide this foundation of best practice skills, often through standard training in the specific skills area. Usually standard processes and templates are defined and documented for use by the various project teams. The initial training is provided to a large group of individuals versus the smaller, focused group mentioned in the depth approach. As projects begin to use the new skills and learn more about how their specific tasks are impacted, these results are fed back into the best practice foundation so it can be refined over time.

Whatever method you choose to manage this effort, it is critical to successfully making the required changes. Without a plan, these changes often fall to the wayside when the crunch of schedule and budget are felt. Making these kinds of changes requires discipline, support, and determination. Each project must be continually assessed to make sure the new skills are being used.

Think about a simple change to your requirements definition process. Who are the experts you can rely on internally? Do you need outside assistance for training and/or mentoring? Where will you go for this training and mentoring? Is your process well documented today or are you starting from ground zero? What is your plan for making sure you are successful (depth, breadth, both)? What is the timeframe for the change?

"Insanity is doing the same thing over and over again and expecting a different result". (Albert Einstein) If you feel that way, begin making changes that will give you the results you would like.

By: Marcia Stinson