Requirements Engineering Techniques for Eliciting Requirements (lecture slides)

D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Requirements Engineering
Techniques for Eliciting
Requirements
Prof. Dr. Dagmar Monett Díaz
Computer Science Dept.
Faculty of Cooperative Studies
Berlin School of Economics and Law
dagmar@monettdiaz.com
Europe Week, 2nd – 6th March 2015
90 Minutes

Dilbert
 Scott Adams
At http://dilbert.com/strip/1997-05-09/
(Educational/Classroom usage permission is granted by Universal Uclick. All Rights Reserved)
Sometimes it happens…
2

D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 3
Main topics

Main topics
 Where does the major content come from?
 Requirements Engineering and Requirements
Development: An Overview
 Requirements Elicitation
- Key actions in elicitation
- Who, what and how?
 Techniques for eliciting requirements. Planning
 Activities for a single elicitation session
 Some cautions and good practices
 What’s next? Further reading, sources of inspiration

Next topics…

©

Software Requirements
Karl Wiegers and Joy Beatty
3rd Edition, 672 pp.
Microsoft Press, 2013
ISBN-13: 978-0-7356-7966-5
(See more at
http://aka.ms/SoftwareReq3E/files)
7
Wiegers & Beatty

Software Engineering
Ian Sommerville
9th Edition, 792 pp.
Addison-Wesley, 2010
ISBN-13: 978-0137035151
(10th Edition: April 2015. See more at
http://iansommerville.com/software-
engineering-book/)
8
Sommerville

The traditional software
development process:
Perceptions, communication patterns
and interests…

D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 10Cartoon  http://projectcartoon.com/

Requirements and
– An Overview –

Requirement: A definition
According to Wiegers & Beatty:
“[A requirement is a] statement of a
customer need or objective, or of a condition
or capability that a product must possess to
satisfy such a need or objective. A property
that a product must have to provide value to
a stakeholder.”
See lecture “A Structured Approach to Requirements Analysis” for more on this topic!

Definition according to Wiegers & Beatty:
Requirements engineering is the subdiscipline of
systems engineering and software engineering that
encompasses all project activities associated with
understanding a product's necessary capabilities and
attributes. Includes both requirements development
and requirements management.
14

Subdisciplines of

Subdisciplines of
Requirements
Engineering
Requirements
Development
Requirements
Management
Acc. to Wiegers & Beatty

Subdisciplines of
Requirements Development
Elicitation
Requirements
Engineering
Analysis Specification Validation
Requirements
Development
Requirements
Management

Subdisciplines of
Requirements Management
Tracking
Requirements
Engineering
Managing Controlling Tracing
Requirements
Development
Requirements
Management

Topics of other related lectures

Subdisciplines of
Elicitation
Requirements
Engineering
Requirements
Development
Requirements
Management
All are topics of lecture:
“A Structured Approach to Requirements Analysis”

Subdisciplines of
Requirements
Engineering
Requirements
Development
Requirements
Management
Elicitation Analysis Specification Validation
Topic of (this) lecture
“Requirements Engineering Techniques for Eliciting Requirements”

Subdisciplines of
Requirements
Engineering
Requirements
Development
Requirements
Management
Elicitation Specification Validation
Topics of lecture
“Requirements Engineering Methods for Documenting Requirements”
Analysis

Subdisciplines of
Requirements
Engineering
Requirements
Development
Requirements
Management
Also topic of lecture
“Modelling Software Requirements. Important diagrams and templates”

Subdisciplines of
Requirements
Engineering
Requirements
Development
Requirements
Management
Topic of lecture
“Methods for Validating and Testing Software Requirements”

A Requirements Development
process framework

Subdisciplines of
Elicitation
Requirements
Engineering
Requirements
Development
Requirements
Management

RD process framework
27
Elicitation
Analysis
Specification
Validation
re-evaluate
Adapted from Wiegers & Beatty
identifying, discovering
evaluating,
verifying
documenting, SRS
classifying,
representing,
deriving,
negotiating
RD: Requirements Development
SRS: Software Requirements Specification
See lecture “A Structured Approach to Requirements Analysis” for details!

A structured approach to

A structured approach to RD
(1) Define stakeholders!
 Who is interested in the system?
 Who makes decisions?
 Who are the users, managers, developers, etc.?
In other words, WHO has influence on the software requirements?
(2) Define goals!
 Stakeholders have goals (define coarse goals!)
 These goals can be divided into more specific goals (define granular goals!)
In other words, WHAT should be implemented or achieved?
(3) Define requirements!
 Goals can be derived into concrete requirements
 How to get to the requirements? (goal-based!)
 Model those requirements using diagrams, templates, etc.
In other words, HOW will the goals be achieved?

Granular goals
CG3
CG2
CG1
Coarse goals
Define
stakeholders
Define
goals
Define
requirements
Diagrams
Templates
Models
WHO
WHAT
HOW

So far…

Next topics…

Requirements Elicitation

34
Elicitation
Analysis
Specification
Validation
re-evaluate
evaluating,
verifying
documenting, SRS
classifying,
representing,
deriving,
negotiating

35
Elicitation
Analysis
Specification
Validation
re-evaluate
evaluating,
verifying
documenting, SRS
classifying,
representing,
deriving,
negotiating

Elicitation: Definition
36
Elicitation
“[Elicitation is the] process of identifying,
discovering requirements from various sources
through interviews, workshops, focus groups,
observations, document analysis, and other
mechanisms.”

Key actions in elicitation

Key actions
38
Elicitation
Identifying the product’s expected user classes and
other stakeholders.
According to Wiegers & Beatty

Key actions
39
Elicitation
other stakeholders.
Understanding user tasks and goals and the
business objectives with which those tasks align.

Key actions
40
Elicitation
other stakeholders.
Learning about the environment in which the new
product will be used.

Key actions
41
Elicitation
other stakeholders.
Working with individuals who represent each user
class to understand their functionality needs and
their quality expectations.

WHO
– The stakeholders –

Granular goals
CG3
CG2
CG1
Coarse goals
Define
stakeholders
Define
goals
Define
requirements
Diagrams
Templates
Models
WHO
WHAT
HOW

Stakeholder: A definition
“[A stakeholder is an] individual, group, or
organization that is actively involved in a
project, is affected by its process or
outcome, or can influence its process or
outcome.”

Examples potential stakeholders
Outside the developing organisation
Developing organisation
Developing team
Project manager
Business analyst
Data modeller
Process analyst
Documentation writer
Database administrator
Hardware engineer
Quality assurance staff
Tester
Designer
Developer
Product owner
Development manager
Marketing
Company owner
Sales staff
Executive sponsor
Training staff
Manufacturing
Operational support staff
Installer
Maintainer
Usability expert
Portfolio architect
Direct user
Indirect user
Legal staff
Auditor
Consultant
Certifier
Software supplier
Venture capitalist
Beta Tester
General public
Government agency
Program manager

Dilbert
 Scott Adams
Busy stakeholders…
47

The customer

Customer: A definition
“[A customer is an] individual or
organization that derives either direct or
indirect benefit from a product. Software
customers might request, pay for, select,
specify, use, or receive the output generated
by a software product.”

Expectation gap
Time
Customer contact points
Expectation
gap without
customer
engagement

Expectation gap
Time
Customer contact points
Expectation
gap with
customer
engagement
Expectation
gap without
customer
engagement

Classifying users

Differentiating user classes
 access privilege or security level (admin/guest/...)
 tasks performed (during business operations)
 features used
 frequency of product use
 experience, expertise (application domain,
computer systems)
 platforms and devices used (desktop/laptop PC,
tablet, smartphone, etc.)
 native language
 interaction with the system (direct/indirect)
53

A possible hierarchy
54
Stakeholders
Customers
Direct and
indirect users
Favoured
user classes
Disfavoured
user classes
Ignored
user classes
Other
user classes
Other
customers
Other
stakeholders

User classes
55
Favoured
user classes
Disfavoured
user classes
Ignored
user classes
Other
user classes
Their satisfaction is most closely aligned with
achieving the project’s business objectives.
 Preferential treatment!
They are not supposed to use the product for
legal/security/safety reasons.
 Build in features to deliberative make that hard!
They will use the product, but you don’t specifically
build it to suit them.
Others other than favoured, disfavoured or ignored.

Reaching agreements
– Sign-off –

Is a consensus possible?
Image © Stuart Miles @ http://www.freedigitalphotos.net/

Reaching agreements
 Customers agree that the requirements address
their needs.
 Developers agree that they understand the
requirements and that they are feasible.
 Testers agree that the requirements are
verifiable.
 Management agrees that the requirements will
achieve their business objectives.
58
Sign-off but be open for changes! (Agile)

But not like this…

WHAT and HOW

Granular goals
CG3
CG2
CG1
Coarse goals
Define
stakeholders
Define
goals
Define
requirements
Diagrams
Templates
Models
WHO
WHAT
HOW
classifying,
representing,
deriving,
negotiating
documenting, SRS
+
+
evaluating, verifying
+

Granular goals
CG3
CG2
CG1
Coarse goals
Define
stakeholders
Define
goals
Define
requirements
Diagrams
Templates
Models
WHO
WHAT
HOW
classifying,
representing,
deriving,
negotiating
documenting, SRS
+
+
+

Product vision
and project scope

Aligning the goals…
Image © arztsamui @ http://www.freedigitalphotos.net/

Product vision
 It is what the product is about and what it
ultimately could become.
 Usually stable
“[The product vision is a] statement that
describes the strategic concept or the ultimate
purpose and form of a new system [and that]
will achieve the business objectives.”

Project scope
 It draws the boundary between what's in and
what's out for a project.
 Usually variable
“[The project scope is the] portion of the
ultimate product vision that the current project
will address.”

So far…

Next topics…

Techniques for eliciting
requirements

Dilbert
 Scott Adams
Gathering requirements…
70

Interviews
71
 Asking users: most obvious way to
find out what they need!
 Mechanism to get direct user
involvement.
 Appropriate for eliciting business
requirements from “busy”
executives.
 Questions should be carefully
prepared in advance.
Image © Ambro @ http://www.freedigitalphotos.net/

Interviews: Useful tips
72
 Establish rapport: introduce yourself,
review the agenda, remind session
objectives, address preliminary concerns.
 Stay in scope: keep discussion focused.
 Prepare questions and straw man models
ahead of time.
 Suggest ideas and alternatives creatively.
 Listen actively: active listening and
paraphrasing.

Workshops
73
 Meeting with multiple stakeholders and formal
roles.
 Several types of stakeholders participate.
 Encourage stakeholder collaboration in defining
requirements concurrently.
 Facilitator plays critical role.
 A scribe assists by capturing
points.
 Can be resource intensive.
Image © stockimages @ http://www.freedigitalphotos.net/

Workshops: Useful tips
74
 Establish and enforce ground rules: Starting/ending on time,
silencing electronic devices, one conversation at a time, etc.
 Fill all of the team roles: Facilitator, note taking, time keeping,
scope management, ground rule management, scribe.
 Stay in scope: Refer to business requirements, keep focused.
 Use parking lots for items for later consideration.
 Plan agenda ahead of time.
 Timebox discussions.
 Keep everyone engaged.
 Team small but with the right
stakeholders.

Focus groups
75
 Representative group of users.
 Must be interactive: chance for all users to voice
their thoughts.
 Useful for exploring users’ attitudes, impressions,
preferences and needs.
 Must be facilitated.
 Subjective feedback that can
be further evaluated.

Observations
76
 Observing exactly how users perform their tasks.
 Time consuming; time should be limited.
 Multiple user classes and important or high-risk
tasks should be selected.
 Can be silent (busy users cannot be interrupted) or
interactive (asking questions allowed).
 Observed information should be
documented for further analysis.

Questionnaires
77
Image © Jeroen van Oostrom @ http://www.freedigitalphotos.net/
 Way to survey large groups of users to understand
their needs.
 Inexpensive, geographically independent.
 Also used for feedback about products.
 Biggest challenge: preparing
well-written questions!
 Analysed results can be used
as input to other elicitation
techniques.

Questionnaires: Useful tips
78
Image © Jeroen van Oostrom @ http://www.freedigitalphotos.net/
 See “Creating Questionnaire Questions” from
the Colorado State University for useful tips!
http://writing.colostate.edu/guides/page.cfm?pageid=1410&guideid=68
 Important issues:
- Open-ended vs. closed-ended
- Format
- Wording
- Content
- Order of questions

Document analysis
79
 Examining existing documentation for potential
software requirements.
 Past documentation can reveal functionality that
might need to be retained.
 Reduces the elicitation meeting time needed.
 Can reveal information people
“don’t tell”.
 Risk: documents up to date?
Image © nuttakit @ http://www.freedigitalphotos.net/

System interface analysis
80
 Examining the systems to which your system
connects.
 It reveals functional requirements regarding data
and services exchange between systems.
 Identifying functionalities that may lead to
requirements.
Image © nuttakit @ http://www.freedigitalphotos.net/

User interface analysis
81
 Studying existing systems to discover user and
functional requirements.
 Uses screen shots if no direct interaction possible.
 Helps learning common steps by navigating
existing user interfaces.
 Helps understanding how an
existing system works.

Active learning exercise
Image © renjith krishnan at http://www.freedigitalphotos.net/

Quiz
83
In the elicitation process for a new product version, you
receive from the customer the user’s guides and the
reference manuals of all products developed by her
company in the past. Which eliciting technique would be
more appropriate to start with?
(A) Observation.
(B) Interviews.
(C) Document analysis.
(D) Workshops.

Planning elicitation

Elicitation plan
85
Elicitation
plan
Elicitation objectives
Elicitation strategy and planned techniques
Schedule and resource estimates
Documents and systems needed
Expected products of elicitation efforts
Elicitation risks

So far…

Next topics…

Activities for a single
requirements elicitation session

Elicitation activities
Decide on
elicitation
scope and
agenda
Prepare
resources
Prepare
questions
and straw
man models
Prepare
for
elicitation

Preparing for elicitation
Decide on
elicitation
scope and
agenda
Prepare
resources
Prepare
questions
and straw
man models
Prepare
for
elicitation
 Plan session scope and agenda (available time?).
 Prepare resources(room, tech, participants,
documentation).
 Learn about the stakeholders (relevant ones?).
 Prepare questions (“What do you need to do?”, “Why?”,
“What happens when…?”, etc.).
 Prepare straw man models (drafts of analysis models).

Decide on
elicitation
scope and
agenda
Prepare
resources
Perform
elicitation
session
Prepare
for
elicitation
Perform
elicitation
activities
Prepare
questions
and straw
man models

Performing elicitation
Perform
elicitation
activities
 Educate stakeholders, teach them about your elicitation
approach.
 Take good notes with help if necessary (attendees,
decisions made, actions to be taken, responsibilities,
outstanding issues, key discussions).
 Prepare questions ahead to keep conversation going.
 Exploit the physical space e.g. to draw diagrams.
Perform
elicitation
session

Perform
elicitation
session
Organise and
share notes
Document
open issues
Prepare
for
elicitation
Perform
elicitation
activities
Follow up
after
elicitation
Decide on
elicitation
scope and
agenda
Prepare
resources
Prepare
questions
and straw
man models

Following up
Follow up
after
elicitation
 Organise and share the notes.
 Consolidate the input from multiple sources.
 Share and ask for review.
 Document open issues to be further explored.
Organise and
share notes
Document
open issues

Decide on
elicitation
scope and
agenda
Prepare
resources
Prepare
questions
and straw
man models
Perform
elicitation
session
Organise and
share notes
Document
open issues
Prepare
for
elicitation
Perform
elicitation
activities
Follow up
after
elicitation

Quiz
97
Which is a right sequence of activities in a single
requirements elicitation session?
(A) Decide on scope, prepare questions, perform
elicitation, document open issues.
(B) Prepare questions, decide on agenda, perform
elicitation, prepare models.
(C) Share notes, perform elicitation, prepare resources,
document open issues.
(D) Decide on agenda, organise notes, prepare
questions, perform elicitation.

Classifying customer input

Organise categories
Business
requirements
User
requirements
Business
rules
Functional
requirements
Quality
attributes
External
Interface
requirements
Constraints
Data
requirements
Solution
ideas

How do you know you are done?

Dilbert
 Scott Adams
When done?
101

When done?
 No more use cases or user stories.
 New scenarios, but no new functional
requirements.
 Repetition of issues already covered.
 Out of scope new features, user requirements, or
functional requirements.
 New requirements are all low priority.
 New capabilities “nice to have some time in the
future” rather than “in the specific product we’re
talking about right now.”
 Few questions from developers and testers who
review the requirements.
102

So far…

Next topics…

Some cautions about elicitation

Some cautions
 Balance stakeholder representation: few product
champions by representative user classes.
 Define scope appropriately: modify product vision
and project scope if necessary.
 Avoid the “requirements vs. design” argument:
Focus on the ‘what’, but also on the ‘how’.
 Research within reason: Prototyping in case new
issues? Incremental development for exploring?
106

Good practices:
Requirements elicitation

Good practices (i)
 Define product vision and project scope.
 Identify user classes and their characteristics.
 Select a product champion for each user class.
 Conduct focus groups with typical users.
 Work with user representatives to identify user
requirements.
 Identify system events and responses.
 Hold elicitation interviews.
 Hold facilitated elicitation workshops.
108

Good practices (ii)
 Observe users performing their jobs.
 Distribute questionnaires.
 Perform document analysis.
 Examine problem reports of current systems for
requirement ideas.
 Reuse existing requirements.
109

So far…

The content so far

Next topics…

To take away…

Key actions
115
Elicitation
other stakeholders.
Working with individuals who represent each user
class to understand their functionality needs and
their quality expectations.

Granular goals
CG3
CG2
CG1
Coarse goals
Define
stakeholders
Define
goals
Define
requirements
Diagrams
Templates
Models
WHO
WHAT
HOW
classifying,
representing,
deriving,
negotiating
documenting, SRS
+
+
+

Decide on
elicitation
scope and
agenda
Prepare
resources
Prepare
questions
and straw
man models
Perform
elicitation
session
Organise and
share notes
Document
open issues
Prepare
for
elicitation
Perform
elicitation
activities
Follow up
after
elicitation

What comes next?

Subdisciplines of
Requirements
Engineering
Requirements
Development
Requirements
Management
Elicitation Specification Validation
Topics of lecture
“Requirements Engineering Methods for Documenting Requirements”
Analysis

121
Elicitation
Analysis
Specification
Validation
re-evaluate
evaluating,
verifying
documenting, SRS
classifying,
representing,
deriving,
negotiating

Granular goals
CG3
CG2
CG1
Coarse goals
Define
stakeholders
Define
goals
Define
requirements
Diagrams
Templates
Models
WHO
WHAT
HOW
classifying,
representing,
deriving,
negotiating
documenting, SRS
+
+
+

Other references

Requirements-Engineering
und -Management: Aus der
Praxis von klassisch bis agil
Chris Rupp & die SOPHISTen
6th Edition, 570 pp.
Carl Hanser Verlag München, 2014
ISBN-13: 978-3-446-43893-4
In German
(Chapters and related topics in English are
available for free at https://www.sophist.de/)
124
Rupp & The SOPHISTs

Other books
125

Further reading
 Ch. Rupp, R. Joppich, Ch. Wünch (2010): “Molecular
Requirements Engineering: The Blueprint of a Perfect
Requirement”.
 Ch. Rupp (2010): “In medias RE”.
 Ch. Rupp, E. Wolf (2011): “The SOPHIST Set of
REgulations”.
 Ch. Rupp, R. Joppich (2010): “Templates – Construction
Plans for Requirements and for More”.
All available at https://www.sophist.de/en/information-
pool/downloads/open-download-area/
126

Further reading
 IREB - International Requirements Engineering
Board e.V.
http://www.ireb.org/en/service/downloads.html
127

Conference sites…
 21st International Working Conference on
Requirements Engineering: Foundation for Software
Quality (REFSQ 2015), Essen, Germany
http://refsq.org/2015/
128

Conference sites…
 23rd IEEE International Requirements Engineering
Conference (RE’15), Ottawa, Canada
http://re15.org/
129

Homework:
“Reflect on the topics that were
covered so far and write down
your own notes and conclusions!”

The traditional software
development process:
and interests…

The ideal, perfect, still possible
software development process:
and interests…

D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 134Adapted from cartoon  http://projectcartoon.com/

Done!

Techniques for Eliciting
Requirements
Prof. Dr. Dagmar Monett Díaz
Computer Science Dept.
Faculty of Cooperative Studies
Berlin School of Economics and Law
dagmar@monettdiaz.com
Europe Week, 2nd – 6th March 2015
monettdiaz@dmonett

Requirements Engineering Techniques for Eliciting Requirements (lecture slides)

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Requirements Engineering Techniques for Eliciting Requirements (lecture slides)

Ähnlich wie Requirements Engineering Techniques for Eliciting Requirements (lecture slides) (20)

Mehr von Dagmar Monett

Mehr von Dagmar Monett (18)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Requirements Engineering Techniques for Eliciting Requirements (lecture slides)