1 of 48

STAKEHOLDERS�(+ ELICITATION, PART 1)

Who do we need to consider?

How do we figure out what the SW should do?

Lecture 5

2 of 48

Announcements

  • If you don’t have a team, contact your TA ASAP
  • Homework 1 due Thursday 11:59pm
  • Homework 1 peer eval (optional) closes Friday 11:59pm
  • Team Bonding due Monday 11:59pm
  • Tuesday 4/23 lecture replaced by Zoom elicitation sessions
    • Find the Zoom (linked from Canvas) associated with your discussion time
  • Thursday 4/25 is EXAM #1
    • Covers weeks 1-3 lectures

Text questions to (562) 684-8307

2

3 of 48

Canvas Quiz

​

​

​

Lecture 5: Lecture 4 Review

Text questions to (562) 684-8307

3

4 of 48

Last Time – How do we gain an initial understanding of what we are developing and why?

  • Understanding the goals of a system/organization answers the question: “why are we building this?”
  • Understanding the context/scope of a system answers the question: “what are we building?”
  • Both goals and scope are used to ensure the product meets its intended purpose and keep requirements changes/additions appropriately controlled

Text questions to (562) 684-8307

4

5 of 48

​

Who do we need to consider?

Text questions to (562) 684-8307

5

6 of 48

​

What is important to them?

Text questions to (562) 684-8307

6

7 of 48

Today’s Lecture – Who do we need to consider?

  • What is a stakeholder?
  • Identifying stakeholders
  • Classifying stakeholders
  • Analyzing stakeholders
  • Requirements negotiation

Text questions to (562) 684-8307

7

8 of 48

Today’s Lecture – Who do we need to consider?

  • What is a stakeholder?
  • Identifying stakeholders
  • Classifying stakeholders
  • Analyzing stakeholders
  • Requirements negotiation

​

​

Text questions to (562) 684-8307

8

9 of 48

Stakeholders

DEFINITION. Stakeholder – A person or organization who influences a system’s requirements and/or is impacted by that system.

​

  • Basic types of stakeholders:
    • System engineers
    • System end-users
    • Managers of system end-users
    • External regulators
    • Domain experts
    • Developers
    • … many more

Text questions to (562) 684-8307

9

Source Kotonya and Sommerville, 1998

10 of 48

Stakeholders make requirements messy!

  • Personality, status, personal goals, technical expertise, background, political influence
  • Different viewpoints
  • Tacit knowledge, hidden needs
  • Hard to access
  • Change their minds

10

Sources: Kotonya and Sommerville, 1998

B. Boehm and R. Turner, Balancing Agility and Discipline: A Guide forthe Perplexed, Addison-Wesley, 2003.

11 of 48

Today’s Lecture – Who do we need to consider?

  • What is a stakeholder?
  • Identifying stakeholders
  • Classifying stakeholders
  • Analyzing stakeholders
  • Requirements negotiation

​

​

Text questions to (562) 684-8307

11

12 of 48

Identifying Stakeholders: Approaches

  • Reference list (framework for stakeholder model)
  • Business/operational context
  • Goals

Text questions to (562) 684-8307

12

It is important to identify all stakeholders as early as possible!

13 of 48

Today’s Lecture – Who do we need to consider?

  • What is a stakeholder?
  • Identifying stakeholders
  • Classifying stakeholders
  • Analyzing stakeholders
  • Requirements negotiation

​

​

Text questions to (562) 684-8307

13

14 of 48

Classifying Stakeholders: Roles

  • Software development staff
  • Owners
  • Partners
  • Suppliers
  • Department heads, managers
  • Regulatory bodies, legislative representatives
  • Customers (customers of your customer)
  • Competitors
  • Users
  • Society (as a whole, or certain people groups)
  • Environment

Text questions to (562) 684-8307

14

15 of 48

Classifying Stakeholders: Functions

  • Decision makers
  • Information providers
  • Regulators
  • Sofware developers
  • End users
  • Post-implementation support

Text questions to (562) 684-8307

15

16 of 48

Classifying Users

Group users into distinct user classes based on differences such as:

  • Access privilege/security level
  • Tasks performed
  • Features used
  • Frequency of use
  • Application domain experience
  • Technical expertise
  • Platforms used

Text questions to (562) 684-8307

16

17 of 48

Example: Banking Software

  • User classes:
    • Tellers
    • Business banker
    • Loan officer
    • Branch manager
  • Some user classes can be considered “more important” than others
  • There can be overlap between the needs of different user classes

Text questions to (562) 684-8307

17

18 of 48

Stakeholder Brainstorming

  • Go to www.menti.com and enter code

Text questions to (562) 684-8307

18

19 of 48

Today’s Lecture – Who do we need to consider?

  • What is a stakeholder?
  • Identifying stakeholders
  • Classifying stakeholders
  • Analyzing stakeholders
  • Requirements negotiation

​

​

Text questions to (562) 684-8307

19

20 of 48

Stakeholder Analysis

  • Developing stakeholder model and/or matrix
    • For each stakeholder, identify:
      • Motivation
      • Authority
      • Relation to other stakeholders
      • Level of expertise
      • Their expectations
      • Your expectations of them
      • Location/availability
      • Priority (critical, major, minor)
  • These models serve as the basis for
    • Requirements elicitation
    • Other RE work products

​

Text questions to (562) 684-8307

20

Simple stakeholder analysis template

21 of 48

Types of Stakeholder Models

  • Textual
  • Informal diagram
  • Onion model
  • Rich picture

​

Text questions to (562) 684-8307

21

22 of 48

Onion Stakeholder Model

