The document discusses stakeholder analysis for requirements engineering, including identifying stakeholders based on their position, decision-making role, expertise, and objectives. It explains that stakeholder analysis is important for developing a shared understanding of the problem, ensuring requirements are complete and realistic, and facilitating cooperative learning. The document then provides an example stakeholder analysis for a bank call center software system.

1. Requirements
Engineering
Werkcollege
Spring
2012
Session
2:
Stakeholders
Christoph J. Stettina (stettina@liacs.nl)
Enrique Larios (elarios@liacs.nl)
Leiden
University.
The
university
to
discover.

2. Session
2:
Stakeholder
Analysis
IdenDfying
Stakeholders:
How?
• Relevant
posi-on
in
the
organiza-on
• Effec-ve
role
in
making
decisions
about
the
system-­‐to-­‐be
• Level
of
domain
exper-se
• Influence
in
system
acceptance
• Personal
objec-ves
and
conflicts
of
interest
(van
Lamsweerde,
2009;
p.
62)
Leiden
University.
The
university
to
discover.

3. Session
2:
Stakeholder
Analysis
Why
is
it
important?
• Essen-al
for
a
shared
problem
understanding
• Complete,
adequate
and
realis-c
requirements
• Coopera-ve
learning
(van
Lamsweerde,
2009;
p.
62)
Leiden
University.
The
university
to
discover.

4.
Exercise
1
-­‐
Stakeholder
Analysis
Bank
Call
Center
Leiden
University.
The
university
to
discover.

5. Stakeholder
Analysis:
Bank
Call
Center
Scenario:
Call
Center
-­‐
Abandoned
Call
The
call
center
manager
has
a
problem
with
unbalanced
resources
and
would
like
to
support
monitoring
and
alloca6on
of
agents
to
a
specific
hotline
via
so:ware.
An
external
IT
company
has
been
hired
to
adapt
/
write
the
so:ware
module
and
conducts
a
stakeholder
analysis.
Leiden
University.
The
university
to
discover.

6. Stakeholder
Analysis:
Roleplay
Bank
Call
Center:
Roles
• Customer
• Agent
• Supervisor
• Manager
• Helpdesk
/
IT
Department
Leiden
University.
The
university
to
discover.

7. Stakeholder
Analysis
Sun
…
Who… Stakeholders expects
What?
Participants
Expectations
Leiden
University.
The
university
to
discover.

8. Stakeholder
Analysis
-­‐
Template
INSIDE
Stakeholder
Objec-ves
Concerns
OUTSIDE
Stakeholder
Objec-ves
Concerns
Leiden
University.
The
university
to
discover.

9.
Exercise
2
–
Use
Case
Diagrams
Bank:
Call
Center
Leiden
University.
The
university
to
discover.

10. What
is
a
use
case?
“A
use
case
is
a
sequence
of
ac-ons
performed
by
an
actor”
Use
Case
Diagram:
Textual
descripDon:
Basic sequence of actions:
1. A student wants to register to a course
2. The student provides his name &
student number to the registrar
3. The registrar verifies the student's
eligibility
4. The student chooses a course from a
list of available courses
5. ....
6. ....
7. ....
Can
be:
Few
sentences,
few
paragraphs,
formal
document
Leiden
University.
The
university
to
discover.

11. What
is
a
use
case?
-­‐
Use
case
types
1.
EssenDal
Use
Case
(Business
Use
Case)
-­‐
Capture
the
essence
of
problems
-­‐
Technology
independent
view
of
behavior
req.
-­‐
High
level
of
abstrac-on
-­‐
More
flexible
and
resilient
to
changes
2.
System
Use
Case
(Concrete
Use
Case)
-­‐
A
detailed
analysis
of
behavioral
requirements
-­‐
Describing
how
the
system
works
Leiden
University.
The
university
to
discover.

12. EssenDal
in
creaDng
UC
diagrams
1.
IdenDfying
Actors
-­‐
People,
external
systems,
other
organiza-ons
-­‐
Actors
are
always
external
to
the
system
2.
IdenDfying
use
cases
-­‐
Actors'
main
tasks
(things
they
try
to
achieve)?
-­‐
Actors'
input
to
the
system?
-­‐
Actors'
needs
from
the
system
(e.g.,
informa-on)?
Leiden
University.
The
university
to
discover.

13. Example:
Course
Management
Leiden
University.
The
university
to
discover.

14. Example:
Library
System
Leiden
University.
The
university
to
discover.

15. Use
Case
Diagram:
In-­‐class
assignment
Bank
Call
Center
Roles
to
consider
• Customer,
Agent,
Call
Center
Supervisor,
CC
Manager,
Helpdesk
/
IT
Department
Use
cases
to
consider
1. Checking
Account
Balance
2. Checking
Last
Transac-ons
Leiden
University.
The
university
to
discover.

16. Use
Case
Diagram:
In-­‐class
assignment
1. Iden-fy
the
solu-on.
1. Elicit,
analyze,
nego-ate
the
requirements.
1. Make
a
use
case
diagram
to
get
an
overview
of
the
solu-on.
Leiden
University.
The
university
to
discover.

17. Bibliography
• Brooks,
F.
(1995)
Mythical
man-­‐month:
essays
on
so`ware
engineering,
20th
anniversary
edi-on.
Addison-­‐Wesley
Professional.
Gause,
D.,
and
G.
Weinberg.
1989.
Exploring
requirements,
quality
before
design.
New
York:
Dorset
House
Publishing.
• Fowler,
M.
(2004)
UML
Dis-lled:
A
Brief
Guide
to
the
Standard
Object
Modeling
Language
(3rd
ed.
ed.).
Addison-­‐
Wesley
• van
Lamsweerde,
A.
(2009)
Requirements
Engineering:
From
System
Goals
to
UML
Models
to
So`ware
Specifica-ons.
Wiley,
March
2009.
Leiden
University.
The
university
to
discover.