Requirements Gathering Techniques
1.Brainstorming
2.Document Analysis
3.Focus Group
4.Interface Analysis
5.Interview
6.Observation
7.Prototyping
8.Requirements Workshop
9.Reverse Engineering
10.Survey
1. Brainstorming
Brainstorming is used in requirements elicitation to get as many ideas as possible from a group of
people. Generally used to identify possible solutions to problems, and clarify details of
opportunities. Brainstorming casts a wide net, identifying many different possibilities.
Prioritization of those possibilities is important to finding the needles in the haystack.
2. Document Analysis
Reviewing the documentation of an existing system can help when creating AS-IS process documents, as
well as driving gap analysis for scoping of migration projects. In an ideal world, we would even be
reviewing the requirements that drove creation of the existing system – a starting point for
documenting current requirements. Ask questions as part of validating requirement completeness.
3. Focus Group
A focus group is a gathering of people who are representative of the users or customers of a product
to get feedback. The feedback can be gathered about needs / opportunities / problems to identify
requirements, or can be gathered to validate and refine already elicited requirements. This form of
market research is distinct from brainstorming in that it is a managed process with specific
participants. There is danger in “following the crowd”, and some people believe focus groups are at
best ineffective. One risk is that we end up with the lowest common denominator features.
4. Interface Analysis
Interfaces for a software product can be human or machine. Integration with external systems and
devices is just another interface. User centric design approaches are very effective at making sure
that we create usable software. Interface analysis – reviewing the touch points with other external
systems – is important to make sure we don’t overlook requirements that aren’t immediately visible
to users.
5. Interview
Interviews of stakeholders and users are critical to creating the great software. Without
understanding the goals and expectations of the users and stakeholders, we are very unlikely to
satisfy them. We also have to recognize the perspective of each interviewee, so that we can properly
weigh and address their inputs. Like a great reporter, listening is the skill that helps a great
analyst to get more value from an interview than an average analyst.
6. Observation
The study of users in their natural habitats is what observation is about. By observing users, an
analyst can identify a process flow, awkward steps, pain points and opportunities for improvement.
Observation can be passive or active (asking questions while observing). Passive observation is
better for getting feedback on a prototype (to refine requirements), where active observation is
more effective at getting an understanding of an existing business process. Either approach can be
used to uncover implicit requirements that otherwise might go overlooked.
7. Prototyping
Prototypes can be very effective at gathering feedback. Low fidelity prototypes can be used as an
active listening tool. Often, when people can not articulate a particular need in the abstract, they
can quickly assess if a design approach would address the need. Prototypes are most efficiently done
with quick sketches of interfaces and storyboards. Prototypes are even being used as the “official
requirements” in some situations.
8. Requirements Workshop
More commonly known as a joint application design (JAD) session, workshops can be very effective for
gathering requirements. More structured than a brainstorming session, involved parties collaborate
to document requirements. One way to capture the collaboration is with creation of domain-model
artifacts (like static diagrams, activity diagrams). A workshop will be more effective with two
analysts than with one, where a facilitator and a scribe work together.
9. Reverse Engineering
Is this a starting point or a last resort? When a migration project does not have access to
sufficient documentation of the existing system, reverse engineering will identify what the system
does. It will not identify what the system should do, and will not identify when the system does the
wrong thing.
10. Survey
When collecting information from many people – too many to interview with budget and time
constraints – a survey or questionnaire can be used. The survey can force users to select from
choices, rate something (“Agree Strongly, Agree…”), or have open ended questions allowing free-form
responses. Survey design is hard – questions can bias the respondents. Don’t assume that you can
create a survey on your own, and get meaningful insight from the results. I would expect that a well
designed survey would provide qualitative guidance for characterizing the market. It should not be
used for prioritization of features or requirements.
Regards
Kshitij Yelkar
www.yelkar.com
1.Brainstorming
2.Document Analysis
3.Focus Group
4.Interface Analysis
5.Interview
6.Observation
7.Prototyping
8.Requirements Workshop
9.Reverse Engineering
10.Survey
1. Brainstorming
Brainstorming is used in requirements elicitation to get as many ideas as possible from a group of
people. Generally used to identify possible solutions to problems, and clarify details of
opportunities. Brainstorming casts a wide net, identifying many different possibilities.
Prioritization of those possibilities is important to finding the needles in the haystack.
2. Document Analysis
Reviewing the documentation of an existing system can help when creating AS-IS process documents, as
well as driving gap analysis for scoping of migration projects. In an ideal world, we would even be
reviewing the requirements that drove creation of the existing system – a starting point for
documenting current requirements. Ask questions as part of validating requirement completeness.
3. Focus Group
A focus group is a gathering of people who are representative of the users or customers of a product
to get feedback. The feedback can be gathered about needs / opportunities / problems to identify
requirements, or can be gathered to validate and refine already elicited requirements. This form of
market research is distinct from brainstorming in that it is a managed process with specific
participants. There is danger in “following the crowd”, and some people believe focus groups are at
best ineffective. One risk is that we end up with the lowest common denominator features.
4. Interface Analysis
Interfaces for a software product can be human or machine. Integration with external systems and
devices is just another interface. User centric design approaches are very effective at making sure
that we create usable software. Interface analysis – reviewing the touch points with other external
systems – is important to make sure we don’t overlook requirements that aren’t immediately visible
to users.
5. Interview
Interviews of stakeholders and users are critical to creating the great software. Without
understanding the goals and expectations of the users and stakeholders, we are very unlikely to
satisfy them. We also have to recognize the perspective of each interviewee, so that we can properly
weigh and address their inputs. Like a great reporter, listening is the skill that helps a great
analyst to get more value from an interview than an average analyst.
6. Observation
The study of users in their natural habitats is what observation is about. By observing users, an
analyst can identify a process flow, awkward steps, pain points and opportunities for improvement.
Observation can be passive or active (asking questions while observing). Passive observation is
better for getting feedback on a prototype (to refine requirements), where active observation is
more effective at getting an understanding of an existing business process. Either approach can be
used to uncover implicit requirements that otherwise might go overlooked.
7. Prototyping
Prototypes can be very effective at gathering feedback. Low fidelity prototypes can be used as an
active listening tool. Often, when people can not articulate a particular need in the abstract, they
can quickly assess if a design approach would address the need. Prototypes are most efficiently done
with quick sketches of interfaces and storyboards. Prototypes are even being used as the “official
requirements” in some situations.
8. Requirements Workshop
More commonly known as a joint application design (JAD) session, workshops can be very effective for
gathering requirements. More structured than a brainstorming session, involved parties collaborate
to document requirements. One way to capture the collaboration is with creation of domain-model
artifacts (like static diagrams, activity diagrams). A workshop will be more effective with two
analysts than with one, where a facilitator and a scribe work together.
9. Reverse Engineering
Is this a starting point or a last resort? When a migration project does not have access to
sufficient documentation of the existing system, reverse engineering will identify what the system
does. It will not identify what the system should do, and will not identify when the system does the
wrong thing.
10. Survey
When collecting information from many people – too many to interview with budget and time
constraints – a survey or questionnaire can be used. The survey can force users to select from
choices, rate something (“Agree Strongly, Agree…”), or have open ended questions allowing free-form
responses. Survey design is hard – questions can bias the respondents. Don’t assume that you can
create a survey on your own, and get meaningful insight from the results. I would expect that a well
designed survey would provide qualitative guidance for characterizing the market. It should not be
used for prioritization of features or requirements.
Regards
Kshitij Yelkar
www.yelkar.com
