Asking Great Questions – Requirements Elicitation

As part of the elicitation process, it is critical that we ask the right questions. When I hear someone say “The customer doesn’t know what they want,” I tend to cringe. I think the customer knows what they want. They may not know how to express that to us. Our job is to ask the right questions so we can help them explain to us what it is that they want. Sounds simple, right??

Here are some tips to getting to those GREAT (not just good) questions.

1. Keep an inventory of “Great Questions” I believe that successful requirements elicitation interviews begin with preparation. Many analysts think they can just go sit with a user and figure out what they want. That is not the case. Analysts need to research the problem domain and think about the questions they need to ask. The primary difference between expert analysts and novice analysts lies in the ability to recognize situations and apply the proper tools (i.e. questions) that are appropriate for the situation.

Experienced analysts tend to ask similar types of questions – they know they get the best results. When conducting an interview watch for instances where a particular question or specific phrasing of a questions works well in getting you the information you need. When that happens write it down. Add to the list as you become more experienced. Having these questions available makes preparing for interviews quicker. These questions, or versions of them, will server you will for nearly any project. Put them in your “toolbox” of questions.

2. What “points of pain” are we trying to solve? This is a great question for getting to the real business problem. We often get into projects assuming we all understand why we’re doing it. Let’s make sure. Let the user describe the pain he is hoping will be alleviated by this project. I asked a user this one time to have them respond that they had no idea what pain this project was supposed to alleviate. Not a good scenario. An alternative to this question is to ask what user this project need will fill.

3. What would happen if we did not implement this project? This kind of question can help get a feel for the criticality of the project. If the users do not feel it is critical, maybe we should rethink why we are using precious resources at this point in time for this effort.

4. What does success look like to you? This helps you understand the stakeholder’s vision for this project. What is the most important result of this project to you? Consider creating a checklist for success factors and order them in order of importance.

5. Who will benefit most from this project? This will help identify key stakeholders and users. This can provide a starting point for identifying actors for high level use cases or user stories.

6. Close every interview by asking if there is anything else that should be covered. This gives the interviewee an opportunity to express other thoughts or opinions that are important to them. This almost always uncovers a couple of new items of value.

This is just a starting list of potential questions. Add to your own list of great questions and share them with other members of your team. Remember the focus of elicitation is to get to the “essence” of the system – why it exists. Good luck!

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

Managing the Cone of Uncertainty

Some of you may not be familiar with the term "Cone of Uncertainty". In the Project Management and Requirement Management world it is often called "Scope". So what is the Cone of Uncertainty? If you have ever watched a weather report as they monitor the progress of a hurricane you will notice that the further the hurricane is from shore the larger the potential impact. As the hurricane nears, the potential impact becomes smaller and smaller as predictability improves.

It is no different in system development. Consider the early phases of a project, when we are far from understanding the potential impact of the system. Our estimates are based on what we used to call WAGs (Wild A** Guesses). Somehow these become finalized in a project schedule. I feel I must state here that we never came close to meeting that schedule. As we began to work through the requirements, our understanding of the system increased and our estimates began to change, and get closer to the truth during each phase of development.

So what can we do to manage this uncertainty? There is no silver bullet, of course. But there are some things we can do to mitigate this risk.

• Many environments change so slowly that they can be considered static. Know your environment and how quickly and often it changes.

• Before making any significant investments, uncertainty should be reduced to a comfortable level. Snap decisions are never a good thing. If there is uncertainty in new technology or new approaches, mitigate the risk with the input of experts.

• Systems engineering is volatile; external pressures increase uncertainty over time. External pressures can affect the entire development process. When those external pressures arise, assess and determine the importance of those pressures and identify their impact to the current development plans.

• You must actively and continuously work to reduce the uncertainty level. Just ignoring uncertainty will not make things any better. Identify uncertainty and meet it head on.

• The Cone of Uncertainty is narrowed both by research and by decisions that reduce variability. This is a key part of the System Engineering tasks. Document decisions and rationale and the resulting requirements so you can move on.

• These decisions are about scope, what is included - and what is not included. Continually assess what is in and what is out. Remember that today the capability might be in, and tomorrow it may be out (as Heidi Klum says on Project Runway). In an Agile environment this assessment is made almost daily.

Many process improvement efforts today are targeted towards reducing the size of the cone of uncertainty.

• Quality requirements from solid elicitation techniques

• Improved estimation techniques

• Formal requirements management

• Formal change management

• Proper and complete testing

Remember, that if these decisions change later in the project then the cone will widen. As always, requirements play a key role in managing the Cone of Uncertainty.

By: Marcia Stinson