Elicitation Techniques

Question 1

Stakeholder Classification

Answer 1

Stakeholders can be classified according to their:
* Relevance and significance for the project success
→ Primary and secondary stakeholders (Clarkson 1995)
* Participation in the project
→ Active and passive stakeholders (Mahoney 1994)
* Ability to formulate requirements
→ If development happens for a market instead of a dedicated customer, there is no client with a user role!
* Role within the project
→ Decision-making and instruction powers
→ Type of interest

Question 2

Stakeholder Model in AMDiRE

Answer 2

In artifact-oriented engineering models, a model
of the stakeholder is the basis to identify
Objectives & Goals, which then influence the
System Vision

Question 3

Stakeholder Model: Advantages

Answer 3

Make knowledge about stakeholders explicit:
- Supertypes and subtypes
- Relation to other stakeholders
Optional:
- Function of a stakeholder (e.g. annotation)
- Priority (e.g. color, transparency, footnote)
- Availability (e.g. color, transparency, footnote)
- Possibly conflicting interests or support

Question 4

what is requirement candidate?

Answer 4

The result of the elicitation

Question 5

challenges from stakeholders to requirements

Answer 5

Challenges:
- Finding the stakeholders
- Some stakeholders are not available for discussions (e.g. legislation, competing suppliers)
- Stakeholders are not able to express their expectation:
„Well, I don‘t know what I imagined, but certainly not that!“
- Stakeholders might know what they want, but not what they need:
„I want a Ferrari to go on safaris in the jungle.”
- Hardly any separation of problem and solution:
„There should by a green button with a disk icon to save my progress, and a red X to dismiss
my changes.“

Question 6

why The requirement candidates are not suitable for development without further processing?

Answer 6

because
they are formulated from a very specific stakeholder viewpoint.

Question 7

Morphological Box (Zwicky Box)

Answer 7

List all possible configurations for every attribute of the system in a brainstorming-like manner.
Then, find combinations that are promising and feasible within the project.

Question 8

IDEO Method Cards

Answer 8

LEARN | Error Analysis:
List all things that could possibly go wrong when
using the product and determine their causes

LOOK | Fly on the Wall:
Observe and record users in their context without
interfering, to see what people actually do within the
real contexts instead of relying on their statements.

ASK | Five Whys:
Ask „Why?“ in response to five consecutive
answers.

TRY | Paper prototyping:
Sketch, layout, print / build a concept as early as
possible using paper or cardboard.

Question 9

Why use creativity techniques?

Answer 9

adv:
Foster thinking outside usual patterns:
Finding solutions that you would not otherwise
come up with

Easier identification of underlying problem and
easier separation of problem/solution

disadv:
* Learning curve
* Time consuming
Requires willingness to open up

Question 10

attributes of persona

Answer 10

A persona consists of two aspects: personal characteristics and usage scenario

motivation, hobbies, job, relationship status…

offline behavior (how user achieves the goal)
online behavior (loves to share things on social media)

Question 11

Persona: Usage Scenario

Answer 11

The scenario is a detailed narrative how the persona would use the
system. Being as concrete as possible often opens new viewpoints.

Question 12

personas: adv and disadv

Answer 12

adv:
Does not need access to actual users

disadv: Difficult to separate from your own desires
and ideas

Personas do not deliver requirements, only candidates, which then have to be consolidated!!

Question 13

Types of goals

Answer 13

Functional goals
* e.g, 98% of users should have a scooter within walking-distance.
* Can be divided into satisfaction and information goals. One agent satisfies the requirement as such, while
a second agent is responsible to inform the user

Non-functional goals
− Non-functional goals can be iteratively refined into actionable requirements
* Accuracy goals ensure that the state of the software corresponds to the object in the environment (e.g., if the
scooter app indicates a scooter is at some place, the scooter is actually there), Performance goals, Security
goals (CIA triad).
* Soft goals (no clear-cut measure) vs. hard goals (can be verified)

Question 14

GORE: Goal-oriented Requirements Engineering

Answer 14

ORE focuses on activities that precede the formulation of system-level requirements.
It aims to answer the question why a system is needed in the first place

In GORE, agents are responsible for achieving goals. Examples: humans, devices, software
A requirement is a ‘sub-goal’ that a single software agent has to fulfill.
An assumption is a goal delegated to a single agent in the environment.
Assumptions cannot be enforced by the system-to-be!

Question 15

goal refinement tree

Answer 15

provides traceability links from high-level
strategic objectives to low-level technical requirements. These trees
are the core idea behind GORE.

Question 16

Advantages of Goal Models

Answer 16

Avoid irrelevant requirements, every requirement is linked to a goal!
Justify the effort for fulfilling requirements
Achieve completeness

Question 17

Conflicting Requirements

Answer 17

Eliminate conflicting parties
Contract-based: The customer decides
Innovation: Find an innovate solution that eliminates the conflict.
Compromise
Goal-based: travers the tree from requirements to goals and negotiate the prioritization of goals
instead of requirements

Question 18

Prioritizing Goals: Kano-Model

Answer 18

Threshold Attributes: Basic functionalities that
the system must be able to provide. The customer is
disappointed if they are missing.
Performance Attributes: They increase the customer’s
satisfaction but are not absolutely necessary
Excitement Attributes: Unexpected benefits contributing to
the customer’s goal, even if not perfectly implemented.
Excitement attributes can only be implemented if the
customer’s actual goal is understood!

Question 19

Goal Question Metric (GQM)

Answer 19

Conceptual level (GOAL): A goal is defined for an object
* Operational level (QUESTION): A set of questions tries to characterize the object
of measurement (product, process, resource) with respect to a selected quality issue and to
determine its quality from the selected viewpoint.
* Quantitative level (METRIC): Observable data is associated with every question in order to
answer it in a quantitative way. Metrics can be objective or subjective.

Question 20

Measuring Goals

Answer 20

• Planning Phase
• Definition Phase
• Data Collection Phase:
• Interpretation Phase

Question 21

(Ethical) Value-based Engineering

Answer 21

Values of the society and user are most important.
These include, e.g., transparency, fairness, accountability, data protection, harmlessness.
How can we prioritize one over the other?
If conflicts arise, they have to be solved from the perspective of the users and their value principles

Question 22

0 principles for ethical software development

Answer 22

1. Assumption of responsibility for the extended system landscape
2. Honest integration of critical direct and indirect stakeholders
3. Context-sensitive, wise, and continuous observation and anticipation of system unfolding