How do I manage the customers’ complex requirements?

How would you handle this scenario? A customer has stated that they the system to be user friendly. I call this a complex requirement because it is effectively a collection of many unique requirements. Elicited requirements should be at an atomic level. In other words, each requirement should be a unique and complete thought. But what is the best way of getting to this level with the customer? Reality (and experience) tell us that that many requirements are actually much more complex than stated.

Remember that we should not expect the customer to give us any good requirements. They are supposed to provide us the problem they want to be solved. If this is not clear then we need to need to ask them! They are expert of the problem. If we pursue this statement a bit more we may find that the requirement is that the Customer must train 500 people in three months to use the new system. Of course it must be user friendly. But what the Customer really needs is a way to ensure new users can be trained quickly. That may change the focus of the solution – user manuals, online training, tutorials, etc.

So let’s take that simple request for a user friendly system. Here are some of the problems.

• A Customer doesn’t want a workshop to determine what user friendly means. The Customer wants us to think for them. After all we are their “consultants”.

• The Customer doesn’t know completely what they want. They haven’t thought through exactly what user friendly means to them. They may have added this because it’s a good idea and everyone else is doing it.

• The Customer is too busy to provide quality input to us. Ask them to spend half an hour talking about what user friendly means to them and they may simply decline to spend the time.

• The Customer may not have determined all of users who are looking for a user friendly system. In other words, he may not have identified everyone who might want to determine if the system is user friendly (e.g. corporate customers, non-corporate, experienced users vs. inexperienced users, foreign customers, etc.).

There are some things that can be done to mitigate the risk associated with a requirement of this type.

• Do some prototyping of screens and show them to the user. Ask them specifically if they think these are user friendly. Then capture the aspects of the screens into a set of user interface requirements.

• Create your own definition of user friendly. Define the criteria and use these to define your user acceptance tests. Provide these to the customer to review.

• Keep pursuing your understanding of the problem. Don’t be afraid to keep asking questions and delve into the real reason behind the customer’s requirement.

• Make sure you have clear criteria to measure the requirement. Without it, you will never pass the requirement in the Customer’s eyes. And without it, the requirement is of no use at all.

By: MARCIA STINSON

Requirements Management Tools – Today’s Trends

The market for Requirements Management tools looks heavily over-saturated today. And what is amazing is that new players are still constantly entering the market. However, just as quickly some of these players vanish from the market. Free trials seem to be becoming a standard practice for new tools and prices for web-based software are falling fast. There is a widening gap between the heavyweight, closed environment, local database traditional RM tools and the lighter and cheaper offerings which often also include free integrations with other software (including old RM tools). Requirements tools are becoming simple to download and install. This effort no longer requires complex database setup done by an administrator.

The trend towards a standard requirements interface is gathering momentum, allowing users to use requirements information across multiple tools, some of which are not requirements management tools.

Most RM tools are focused on either requirements definition or requirements management. It is important that potential customers understand the different between the two activities. Requirements definition is focused on gathering user needs and analyzing these needs to create a consolidated set of user requirements. This is just the beginning of the requirements effort. 90% of organizations today are still using Word to document their business and user requirements. Many requirements management tools today focus on providing a way to leverage existing requirements information that is provided outside of the tool, in particular a tool like Word. Other requirements management tools that are focused on this effort provide more functionality related to the elicitation process and provide methods to document actor and object names, create use cases, and document high level test plans.

Requirements management today involves very complex models to handle conditions such as multiple variations on the same basic project, reuse of components across projects, variants in reused components, and multiple release of each project. This complexity is not handled by many requirements management tools on the market today, especially those focused on the requirements elicitation activities.

IRQA is a state-of-the–art tool that has been able to meet many of the demanding needs of customers today. Although providing true requirements management support, it is not a heavyweight from an administration or cost perspective. It is simple to download and install and uses a standard database. The graphical view it provides to organize your project information is a new approach from a requirements management tool that allows users to easily visualize and create an information structure. If you are looking for a tool to handle some of the complex conditions mentioned in the previous paragraph then you should check out IRQA from Visure Solutions.

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