Requirement Gathering Techniques – The essentials for you to know as a Business Analyst
Being good at Requirement Gathering Techniques is one of our biggest and most important tasks to try and get the most out of when engaging with stakeholders. You will do a mix of the techniques described here and the mix will be different for every project. Think about what suits the project best and have a read of the top tips associated with each of the requirement gathering techniques.
Requirement Gathering Techniques – Requirement Interviews
This requirement gathering technique is probably the most common way of eliciting requirements from your stakeholders out of all the requirement gathering techniques out there. When you perform a requirements interview keep these points in mind:
Once you introduced yourself to the interviewee you should first provide them with background on the project, the project scope and timeframes. It is also often useful to tell them who suggested you talk to them and why you would like to talk to them. If you know they may feel threatened by the project’s objective, find something positive to say which can put them at ease. Building rapport with your stakeholders here will stand you in good stead during the rest of the project.
Format of the Requirement Gathering Interview
Now that you have set the scene, you should also high-light the scope of your requirement gathering questions. Tell them for example that you have some questions about the overall purpose of their department, then you would like to talk about their most important business processes and finally if they could discuss their current system with you. You should also tell them that you are more than happy to answer their questions as you go. If they sound comfortable with your approach, they will feel more at ease with you which means you will get great results.
Requirement Gathering Questions
There is a skill in asking requirement gathering questions the right way. A few tips here would include:
- Ask open ended type of questions. Try to avoid asking ‘yes’ or ‘no’ type questions. Example questions could start like: “Could you please describe your daily tasks you perform to prepare the salaries for month end?” If this question is too high level for them you could try: “How do you know what each person’s salary will be each month?”, “Where do you find that information?”, “How long does it take you to do everyone’s salary pay slips”?, “Why does it take THAT long, what do you have to do?”
- Drill down to detail or pull up to higher level questions. In general, some people tend to talk specifics and focusses on exceptions. Other people talk contextually and in general and hardly ever delve into specifics. Use questions such as: “So in general terms, would you say the payroll system is inadequate?” if they tend to focus on a specific small aspect of the system which might not do what they need once a year! This type of question will ‘force’ them to pull out of divergence. The opposite also happens where you might need someone to be more specific. An example question could be: “Is it the report processing specifically that causes the system to fail?” and so on. This is one of the most powerful aspects amongst all requirement gathering techniques and can be used everywhere and in any conversation.
- Talk to the right stakeholder to get the right outcome. Depending on the level of stakeholder you are talking to, you will find that different people talk about a problem in different terms. If you need to understand the overall business process from a high level, it is probably not a great idea to interview the person performing a small part of that process.
It is a good idea to review more questions and plan your requirement gathering interviews well. Be prepared for each interview! Read more on this in Business Analyst Courses.
Learn how you can use UML Use Cases Diagrams during an interview as a tool.
Requirement Gathering Techniques – Requirement Workshops
I personally love using workshops to elicit requirements but I would never walk into a requirement gathering workshop without some pre-written requirements or concepts at a minimum! Why? There are several reasons why I would plan my workshop carefully:
- The more structure you can give a workshop the more focussed your session will be. If you don’t have an agenda, any pre-developed materials to run the session with, you will find that there might be a lot of ideas and activity in the session but it will most likely be of a poor quality.
- Know who is coming to your workshop. This is important because everyone who is coming will have their own ideas of what they want to get out of it. If you don’t have a clue who they are, how will you be able to plan for meeting their expectations or ensure their objectives are met. In an ideal world, meet everyone before the requirement gathering workshop for a short chat and understand their views of where they see your project going!
- You as the facilitator can control the flow of a workshop with so much less effort with a prepared and planned session than if you walk in blind. You will appear professional, in control and your stakeholders will trust you.
Benefits of a running a requirement gathering workshop:
- People have to justify their views in front of a larger group of stakeholders. This often help with eliminating nonsense type requirements you might get if you only do one to one interviews.
- Discussion of each topic, refines and clarifies the requirement. Your requirement quality is typically much higher at the end of a workshop.
- Stakeholder ‘buy in’. Involving people in a group format on the topic of requirement gathering does wonders for stakeholder ‘buy in’ for the project.
Disadvantages of a running a requirements workshop:
- Out of all the Requirement Gathering Techniques this one takes the most effort to plan, co-ordinate and prepare for.
- You don’t always manage to get all the right people in the room at the same time. (Idea here: Schedule more workshops and rerun the same session multiple times!)
- You may need more time for these requirement gathering activities than for other requirement gathering techniques but the upside is that your requirement quality is higher.
Requirement Gathering Techniques – Research and Observation
I put these two requirement gathering techniques together because they walk hand in hand a lot of the time. As a business analyst, it is a great idea to always include some of this technique into any requirement gathering techniques you choose to apply.
To job shadow someone means that you need to go sit with them for a few hours or days and observe how they perform their jobs. There is nothing like experiencing the practicality of someone’s day-to-day job. It becomes ‘real’ to you and you will translate and write your requirements with the people doing the actual jobs in mind.
When you do use ‘Observation’ as one of the requirement gathering techniques, keep these things in mind:
- Build up a picture in your mind (or on paper) of the end-to-end process a person follows to perform their average day in their job.
- If they allow questions, be selective and careful not to delve into too much detail with your questions or digress into a path of an exceptional circumstance.
- People will focus on what doesn’t work naturally, so you will get the picture fairly quickly once you spent some time with someone performing a job function or executing a business process. Take note of this and delve into the detail with them.
- Try and gather samples of forms, user training manuals and documented procedures that they follow to perform the role.
- Very important aspect of observation is to see what the system they are using is capable of, watch them use it, which parts of the process is perform manually and if possible try and understand the ‘why’ it is done that way.
Always remember to thank people who spent time with you! Build rapport when you are with them because you never know when you might to get back to them with more questions or observation requirements.
Return from Requirement Gathering Techniques to Tools & Techniques..
Return from Requirement Gathering Techniques to Business Analysis Excellence..
Sources of Requirements
Good requirements start with good sources. Finding those quality sources is an important task and, fortunately, one that takes few resources. Examples of sources of requirements include:
- Administrators and maintenance staff
- Domain Experts
- Industry Analysts
- Information about competitors
Requirements Gathering Techniques
After you have identified these sources, there are a number of techniques that may be used to gather requirements. The following will describe the various techniques, followed by a brief discussion of when to use each technique.
To get the requirements down on paper, you can to do one or more of the following:
- Conduct a brainstorming session
- Interview users
- Send questionnaires
- Work in the target environment
- Study analogous systems
- Examine suggestions and problem reports
- Talk to support teams
- Study improvements made by users
- Look at unintended uses
- Conduct workshops
- Demonstrate prototypes to stakeholders
The best idea is to get the requirements down quickly and then to encourage the users to correct and improve them. Put in those corrections, and repeat the cycle. Do it now, keep it small, and correct it at once. Start off with the best structure you can devise, but expect to keep on correcting it throughout the process. Success tips: Do it now, keep it small, and correct it immediately.
Conduct a brainstorming session
Brainstorming is a short group session where everyone is allowed to say whatever they feel is important to the topic of discussion. After that, a facilitator leads the group in organizing and prioritizing the results. The following basic rules for brainstorming ensures better results:
- Start out by clearly stating the objective of the brainstorming session.
- Generate as may ideas as possible.
- Let your imagination soar.
- Do not allow criticism or debate while you are gathering information.
- Once information is gathered, reshape and combine ideas.
Face-to-face contact with users through individual interviewing is the primary source of requirements and an important way you gather and validate their requirements. Remember that it is not the only possible technique, and that you can conduct interviews many different ways. Develop a repertoire of styles to fit different situations. Unless you use the system yourself, you will need to make an effort to understand and experience the user's problem to describe it clearly and correctly.
If face-to-face meetings are possible, they are always preferable, because they provide a better means of uncovering the problem behind the problem. Sometimes, though, face-to-face meetings with stakeholders are not feasible (when developing products for the consumer market, for example). In those situations, consider using questionnaires. Send a set of questions, possibly with multiple choice responses, to the relevant stakeholders, and ask them to complete it and return it to you. Success tips: Keep it short and given them a deadline.
This technique has the advantage of providing a lot of information for statistical analysis. However, the questions must be well designed to be clear and to avoid so-called "leading questions", which bias the responses.
Work in the target environment
Experience the work of the users for yourself. Working with users helps you understand problems that have resisted previous solutions. Familiar systems developed in this way inevitably include tools for programmers, such as interactive editors and compilers, as the developers naturally have both the expertise in the subject area, and the desire to solve their own problems. It would be good to see the same dedication devoted to solving problems in other areas too. Where the work cannot easily be experienced in this way, it may still be possible to do a bit more than just sit quietly and observe. Users can give you a commentary on what they are doing, what the problems are, and what they would like to have to make the work easier.
Study analogous systems
The starting point for many projects is often a similar or an existing system. Sometimes, comparable products and systems contain working versions of good ideas for solving user problems. You can save the time lost in reinventing the wheel by looking at systems already on the market, whether they are systems installed at the user's site or products made by rival organizations. Even if they are trying to solve slightly different problems, they often provide valuable clues as to what you need to do.
Listen when a customer asks why a product couldn't do something that the customer wants, and keep a list of these suggestions. Later, use it to start discussions with other users. You should be able to obtain some requirements directly this way. If not, capture and store suggestions for future use.
You can describe to users selected features of other products. Explain that the system is designed for another purpose but contains an interesting feature, and you wonder it or something similar would help them. Sometimes these systems are described in documents, such as a contract from another organization or a report written for management. Often, these documents were never intended as formal requirements, and were written merely to communicate a stream-of-consciousness idea. Define a process of going from disorganized to organized information.
Such a process might involve the following activities:
- Read the document from end to end (several times) to comprehend what the customer wants and what actually has been written.
- Classify all of the types of information in the document. (user, system requirements, design elements, plans, background material, irrelevant detail)
- Mark up the original text to separate out such requirements.
- Find a good structure for each of the different types of information such as: a scenario for the user requirements, functional breakdown for the system requirements, and architecture for the design.
- Organize the information to show gaps and overlaps. Feel free to add missing elements, but confirm these decisions with the users.
- Create traceability links between these information elements to show the designers exactly what the users want.
- Convince the customer to accept the new information as the basis for the contract.
Examine suggestions and problem reports
Requirements can come from change suggestions and user problems. A direct road to finding requirements is to look at suggestions and problems as first described. Most organizations have a form for reporting system problems or software defects. You can ask to look through the reports (and there will probably be many). Sort them into groups so you can identify the key areas that are troubling users. Ask users some questions about these areas to clarify the users' actual needs.
Talk to support teams
Most large sales organizations have a help desk that keeps a log of problems and fixes, and support engineers who do the fixing. Many organizations have similar facilities to support their own operations. Talking to the help desk staff and the support engineers may give you good leads into the requirements, and save you time. Also talk to the training team and installation teams about what users find to be difficult.
Study improvements made by users
This is an excellent source of requirements. Users of a standard company spreadsheet may have added a few fields, or related different sheets together, or drawn a graph, that exactly meets their individual needs. You need only ask: Why did you add that? Their answers help you get to the heart of the actual requirement. This applies also to hardware and non-computer devices. For example, a lathe operator may have manufactured a special clamp, or an arm that prevents movement of the tool beyond a certain point. Any such modification points to something wrong with the existing product, which makes it a valid requirement for the new version.
Look at unintended uses
People often use things for purposes for which they were not designed. This is a good way to get new ideas and to think of innovations. For example, an observant product manager noticed that an engineer was staying in the office late to use an advanced computer-aided design system to design a new kitchen layout for his home. Inexpensive commercial products are now widely available for home use.
Workshops can rapidly pull together a good set of requirements. In two to five days, you can create a set of requirements, and then review and improve them. If everyone in a workshop tries to estimate the cost and value of each requirement, the document becomes much more useful and cost-effective.
Workshops are quicker and better at discovering requirements than other techniques, such as sending questionnaires. You are bringing the right collection of people together, and getting them to correct and improve on their requirements document.
A workshop is inherently expensive because of the number of people involved, but it saves a large amount of time. If you can define the product right the first time and cut three months off the requirements gathering, the savings could be enormous. The workshop has to be thoroughly organized to take advantage of people's time.
Choose a quiet location for the workshop so that people are not disturbed by day-to-day business. Mobile phones should be discouraged; arrange to take messages externally. Take advantage of informal interactions by choosing a site so that people don't go home at night or go out separately. The example in Figure 1 shows the logic of a requirements workshop. Note that the workshop provides the environment in which to apply other requirements-gathering techniques such as brainstorming.
Figure 1: Conducting Workshops
Demonstrate prototypes to stakeholders
Prototypes allow us to immediately see some aspects of the system. Showing users a simple prototype can provoke them into giving good requirements information or changing their mind about existing requirements. The techniques described here help you gather ideas for requirements. Prototypes and models are an excellent way of presenting ideas to users. They can illustrate how an approach might work, or give users a glimpse of what they might be able to do. More requirements are likely to emerge when users see what you are suggesting.
A presentation can use a sequence of slides, storyboard, an artist's impression, or even an animation to give users a vision of the possibilities. When prototyping software, make a mock-up of the user interface screens, emphasizing that there is no code and that the system has not been designed or even specified yet (fair warning: there are dangers here for the unwary).
This prototyping aims to get users to express (missing) requirements. You are not trying to sell users an idea or product, you are finding out what they actually want. Seeing a prototype, which invariably is wrong in some ways and right in others, is a powerful stimulus to users to start saying what they want. They may point out plenty of problems with the prototype! This is excellent, because each problem leads to a new requirement.
Which Technique to Apply?
Which technique to apply depends on a number of factors, such as:
- Availability and location of stakeholders
- Development team knowledge of the problem domain
- Customers' and users' knowledge of the problem domain
- Customers' and users' knowledge of the development process and methods
If the stakeholders are not co-located or readily available, for example in the case of a product being developed for mass market, techniques such as brainstorming, interviews and workshops that require face-to-face contact with the stakeholders may be difficult or impossible.
If the stakeholders are available for face-to-face meetings, this is a much better situation and almost all of the techniques described, or combination of them, may be applied. In this case, the domain and development experience of both the stakeholders and the development team are critical factors in selecting the appropriate technique.
Figure 2, adapted from [HIC03], provides a framework for determining the appropriate techniques. It defines four main categories of customer or user experience and development team experience: "Fuzzy problem", "Selling/Teaching", "Catch up", and "Mature".
Figure 2: Selection of Techniques
There is no "right answer", but these guidelines may help you decide which method to use:
- Catch-up: Interviews, work in target environment
- Fuzzy: Brainstorming, workshops
- Mature: Questionnaires, workshops, prototypes
- Selling/Teaching: prototypes