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íazComputer Science Dept.

Faculty of Cooperative Studies

Berlin School of Economics and Law

[email protected]

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

http://dilbert.com/strips/comic/2006-01-29/

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

http://aka.ms/SoftwareReq3E/files


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

http://iansommerville.com/software-engineering-book/


The traditional software

development process:

Perceptions, communication patterns

and interests…

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

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

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 Requirements Engineering

Elicitation

Requirements

Engineering


Requirements

Development

Requirements

Management

All are topics of lecture:

“A Structured Approach to Requirements Analysis”



Requirements

Engineering

Requirements

Development

Requirements

Management

Elicitation Analysis Specification Validation

Topic of (this) lecture

“Requirements Engineering Techniques for Eliciting Requirements”



Requirements

Engineering

Requirements

Development

Requirements

Management

Elicitation Specification Validation

Topics of lecture

“Requirements Engineering Methods for Documenting Requirements”

Analysis



Requirements

Engineering

Requirements

Development

Requirements

Management


Also topic of lecture

“Modelling Software Requirements. Important diagrams and templates”



Requirements

Engineering

Requirements

Development

Requirements

Management


Topic of lecture

“Methods for Validating and Testing Software Requirements”


A Requirements Development

process framework



Elicitation

Requirements

Engineering


Requirements

Development

Requirements

Management



RD process framework

27

Elicitation

Analysis

Specification

Validationre-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

Requirements Development


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

CG2CG1

Coarse goals

Define

stakeholders

Define

goals

Define

requirements

DiagramsTemplates

Models

WHO

WHAT

HOW



So far…












Next topics…













34

Elicitation

Analysis

Specification




evaluating,

verifying

documenting, SRS

classifying,

representing,

deriving,

negotiating





35

Elicitation

Analysis

Specification




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

Acc. to Wiegers & BeattyE

licit

ati

on

Identifying the product’s expected user classes and

other stakeholders.

According to Wiegers & Beatty


Key actions

39


licit

ati

on


other stakeholders.

Understanding user tasks and goals and the

business objectives with which those tasks align.



Key actions

40


licit

ati

on


other stakeholders.



Learning about the environment in which the new

product will be used.



Key actions

41


licit

ati

on


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

CG2CG1

Coarse goals

Define

stakeholders

Define

goals

Define

requirements

DiagramsTemplates

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

http://dilbert.com/strip/2009-04-08/


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

engagementExpectation

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/

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

CG2CG1

Coarse goals

Define

stakeholders

Define

goals

Define

requirements

DiagramsTemplates

Models

WHO

WHAT

HOW

classifying,

representing,

deriving,

negotiating


documenting, SRS

+

+

evaluating, verifying+



Granular goals

CG3

CG2CG1

Coarse goals

Define

stakeholders

Define

goals

Define

requirements

DiagramsTemplates

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 rightstakeholders.




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


http://writing.colostate.edu/guides/page.cfm?pageid=1410&guideid=68


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

Preparefor

elicitation



Preparing for elicitation

Decide on

elicitation

scope and

agenda

Prepare

resources

Prepare

questions

and straw

man models

Preparefor

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

Preparefor

elicitation

Performelicitation

activities


Prepare

questions

and straw

man models


Performing elicitation

Performelicitation

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 notesDocument

open issues

Preparefor

elicitation

Performelicitation

activities

Follow upafter

elicitation


Decide on

elicitation

scope and

agenda

Prepare

resources

Prepare

questions

and straw

man models


Following up

Follow upafter

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 notesDocument

open issues



Decide on

elicitation

scope and

agenda

Prepare

resources

Prepare

questions

and straw

man models

Perform

elicitation

session

Organise and

share notesDocument

open issues

Preparefor

elicitation

Performelicitation

activities

Follow upafter

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

requirementsUser

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


licit

ati

on


other stakeholders.





Working with individuals who represent each user

class to understand their functionality needs and

their quality expectations.



Granular goals

CG3

CG2CG1

Coarse goals

Define

stakeholders

Define

goals

Define

requirements

DiagramsTemplates

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 notesDocument

open issues

Preparefor

elicitation

Performelicitation

activities

Follow upafter

elicitation



What comes next?



Requirements

Engineering

Requirements

Development

Requirements

Management

Elicitation Specification Validation

Topics of lecture

“Requirements Engineering Methods for Documenting Requirements”

Analysis



121

Elicitation

Analysis

Specification




evaluating,

verifying

documenting, SRS

classifying,

representing,

deriving,

negotiating





Granular goals

CG3

CG2CG1

Coarse goals

Define

stakeholders

Define

goals

Define

requirements

DiagramsTemplates

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

https://www.sophist.de/


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

https://www.sophist.de/en/information-pool/downloads/open-download-area/


Further reading

IREB - International Requirements Engineering

Board e.V.

http://www.ireb.org/en/service/downloads.html

127

http://www.ireb.org/en/home.html


Conference sites…

21st International Working Conference on

Requirements Engineering: Foundation for Software

Quality (REFSQ 2015), Essen, Germany

http://refsq.org/2015/

128

http://refsq.org/2015/


Conference sites…

23rd IEEE International Requirements Engineering

Conference (RE’15), Ottawa, Canada

http://re15.org/

129

http://re15.org/


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íazComputer Science Dept.

Faculty of Cooperative Studies

Berlin School of Economics and Law

[email protected]

Europe Week, 2nd – 6th March 2015

monettdiaz@dmonett

Requirements Engineering Techniques for Eliciting Requirements (lecture slides)

Education

Transcript of Requirements Engineering Techniques for Eliciting Requirements (lecture slides)