Gathering requirements

gngdoan 2,175 views 19 slides Jun 14, 2016
Slide 1
Slide 1 of 19
Slide 1
1
Slide 2
2
Slide 3
3
Slide 4
4
Slide 5
5
Slide 6
6
Slide 7
7
Slide 8
8
Slide 9
9
Slide 10
10
Slide 11
11
Slide 12
12
Slide 13
13
Slide 14
14
Slide 15
15
Slide 16
16
Slide 17
17
Slide 18
18
Slide 19
19

About This Presentation

Reference:
Karl Wiegers & Joy Beatty, 2013, Software Requirement, 3rd Edition


Slide Content

Gathering requirement
(Karl Wiegers and Joy Beatty, 2013, Software Requirement, 3rd Edition)
1
Presented by Doan Truong Giang, 2016

The importance of requirements
2 Source: Observation and interviewing, by Yaowaluck Promdee

User-Centred Data Gathering Techniques
Using more than one technique prevents biases in the gathered data
(researcher is with
the user while the data
is being gathered)
(researcher looks at data
previously gathered
from the user)
Interviews
Diaries/Journals
Card Sorting
Surveys
Focus Groups
Observations
Task/Activity
analysis
Data analytics
(search logs,
Google analytics, etc.)
Customer feedback reports
Help desk reports
Call Center reports
Other people’s insights
(people working at
help desks, call centers, …)
Self-Reported Observed
Indirect
Direct
Collection method
Participant Involvement 3 Source: Observation and interviewing, by Yaowaluck Promdee

Levels of requirements
Relationships among
several types of
requirements
information. Solid
arrows mean “are
stored in”; dotted
arrows mean “are the
origin of” or
“influence.
4

Working with the 3 layers
An example of how
different stakeholders
participate in
requirements
development.
5

Some types of requirements and definitions
6

Subdisciplines of software requirements engineering
7

Requirements development and requirements management
8

The business analyst bridges communication between customer and
development stakeholders.
9

Requirements development is an iterative process.
A representative
requirements
development process.
10

Knowledge, skills, and experience is to an effective business analyst.
The cyclic nature of requirements elicitation,
analysis, and specification.
11

Activities for a single requirements elicitation session.
12

Requirements elicitation techniques
1.Interviews
2.Workshops
3.Focus groups
4.Observations
5.Questionnaires
6.System interface analysis
7.User interface analysis
8.Document analysis
13

Interviews
Establish rapport
Stay in scope
Prepare questions and straw man models ahead of time
Suggest ideas
Listen actively
14

Workshops
Establish and enforce ground rules
Fill all of the team roles
Plan an agenda
Stay in scope
Use parking lots to captures items for later consideration
Timebox discussion
Keep the team small but include the right stakeholders
Keep everyone engaged
15

Prepare for elicitation
Plan session scope and agenda
Prepare resource
Learn about the stakeholders
Prepare questions
Prepare straw man models
Educate stakeholders
Take good notes
Exploit the physical space
16

Observations
A single observation of limited Multiple observations; long-term
duration (e.g., 30 minutes). duration (e.g., months, even years).
Narrow focus: Only a single Broad focus: Holistic view of the activity or
element or characteristic is observed. characteristic being observed and all of
its elements is sought.
The purpose of the The purpose of the No explanation is False explanations are
observation is fully explained observation is given to any of the given; participants are
to all involved. explained to some of participants. deceived about the
the participants. purpose of the
observation.
Full-participant Partial Onlooker;
observation participation observer is an outsider
Participants know Some but not Participants do not know
that observations are being all of the that observations are being
made and they know who is participants made or that there is
making them. know the observer. someone observing them.
Role of the Observer
How the Observer Is Portrayed to Others
How the Purpose of the Observation Is Portrayed to Others
Duration of the Observations
Focus of the Observations
17 Source: Observation and interviewing, by Yaowaluck Promdee

Classifying customer input and documenting open issues
18

19