Requirements elicitation is the process of collecting system requirements from stakeholders using various techniques such as interviews, focus groups, and document analysis. It ensures all relevant needs are captured but can be time-consuming and may lead to conflicts if not managed carefully. Effective techniques include prototyping, questionnaires, and use cases, each with distinct advantages and drawbacks in gathering user input and feedback.

1. Requirements elicitation is the practice of collecting
the requirements of a system from users, customers
and other stakeholders. The practice is also sometimes
referred to as requirements gathering.
Presented By:
Muhammad Imran Hussain Khan
0300-6519990

2. Stakeholder Analysis
Brainstorming
One On One Interview
Group Interview
Document Analysis
Focus Group
Interface Analysis
Observation Social Analysis
Prototyping

3. Facilitated sessions
Joint Application Development (JAD)
Questionnaire
Survey
Use cases and scenarios (UCD)
Reused Requirements
Request for proposals (RFPs)
Reverse Engineering

4. Stakeholder analysis identifies
all the users and stakeholders
who may influence or be
impacted by the system. This
helps ensure that the needs of
all those involved are taken into
account
Benefits
1. Ensures that all relevant
stakeholders are considered
1. All important
stakeholders are captured,
and yet that irrelevant
actors are not included
Drawbacks
There is a danger that too much
time is spent on
identifying roles and
relationships, and the team is
swamped with data.

5. Basic Rules
1. Start out by clearly
stating the objective of
the brainstorming
session.
2. Generate as may ideas as
possible.
3. Let your imagination
soar.
4. Do not allow criticism or
debate while you are
gathering information.
5. Once information is
gathered, reshape and
combine ideas.

7. The most common technique for
gathering requirements is to sit
down with the clients and ask
them what they need. The
discussion should be planned
out ahead of time based on the
type of requirements you’re
looking for
• Privacy of everyone
• in-depth a stakeholder’s
thoughts and get his or
her perspective
Benefits
• Time Consuming
• Misunderstandings
Risks & Drawbacks

8. If there are more then one
person during interview usually
2 or 4 these people must be on
some level must be on some level
less time required
• we can get hidden requirements
• uncover a richer set of
requirements in a shorter period
of time
• Uncover ambiguities
Benefits
• Not relaxed environment
• Conflicts
• The allotted time have been
exhausted
Risks & Drawbacks

9. Document Analysis is an
important gathering technique.
Evaluating the documentation of a
present system can assist when
making AS-IS process documents
and also when driving the gap
analysis for scoping of the
migration projects.
• validating the requirement
completeness.
• Chunks of information are mostly
buried in present documents
• A beginning point for documenting
all current requirements.
Benefits
• Time Consuming
• Conflicts
• Exhausted
• Not Found Real Figures
Risks & Drawbacks

10. A focus group is actually gathering of
people who are customers or users
representatives for a product to gain its
feedback. The feedback can be collected
about opportunities, needs, and
problems to determine requirements or
it can be collected to refine and validate
the already elicited requirements.
• Managed process with particular
participants
• refine and validate the already
elicited requirements
• Allows analyst to rapidly obtain a
wide variety of user views and
possibly a consensus.
Benefits
• following the crowd and some
people think that focus groups
are at best unproductive
• end up with is with least common
denominator features.
• Recruitment effort to
• Assemble groups. Dominant
participants may influence group
disproportionately
Risks & Drawbacks

11. Interface for any software product will either be human or machine.
Integration with external devices and systems is another interface. The
user centric design approaches are quite effective to ensure that you
make usable software. Interface analysis- analyzing the touch points
with another external system- is vital to ensure that you do not overlook
requirements that are not instantly visible to the users.

12. Social analysis is also known as
Observation. Observation is the method
of collecting requirements by observing
the people doing their normal work.
This method is generally used to find the
additional requirements needed by the
user, when the user is unable to explain
their expected requirements from the
new product and problems with the
existing product
• The ability to record and
report all findings that are
true
• it is more practical
• no long calculation has to be
done
Benefits
• The viewer's or researcher's
own perception
• few trials/studies/or objects
observed to make an end
conclusion
• results may contain human
error
Risks & Drawbacks

13. Prototyping is a relatively modern technique
for gathering requirements. In this approach,
you gather preliminary requirements that you
use to build an initial version of the solution
— a prototype. You show this to the client,
who then gives you additional requirements.
You change the application and cycle around
with the client again. This repetitive process
continues until the product meets the critical
mass of business needs or for an agreed
number of iterations.
• prototypes can be ideal
reduce design risk
• it is more practical
• Screen mock-ups
• Using animation tools
• provides an understanding
of functionality
Benefits
• takes time to build
• more costly to build
• false sense of security
Risks & Drawbacks

