This document discusses various techniques for requirements elicitation including interviews, brainstorming, joint application design, prototyping, use cases, observations, and surveys/questionnaires. It provides details on each technique, such as how to conduct interviews and brainstorming sessions effectively, the different roles in joint application design, and tips for creating prototypes, use cases, and surveys. The overall purpose is to elicit requirements by determining what customers and users want from existing documentation, subject matter experts, and end users.

1. REQUIREMENT
ELICITATION
APPROACHES
SHOBHIT MISHRA
CS-14
1401410076
3/3/2017 1

2. CONTENTS-
• What is “Elicitation”?
• Need Of Elicitation
• Techniques/Approaches of Requirement Elicitation
1.Analysis of existing system, background reading
2.Interviews
3.Brainstorming
4.Joint Application Design(JAD)
5.Prototyping
6.Use Cases
7.observations
8. Survey/Questionnaire-
• References
3/3/2017 2

3. Elicitation-
Ask the customer , the users ,what they want?
3/3/2017 3

4. 1.Analysis of existing system, backgroundreading-
 Elicit information from existing documentation
 Helpful when subject matter experts are not available or no longer with the
organization
 Use relevant documentation to study
and understand relevant details
 business plans, project charters,
business rules, contracts, statements
of work, memos, emails, training
materials, etc
3/3/2017 4

5. 2.Interviews-
 Ask questions geared toward uncovering information
 Formal or informal
 Directed at an individual or selected group
 Maintain focus on the goals of the interview
 Open-ended questions find information and gaps
 Closed ended questions confirm and validate
 Success depends on
 Knowledge of interviewer and interviewee(s)
 Experience of the interviewer
 Skill in documenting discussions
 Readiness of interviewee to provide information
 Relationship between the parties
 Not a good way to reach consensus (BABOK 2.0 – p.180)
3/3/2017 5

6. 3.Brainstorming-
 Produce numerous ideas
 Set a time limit
 Make it visual
 Designate a facilitator (usually the BA)
 Watch group size! (ideally 6-8)
 Establish ground rules
 criteria for evaluating and rating ideas
 do not allow criticism
 limit discussion and evaluation
 At the end, use criteria to evaluate ideas
 Can be fun, productive, and motivating
3/3/2017 6

7. 4.Joint Application Design(JAD)-
3/3/2017 7
• A more structured and intensive brainstorming approach
• Developed at IBM in the 1970s
• Lots of success stories
• "Structured brainstorming", IBM-style
• Full of structure, defined roles, forms to be filled out...
• Several activities and six (human) roles to be played
• JAD session may last few days
• The whole is more than the sum of its parts. The part is more than a fraction of
the whole.1

8. The 6 “p”s
1. Purpose - Why do we do things? (Goals, needs, motivation)
2. Participants - Who is involved? (People, roles, responsibilities)
3. Principles - How do we function? (Guidelines, working agreements,
ground rules)
4. Products - What do we create? (Deliverables, decisions, plans, next
steps)
5. Place - Where is it located? (Venue, logistics)
6. Process - When do we do what? (Activities, sequence)
3/3/2017 8

9. 5.Prototyping-
 Visually represent the user interface
 Good validation measure
 Great for interaction
 Supports visual learners
 Focus on the whole solution or just a specific area
 Great for validating requirements and uncovering gaps
 Can take lots of time if bogged down in the “hows”
instead of the “whats”
3/3/2017 9

10. 6.Use Cases-
• A use case should describe the user’s interaction with the system ...
• Not the computations the system performs
• In general, a use case should cover the full sequence of steps from
the beginning of a task until the en
• A use case should only include actions in which the actor interacts
with the computer
• Some views differ on this one!!!
3/3/2017 10

11. Example of use case diagrams-
3/3/2017 11
Customer
Bank
Make Deposit
Print Account Statement
Withdraw Cash
Identify Customer
<<include>>
<<include>><<include>>

12. 7.observations-
 Study a stakeholder's work environment
 Good when documenting current or changing processes
 Passive/Invisible
 observer does not ask questions
 takes notes
 generally stays out of the way
 Active/Visible
 dialog with the user
 while they are performing their work
 May be disruptive
 May be time consuming
 May not observe all possible
scenarios
3/3/2017 12

13. 8. Survey/Questionnaire-
 Efficiently elicit information from many people
 Have a purpose
 Appropriate audience
 Establish a timeframe
 Clear and concise questions
 Focus on business objective
 Support with follow-up interviews
 Closed ended questions
 Range of possible responses is very well understood
 Easier to analyze
 Open ended questions
 Extra detail when the range of response is not well understood
 Harder to analyze and quantify
 Use selectively
3/3/2017 13

14. References-
• Requirements Engineering A good practice guide, Ramos Rowel and
Kurts Alfeche, John Wiley and Sons, 1997
• Christel, Michael and Kyo C. Kang (September 1992). "Issues in
Requirements Elicitation". Technical Report CMU/SEI-92-TR-012. CMU
/ SEI. Retrieved January 14, 2012.
• "PMI Requirements CoP Webinar on Requirements .Quality".
• Sommerville and Sawyer, 1997.
3/3/2017 14

15. “THANK YOU!!!”
3/3/2017 15