Introduction
There are a myriad of requirements elicitation methods. The BABOK lists nine (Brainstorming, Document Analysis, Focus Groups, Interface Analysis, Interviews, Observation, Prototyping, Requirements Workshops, Survey/Questionnaire), but there are many more methods out there such as protocol analysis [1] , job application design [2] , and so on).
It’s doubtful that any single elicitation technique will always work for you. “Although some may advocate . . . just one elicitation technique . . . it is generally accepted that an individual requirements elicitation technique or approach cannot possibly be suitable for all projects.” [3] But obviously, you can’t do all of even the most popular ones when you unearth requirements for every project. So how do you decide which will give you the most bang for your buck (limited time), and why?
Your organization’s makeup, political climate, the nature of your project, and your personal strengths and preferences will have a lot to do with which methods work best for you. Having said that, here are five methods that analysts of nearly any experience or skill level can do, and that nearly always deliver a great return on the investment.
The Top Five Requirements Elicitation Methods
#5: Observation
Benefit: You can figure out exactly where users are at the start of your project, and you can use your strengths to document it.
Observation is primarily useful for capturing what’s already in existence and enables several other types of requirements tools, not the least of which is existing use-case scenarios. As one analyst notes, “We’ve found that informal use cases provide the best return on invested effort at the early stages of elicitation – they are easier to iterate, and provide less risk of getting caught up in the details of early thought processes.” [4]
Also, an analyst can document what she observes through numerous types of diagramming and business process models besides use cases. This method not only helps an analyst really get her brain around precisely what the current business needs and processes are, the wide array of available diagramming and modeling techniques ensure that you can use whatever you are most comfortable with.
Before you start observation, you’ll want to set the tone with your users. One writer does caution, “The effectiveness of observation . . . can vary as users have a tendency to adjust the way they perform tasks when knowingly being watched.” [5] Make sure the people you observe know that you are not there to judge what they do, but to make their work easier in the long run. Thank them for letting you hang out with them for a bit, and ask them to show you what they do in a typical task and explain it for you as they go. Ask them what they like and don’t like about it, and about any workarounds they’ve created on their own.
# 4: Brainstorming
Benefit: You can avoid potential “gotchas” down the road by enlisting others to help you discover your unknowns. Also, more than most other methods, brainstorming enables you to take in a wide amount of information at once, helping you figure out where you want to go from here.
Done properly (without censoring ideas as you go) and with the right audience (representatives of each group, SMEs, stakeholders), brainstorming has the most potential to prevent gotchas down the road, capturing needs you didn’t know about, processes no one mentioned, and things you hadn’t thought of. To an extent, this takes the onus off you for knowing your unknowns by helping everyone think outside the box and helping stakeholders take ownership of the direction of a project. The myriad of ideas and information also give you a rich repository of knowledge to choose from, so you can discern where to go next with your project.
#3: Interviews
Benefit: By exploring someone’s knowledge and needs in-depth, one-on-one, you ensure you understand the real, not just the perceived, need.
Interviews help you dig through your SMEs and users’ knowledge base, so you can understand what they understand and think—which is what you need to write strong requirements. One writer notes, “Interviews provide an efficient way to collect large amounts of data quickly,” but is quick to add, “The results of interviews, such as the usefulness of the information gathered, can vary significantly depending on the skill of the interviewer.” [6] For your interview to be effective, you must be persistent. Remember the five Ws—Who, What, When, Where and Why. When you can’t ask why anymore—you’re going in circles, you’re done with your interview. Also, decide how structured or unstructured you want your interview to be. One analyst advocates unstructured interviews, noting, “The most important thing to remember when interviewing is to ask open ended questions.” [7] You will want to keep your interviews unstructured enough to be sure that you’ve successfully mined your interviewee’s knowledge base, but structured enough to be sure that you cover all of your basic questions and don’t go too far off topic.
#2: Requirements Workshops
Benefit: You can get your basic requirements done in a hurry. Also, everyone you invite can become invested in the project.
In a requirements workshop, you ask everyone to sit down and hammer out the requirements with you. “A requirements workshop is a highly productive focused event attended by carefully selected key stakeholders and subject matter experts for a short, intensive period (typically one or a few days).” [8] To many analysts, this may sound impossible. Stakeholders are notorious for changing their minds and adding to discovery after six months—you’re going to put them in a conference room and nail down the scope over a weekend?
For your workshop to be successful, you will need to
- Select the right participants—SMEs, stakeholders, users, and so on. If you leave someone necessary out, the results of the workshop may have to be completely overhauled. Think about this carefully before inviting your group. As BABOK notes, “Requirements workshops that involve too many participants can slow down the workshop process. Conversely, collecting input from too few participants can lead to overlooking requirements.” Another source notes, “Key factors in the success of group work are the makeup of participants and the cohesion within the group. Stakeholders must feel comfortable and confident in speaking openly and honestly, and it is for this reason that group work is less effective in highly political situations.”[9]
- Get everyone on the same page regarding the purpose of the workshop ahead of time (defining scope, unearthing business requirements, etc.) Do some base research—use case scenarios, etc., before you start so everyone knows what the current process is.
- Conduct the workshop like an interview, with open-ended questions presented to the room.
- Document everything. Get a recorder or get someone besides you (or whomever will be busy facilitating) to write everything down.
#1: Prototyping
Benefit: You can make sure that what you’re designing is really what people need while you still have time to change it.
No matter how hard they try, some people just can’t analyze a system or product until they try it. Make it as easy as possible for them to do that. One analyst notes, “Users and business owners should not be expected to be able to visualize the new software. Users usually don’t know what they want until they see something they don’t want.” [10] Obviously, you can’t do this too early in the project—you need some idea of where you’re going before a prototype is feasible. “An advantage of using prototypes is that they encourage stakeholders, and more specifically the users, to play an active role in developing the requirements. . . . the technique is extremely helpful when developing new systems for entirely new applications.” [11] Innovative software is available now to make prototyping more accessible to analysts. If you don’t have a web person at your organization who does it, the software is worth pitching for.
When are other popular requirements elicitation methods useful?
Here’s an idea of when some of the other more popular methods might be a good fit for your project.
Survey/Questionnaire
Use this when
- You have a large audience to gather information from
- Your interviewees are scattered around time zones, making a virtual meeting or focus group unfeasible.
Note the constraint of this method is it can be difficult to ask follow-up questions or let a user interact with a prototype. “Questionnaires lack the opportunity to delve further on a topic, or expand on new ideas. In the same way they provide no mechanism for the participants to request clarification or correct misunderstandings.” [12]
Focus Groups
Use this when
- You haven’t gotten a lot of feedback from customers or users through Customer Service complaints, responses to the sales force, or any other avenue, and you need to explore their thoughts to chart your direction.
While focus groups allow you to dig into the thought processes of a select group of users, remember there’s always the danger that a small group may not be reflective of your entire audience of users. Also, participants must feel comfortable speaking honestly about their needs without fear of offending the moderator or stakeholders, or the benefit of the focus group is moot.
Document Analysis/Interface Analysis
Use this when
- You’re checking out what’s already there. In the course of nearly every project, every analyst will look at the user guides, previous requirements, and existing systems of their own organization.
- You’re bringing something competitive to market. Don’t just review your own documents. Without breaking any non-disclosure clauses or copyright laws, review everything you can get your hands on from competitors and other industries that have similar systems.
For more information on requirements elicitation, check out An Overview of Requirements Elicitation.
Author: Morgan Masters is Business Analyst and Staff Writer at ModernAnalyst.com, the premier community and resource portal for business analysts. Business analysis resources such as articles, blogs, templates, forums, books, along with a thriving business analyst community can be found at http://www.ModernAnalyst.com
[1] http://en.wikipedia.org/wiki/Protocol_analysis Accessed January 3, 2013. See also http://www.cs.toronto.edu/~sme/CSC2106S/slides/04-elicitation-techniques.pdf Accessed January 3, 2013
[2] http://en.wikipedia.org/wiki/Joint_application_design Accessed January 3, 2013. See also http://www.cs.toronto.edu/~sme/CSC2106S/slides/04-elicitation-techniques.pdf Accessed January 3, 2013
[3] http://epress.lib.uts.edu.au/research/bitstream/handle/10453/11626/2005003295.pdf?sequence Accessed December 5, 2012.
[4] http://tynerblain.com/blog/2006/01/14/top-five-requirements-gathering-tips/ Accessed December 5, 2012
[5] http://epress.lib.uts.edu.au/research/bitstream/handle/10453/11626/2005003295.pdf?sequence Accessed December 5, 2012.
[6] http://epress.lib.uts.edu.au/research/bitstream/handle/10453/11626/2005003295.pdf?sequence
[7] http://tynerblain.com/blog/2006/01/14/top-five-requirements-gathering-tips/ Accessed December 5, 2012
[8] A Guide to the Business Analyst’s Body of Knowledge® (BABOK® Guide), Version 2.0, International Institute of Business Analysis, Toronto, Ontario, Canada, ©2005, 2006, 2008, 2009.
[9] http://epress.lib.uts.edu.au/research/bitstream/handle/10453/11626/2005003295.pdf?sequence Accessed December 5, 2012
[10] http://tynerblain.com/blog/2006/01/14/top-five-requirements-gathering-tips/ Accessed December 5, 2012
[11] http://epress.lib.uts.edu.au/research/bitstream/handle/10453/11626/2005003295.pdf?sequence Accessed December 5, 2012
[12] http://epress.lib.uts.edu.au/research/bitstream/handle/10453/11626/2005003295.pdf?sequence Accessed December 5, 2012