14. In a facilitated session, you bring a larger
group (five or more) together for a common
purpose. In this case, you are trying to gather
a set of common requirements from the group
in a faster manner than if you were to
interview each of them separately.
• Less Time
• Reach Group Of People
• Brainstorming sessions
(virtual or face-to-face)
Benefits
• More Expensive
• need for extra facilities
to allow for group work
etc
• Handouts, readings
Risks & Drawbacks

15. JAD or joint application design, these
workshops can be efficient for gathering
requirements. The requirements workshops
are more organized and structured than a
brainstorming session where the involved
parties get together to document
requirements. Creation of domain model
artifacts like activity programs or static
diagrams is one of the ways to capture the
collaboration. A workshop with two analysts is
more effective than one in which on works as a
facilitator and the other scribes the work
together.
• group typically stays in the
session until the session
objectives are completed
• participants stay in session
until a complete set of
requirements
• documented and agreed to
Benefits
• takes time to build
• more costly to build
• false sense of security
Risks & Drawbacks

16. Questionnaires are much more informal, and
they are good tools to gather requirements
from stakeholders in remote locations or
those who will have only minor input into the
overall requirements. Questionnaires can also
be used when you have to gather input from
dozens, hundreds, or thousands of people.
• Less cost
• Reach Large No of Peoples
• The responses are gathered
in a standardized way
Benefits
• Difficult filling for users
• participants may forget
important issues
• Stockholders may not be
willing to answer the
questions
Risks & Drawbacks

17. When gathering information from many
people: to many to interview with time
constraints and less budget: a questionnaire
survey can be used. The survey insists the
users to choose from the given options agree /
disagree or rate something. Do not think that
you can make a survey on your own but try to
add meaningful insight in it. A well designed
survey must give qualitative guidance for
characterizing the market. It should not be
utilized for prioritizing of requirements or
features.
• Less cost
• Reach Large No of
Peoples
• A detailed critical
inspection
Benefits
• Difficult filling for users
• participants may forget
important issues
• Stockholders may not be
willing to answer the
questions
Risks & Drawbacks

19. Use cases are basically stories that describe
how discrete processes work. The stories
include people (actors) and describe how the
solution works from a user perspective. Use
cases may be easier for the users to articulate,
although the use cases may need to be
distilled later into the more specific detailed
requirements.
• provide the best return on
invested effort
• explain how that system will
be implemented
• Each use case provides a set
of scenarios that convey how
the system should interact
Benefits
• Poor identification of
structure and flow
• Time-consuming to generate
• Scenario management is
difficult
Risks & Drawbacks

21. In the field of software engineering
reusing the requirements of the
existing system is common method of
requirements elicitation. Using the
existing knowledge to develop the
new product has many advantages
that include low cost and less time.
Though each product has their own
type of stake holders and users, there
is still number of situations that the
reusing of the requirements take
places
• Reused requirements
are already validated
and analyzed thus
reducing the time of
testing
Benefits
• Some time proposed
product is completely
different form the
existing product
Risks & Drawbacks

22. If you are a vendor, you may receive
requirements through an RFP. This list
of requirements is there for you to
compare against your own capabilities to
determine how close a match you are to
the client’s needs.
The RFP presents preliminary
requirements for the commodity or
service, and may dictate to varying
degrees the exact structure and format
of the supplier's response. Effective RFPs
typically reflect the strategy and
short/long-term business objectives,
providing detailed insight upon which
suppliers will be able to offer a matching
perspective

23. Is this a last resort or starting point? When a migration project
is not having enough documentation of the current system,
reverse engineering will determine what system does? It will
not determine what the thing went wrong with the system and
what a system must do?
A critical activity for any ERP implementation is gathering
business requirements
Often we spend too much time and effort focusing on
gathering requirements that do not support key business
results and then gloss over the key business activities because
of implementation time constraints. Prioritizing business
results is an activity that we need to initiate before gather
requirements, not during fit/gap when expectations are
harder to manage and negotiate.

26. 26
Selecting Appropriate Techniques
Interview JAD Question
-naires
Documen
t Analysis
Observati
on
Type of
information
As-is,
improves,
to-be
As-is,
improves,
to-be
As-is,
improves
As-is As-is
Depth of info High High Medium Low Low
Breadth of info Low Medium High High Low
Info integration Low High Low Low Low
User
involvement
Medium High Low Low Low
Cost Medium Low-
medium
Low Low Low-
medium
As-is : understanding current system
Improves: identifies improvements
To-be: developing the new system