Week 3 Elicitation Part 1

1. Requirements Elicitation (Part 1)

REQUIREMENTS
ELICITATION (PART 1)
DR. CHANDRA REKA

2. OUTLINE

IMPORTANCE OF SOFTWARE REQUIREMENT ELICITATION
PROCESS OF SOFTWARE REQUIREMENT ELICITATION
METHODS OF INVESTIGATION

3. Software requirements elicitation

“Elicitation is the drawing forth or
receiving of information from
stakeholders or other sources. It is
the main path to discovering
requirements and design
information, and might involve
talking with stakeholders directly,
researching topics, experimenting,
or simply being handed
Source: BABOK (2015)
information.”
SWE307
Also known as requirements gathering
3

4. Importance

• Stakeholder may not be able to clearly articulate
the problem
• A well defined problem and clear requirements
will go a long way to creating the correct solution
that adds value to the business project success
• Developers implement based on requirements
• Elicitation of requirements may be to:
Build new system
Re-design and re-implement an existing
system
Modify environment in which system operates
based on new market needs (enhancement)
Turning legacy system to a new system
SWE307
4

5.

6. Promobot unveils robot doppelganger with mobile arms

◦ “It took four months to develop. Each arm has eight motors.
The robot can point in the right direction and shake the other
person’s hand. The process of transferring commands to the
arm is implemented using scripts. Scripts are created using
special software in which our engineers work. There are three
modes available:
◦ (1) basic communication gestures
◦ (2) movements on command from the outside – you can ask
the robot to make a gesture such as waving and
◦ (3) on command from the development engineer. In the
future, we are going to teach the robot to write in different
languages and draw”,- says Oleg Kivokurtsev, CBDO of
Promobot.

7. Process of software requirements elicitation

• Initiated by a request from
customer/client/acquirer
• Form of request
• Request for proposal (RFP)
• Statement of Work
• Formal or informal inquiry
• Requirements Engineer ensures
requirements gathering activity is
planned well and is effective
SWE307
7

8. Process of software requirements elicitation

Prepare for
elicitation
Conduct
elicitation
Confirm
elicitation
results
Communicate business
analysis information
SWE307
Source: BABOK (2015)
8

9. Prepare for requirements elicitation

1. Understand the scope of the elicitation activity
Eg. business domain, overall corporate culture
and environment,
stakeholder locations, expected outputs etc.
2. Select elicitation techniques
Eg. Select techniques commonly or specifically
used, tasks needed to prepare, execute and complete
each technique
SWE307
3. Set up logistics
Eg. Goal, location, communication channel etc.
9

10. Prepare for requirements elicitation

4. Secure supporting materials
Eg. Identify sources of information, procure
or develop the materials and tools needed
5. Prepare stakeholders
Eg. Educate stakeholders, ensure buy-in,
review supporting material before hand,
provide agenda
SWE307
An elicitation activity plan is produced at this
stage.
10

11. Let’s Guess Understanding!

12. Checklist for requirements elicitation

Contd. to next
page
Source: Young (2004)
SWE307
12

13. Checklist for requirements elicitation

SWE307
13
Source: Young (2004)

14. Conduct elicitation

Purpose: To
draw out,
explore,
and identify
information
relevant to
the change
SWE307
14
Source: BABOK
(2015)

15. Type of requirements elicitation

Collaborative: involves direct interaction
with stakeholders, and relies on their
experiences, expertise, and judgment.
Research:
discovering
and
studying
materials or sources not directly known by
stakeholders eg. analysis of historical data
SWE307
Experiments: identifying information through
controlled test eg. observational studies,
proofs of concept, prototypes
Source: BABOK (2015)
15

16. Methods of investigation

Techniques to elicit
requirements:
1. Interviews
2. Surveys/questionn
aire
3. Observation
4. Prototype
5. Brainstorming
6. Focus Groups
7. Document
Analysis
SWE307
Techniques to elicit
requirements:
8. Interface Analysis
9. Process modeling
10.Workshop
16

17. Methods of investigation: Interviews

- Primary method of capturing requirements
from end users
- May be used to fill gaps after receiving
preliminary requirements to start software
design
- Email and phone interviews
possible if gaps are small/minimal
SWE307
17

18.

Source: Davis, A et. al(2006). Effectiveness of Requirements Elicitation Techniques:
Empirical Results Derived from Systematic Review. 14th IEEE Requirements Engineering Conference,
St Paul, Minnesota USA RE2006.

19. Methods of investigation: Interviews

SWE307
Guidelines – before the interview
i. Plan for interview
Identify resources (eg. List of individuals/group
to interview, estimate time required, who will
conduct interview)
ii. Examine preliminary information to understand
problem
Important step
Study information and identify gaps; or
Study literature available
Purpose – be familiar with jargon understand
end user responses
Source: Chemuturi (2013)

20. Methods of investigation: Interviews

Guidelines – before the interview
iii. Prepare questions to ask
Ask questions one topic at a time
Ask corollaries for completeness
Record/format questions in template
Peer review questions, if required
What to ask:
The trigger that activates the process
inputs for process
outputs/deliverable
Validations on inputs
Source: Chemuturi (2013)
SWE307
20

21. Methods of investigation: Interviews