Usually 4 or 5 layers – from the center out these layers represent:

  1. Product or Solution
  2. System �(Business System)
  3. Containing System�(the Business)
  4. Wider Environment
  5. Outer layer for stakeholders who do not map to other layers

22

23 of 48

Rich Picture Stakeholder Model

23

24 of 48

Rich Picture Stakeholder Model

24

25 of 48

Rich Picture Stakeholder Model

25

26 of 48

Rich Picture Stakeholder Model

26

27 of 48

Creating a rich picture

  • Create a ”graph” in which:
    • Nodes are stakeholders
    • Edges are relationships between stakeholders
    • Primary concern(s) of each stakeholder is shown as a thought/speech bubble near the stakeholder

27

Text questions to (562) 684-8307

28 of 48

Canvas Quiz

​

​

​

Lecture 5: Stakeholder Analysis

Text questions to (562) 684-8307

28

29 of 48

Today’s Lecture – Who do we need to consider?

  • What is a stakeholder?
  • Identifying stakeholders
  • Classifying stakeholders
  • Analyzing stakeholders
  • Requirements negotiation

​

​

Text questions to (562) 684-8307

29

30 of 48

Requirements negotiation

Stakeholders may have conflicting requirements.

  • Negotiation of requirements needed

​

  • Requirements negotiation implies:
    • Identification of conflicts
    • Conflict analysis
    • Conflict resolution
    • Documentation of resolution
  • Requirements negotiation can happen
    • While eliciting requirements
    • When validating requirements

Text questions to (562) 684-8307

30

31 of 48

Example: Conflicting Goals

31

The Kiosk Developers

  • Generate revenue by leasing or selling the kiosk to the retailer
  • Sell consumables to customers through the kiosk
  • Attract retailers to the brand
  • Make a wide variety of products or services available

The Retailer

  • Maximize revenue from the available floor space
  • Attract new customers to the store
  • Increase sales to existing customers
  • Increase profit margins
  • Little kiosk maintenance required

The Customer

  • Broad selection of products or services available
  • Find desired products quickly
  • Spend less time purchasing
  • Easy-to-understand purchasing process

32 of 48

Summary – Who do we need to consider?

  • Stakeholders influence, are affected by, and have an interest in the system-to-be
  • Identifying, classifying, and analyzing them is a central activity to requirement engineering
  • Stakeholders may have conflicting requirements
    • Negotiation needed

Text questions to (562) 684-8307

32

33 of 48

Homework 2 – Stakeholder Model

Text questions to (562) 684-8307

33

34 of 48

Elicitation

34

35 of 48

​

​

How do we figure out what the software should do?

Text questions to (562) 684-8307

35

36 of 48

Encounter with a “Customer”

  • Your partner/roommate/friend asks you to go to the store and pick up the following items because they want to make a cake:
    • 5 pounds flour
    • 12 large eggs
    • 5 pounds sugar
    • 1 pound butter

Text questions to (562) 684-8307

36

37 of 48

37

?

38 of 48

Requirements Engineering Parallels

  • You need to understand the application domain
  • Customers don’t always know what they want
  • Never make assumptions about what customers want
  • Providing customers with even more than they ask for can sometimes be the wrong thing to do
  • Customers can be trouble!

Text questions to (562) 684-8307

38

39 of 48

Today’s Lecture – How do we figure out what the SW should do?

  • Information sources
  • Elicitation practices
  • Analyzing and documenting
  • Eliciting innovative requirements

Text questions to (562) 684-8307

39

40 of 48

What to do

The prerequisites

  • Knowing and tapping the information sources
  • Knowing the goals
  • Considering the context

​

The tasks

  • Elicit, analyze and document requirements
  • Negotiate
  • Validate (Lecture 14)

Text questions to (562) 684-8307

40

41 of 48

Today’s Lecture – How do we figure out what the SW should do?

  • Information sources
  • Elicitation practices
  • Analyzing and documenting
  • Eliciting innovative requirements

Text questions to (562) 684-8307

41

42 of 48

Information sources

Main sources

  • Stakeholders (Lecture 5)
  • Documents
  • Existing systems

​

Requirements are also influenced by

  • Context (Lecture 4)
  • Goals (Lecture 4)
  • Observations

Text questions to (562) 684-8307

42

43 of 48

Documents as sources for requirements

Documents can be a rich source for requirements

  • Artifacts produced or consumed in business processes
  • Process or procedure descriptions
  • Regulatory documents
  • Company guidelines
  • ...

​

  • Provides basics for getting prepared before meeting stakeholders
    • prerequisite to other techniques

Text questions to (562) 684-8307

43

44 of 48

Existing systems as sources for requirements

  • Renewing/renovating legacy systems
  • Copying/mimicking successful parts of an existing system
  • Developing a new product that shall beat an existing product of a competitor
  • Existing legacy systems can also be a source of negative requirements: what stakeholders do not want

Text questions to (562) 684-8307

44

45 of 48

Context analysis

  • Determine the system’s context and the context boundary
  • Identify context constraints
    • Physical, legal, cultural, environmental
    • Embedding, interfaces
  • Determine the system scope

Text questions to (562) 684-8307

45

46 of 48

The role of (informal) observations

When interacting with stakeholders, keep an eye on informal observations, such as

  • Stakeholder behavior
  • Conflicts and power relationships between stakeholders
  • Coffee break chats�
  • Can be a source for requirements and also helps when negotiating requirements conflicts

Text questions to (562) 684-8307

46

47 of 48

Summary – How do we figure out what the SW should do?

  • Requirements come from stakeholders, documents, existing systems, context, goals, and observations

Text questions to (562) 684-8307

47

48 of 48

For Next Time

  • Complete Lecture 6 Pre-Work: More Case Study Questions

48