The Top Five Go-To Requirements Elicitation Methods

The Top Five

#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.

Credit: Morgan Masters