Contd. from
previous page
Guidelines – before the interview
iii. Prepare questions to ask contd.
Open-ended questions for information
and gaps
Close-ended questions to confirm and
validate
iv. Prepare format/template to capture
information
SWE307
21

22. Methods of investigation: Interviews

Guidelines – before the interview
v. Fix appointments
To enable interviewee to be prepared
Interview can make documents/formats
available
vi. Conduct the interview
Focus on the objective of the interview
Exercise empathy and gentleness
Source: Chemuturi (2013)
SWE307
22

23. Methods of investigation: Interviews

Guidelines – during the
interview
i. Be on time
ii. Ask questions gently,
listen attentively
iii. Make
notes
while
listening (if recording,
seek
consent
from
interviewee)
iv. Draw
diagrams/flowchart to
clarify
understanding
and process steps
SWE307
v.
Do not argue or
dispute
vi. If doubtful, seek
clarification
vii. If necessary, schedule
another appointment
viii. Collect forms used
ix. Data related – ask for
max length and type
x. Do not end interview
mid way through
Contd. to next
process
pageSource: Chemuturi (2013)
23

24. Good or Bad?

25. What’s wrong ? Scenario 1

What’s Wrong ?
Scenario 1

26.

What’s Wrong ?
Scenario 2

27. Methods of investigation: Interviews

Guidelines – after the interview
i. Check for completeness of information
using checklists
ii. Organise the information collected into
requirements, information for filling in the
identified gaps and data useful for software
design such as workflows.
Note: Interviews are NOT a good
way to reach consensus
SWE307
Source: Chemuturi (2013)
27

28. Methods of investigation: Survey/Questionnaire

◦ Questionnaires are mainly used during the early stages of requirements
elicitation and may consist of open and/or closed questions.
◦ the terms, concepts, and boundaries of the domain must be well
established and understood by the participants and questionnaire
designer.
◦ Questions must be focused to avoid gathering large amounts of
redundant and irrelevant information.
◦ Generally questionnaires are considered more useful as informal
checklists to ensure fundamental elements are addressed early on, and
to establish the foundation for subsequent elicitation activities.
SWE307
28

29. Methods of investigation: Survey/Questionnaire

Strengths
• Economical
• Convenient
• Anonymous
• Quick/Efficient
• Various
stakeholders at
one time
• Massive data
SWE307
Weakness:
• Follow-up questions
may be difficult
• Poor participation
• Tedious to create
questions
• Richness of responses
depends on questions
asked
• lack the opportunity to
delve further on a
topic
29

30. break

31. Methods of investigation: Survey/Questionnaire

Surveys may be
conducted using:
• Face-to-face
• High cost
• Less responses
• May use a similar
technique to
interview
• Postal
• questionnaires are
mailed/e-mailed
to participants
SWE307
Web-based
• More
popular
and
recent method used
• Immediate
and
automatic collation of
requirements
Telephone
• Trained
interviewers
contact and gather
information
• Immediate response
• May clarify responses
31

32. Methods of investigation: Survey/Questionnaire

To create an effective survey:
• Think about the end goal of the
survey
• Who are the stakeholders
• Develop the right questions
• Types/format of questions
• When to conduct the survey
SWE307
32

33. Methods of investigation: Survey/Questionnaire

When conducting a survey:
• State the purpose
• Keep it short (KISS)
• Ask general questions and then move to specific
questions
• Use words to denote ratings (Likert scale)
• Use open-ended questions sparingly
• Allow a range of responses
• Questions should be relevant to the purpose
SWE307
33

34. Method of Investigation: Task Analysis

◦ Task analysis employs a top-down approach where high level
tasks are decomposed into subtasks and eventually detailed
sequences until all actions and events are described.
◦ It is to construct a hierarchy of the tasks performed by
the users and the system, and determine the knowledge used or
required to carry them out.
◦ provides information on the interactions of both the user and the
system with respect to the tasks as well as a contextual
description of the activities that take place.

35. Method of Investigation: Domain Analysis

◦ Examining the existing and related documentation and applications is a very useful way of gathering
early requirements as well as understanding and capturing domain knowledge, and identification of
reusable concepts and components.
◦ when the project involves the replacement or enhancement of an existing legacy system.
◦ Design documents and instruction manuals for existing systems, and hardcopy forms and files used in the
current business processes.
◦ Involve other elicitation techniques such as observing the existing system in use and interviewing the
current users.

36. TASK

◦ Compare the open ended and close ended questions and share
an example for each in MS Teams

37.

38. Reference Materials

◦ Chemuturi, M. (2013). Requirements Engineering and Management for Software Development Projects.
Springer. New York.
◦ Hull, E., Jackson, K., & Dick, J. (2011). Requirements Engineering (3rd edition). Springer. New York.
◦ Source: Davis, A et. al(2006). Effectiveness of Requirements
Elicitation Techniques: Empirical Results Derived from Systematic
Review. 14th IEEE Requirements Engineering Conference, St Paul,
Minnesota USA RE2006.
◦ ISO/IEC/IEEE. (2018). Systems and software engineering — Life cycle processes — Requirements
engineering. ISO/IEC/IEEE 29148:2018(E).
◦ Young, R. R. (2004). The Requirements Engineering Handbook. Artech House. Boston.
SWE307
38