It’s Christmas – Let’s Not Talk About Requirements

Hopefully you have your shopping all done and are ready for the holidays. I admit I’m a bit of a procrastinator. But this year I got things done early and I’m all ready to celebrate. We’ve made plans for the family to get together. We know who is bringing what food for our big dinner. We follow the same process every year for opening gifts – youngest to the oldest.

Think about a different scenario. It is Christmas Eve and you are frantically running from store to store to buy gifts. They are picked over and you can’t really find what you want so you settle for just about anything. You rush home to prepare dinner. Only you find you don’t have many of the ingredients you need so you run back to the store. That’s picked over too. You can’t make the pie you wanted because you can’t find the ingredients. There are few turkeys left, only small ones, so you have to buy three small ones instead of one big one. You run home and work all evening preparing your meal. The next morning the family arrives, each one bringing a dish. And to your dismay you find you have four bowls of mashed potatoes and four bowls of sweet potatoes. No salad. No stuffing. Just your three turkeys and some potatoes. And no desserts. You open presents and there is not a big response to your gifts. Unfortunately there was nothing in those packages that the family really wanted. This scenario definitely is a result of no planning.

I’m sure you can see where this discussion is going. No planning. The results are questionable. We can probably get by with the end results. But it’s not ideal. Often it’s not even acceptable. Sometimes or family is forced to take what we give them, even if it’s not what they really wanted.

There’s always an excuse not to think about planning. I was trying to think of all of the excuses I have heard over the years. See if you recognize some of these.

I’m working too many hours to plan these activities.

The family doesn’t know what they want.

No one tells me what they would like for Christmas.

Our schedule doesn’t allow any time to plan – we just have to wing it.

We know it’s important, but who is really going to do the planning.

And so on it goes.

I said we wouldn’t talk about requirements and I haven’t mentioned them once (until this sentence). But without saying anything I’m sure you can see where this discussion is going. Since it is the Christmas week I won’t even add any additional points.

I will only say that I hope your holidays are better planned that we have talked about here. Enjoy the holidays with your families. And don’t think about requirements one time until you are back at work. Then you can think about the kind of scenario you want for your project. I wish the best for you and your family during this holiday season.

By: Marcia Stinson

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

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

Risk Analysis in Requirements Engineering: FMEA

In a couple of industries like Automotive, Aerospace and Medical Devices Risk Analysis becomes more and more important because lots of standards and regulations require Risk Analysis for safety critical systems. In many cases the manufacturer of such a safety critical system is forced proving that they did Risk Analysis in a proper way.

FMEA (Failure Mode and Effects Analysis) is one of the most famous techniques for analysing risks. In FMEA an interdisciplinary team derives risks from the requirements which are then evaluated in a structured way. For each risk three values are specified:

• Severity
• Occurence
• Detection

The Risk Priority Number (RPN) is then calculated by multiplying these three values. If the RPN is lower than a certain threshold the risk is seen as acceptable and no further actions need to be taken. If the RPN is too high additional actions must be taken to either decrease the probability of occurrence or to increase the probability of detection by the system.

Whenever an action was defined to reduce a certain risk a re-evaluation needs to be done. If the RPN for risk + action is still too high another action must be defined.

While preforming Risk Analysis we obviously create different types of information which are related to each other. So, why not using the requirements management solution with its dedicated support for managing such relations not only for the requirements but also for Risk Analysis?

Using the traceability capabilities of such a solution eases up approvement processes with certification authorities tremendously.

And if you need to create a nice looking report for the certification authority, just click a button (or generate them in batch mode while you relax at home…):

Life could be so easy…

By: Andreas Plette

What is a requirement?

Whatever kind of system, software, product or service you would like to offer to the market all your efforts are based on requirements to be fulfilled. Indeed, this is not new. Most of us are writing requirements since decades. But do we really know what a requirement is?

There are almost as many definitions out there as books available about Requirements Engineering. But do these definitions really help in our daily work?

A couple of weeks ago I had the pleasure to participate in a workshop about requirements methodology. At the beginning we did a small exercise. We got the following text frament – taken from a real-life example (!) - and we were asked to count the requirements regardless whether they are “good” or “bad”:

Sounds like a simple question. But: although most of the participants had several years of experience working with requirements we got an interesting result (the constructor wrote down the answers of the individual participants):

Why that?

Of course, each participant has its own experiences and knowledge about the system to be build which highly influences the way they read the document. So, you cannot expect to get a single answer…

Then we started to analyze the given text sentence by sentence trying to formulate requirements with better quality based on two of the most important characteristics for a “good” requirement:

• You must be able to implement the requirement
• You must be able to verify that the implementation fulfils the requirement

Using these quite simple rules we came to the following improvement (which still may not be perfect):

From this example you can see one of the major drawbacks when using word processing tools for requirements: Authors tend to provide justifications for certain requirements in subordinate clauses (e.g. 3 is the justification for 2). Then it may happen that they introduce redundancy (e.g. requirements 2 and 5 in the example above) which makes it difficult to maintain these documents. Apart from the implicit relations the author has “created” using subordinate clauses there are of course more relations between the different requirements we identified above. If you try to represent these relations in a more structured way you may get the following [please do not use a word processing tool for this… = ) ]

So, finally we identified requirements from four different abstraction levels within the first three sentences of the original document!

Think about it…

By: Andreas Plette