Elicitation Techniques Flashcards
Stakeholder Classification
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
Stakeholder Model in AMDiRE
In artifact-oriented engineering models, a model
of the stakeholder is the basis to identify
Objectives & Goals, which then influence the
System Vision
Stakeholder Model: Advantages
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
what is requirement candidate?
The result of the elicitation
challenges from stakeholders to requirements
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.“
why The requirement candidates are not suitable for development without further processing?
because
they are formulated from a very specific stakeholder viewpoint.
Morphological Box (Zwicky Box)
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.
IDEO Method Cards
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.
Why use creativity techniques?
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
attributes of persona
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)
Persona: Usage Scenario
The scenario is a detailed narrative how the persona would use the
system. Being as concrete as possible often opens new viewpoints.
personas: adv and disadv
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!!
Types of goals
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)
GORE: Goal-oriented Requirements Engineering
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!
goal refinement tree
provides traceability links from high-level
strategic objectives to low-level technical requirements. These trees
are the core idea behind GORE.
Advantages of Goal Models
Avoid irrelevant requirements, every requirement is linked to a goal!
Justify the effort for fulfilling requirements
Achieve completeness
Conflicting Requirements
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
Prioritizing Goals: Kano-Model
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!
Goal Question Metric (GQM)
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.
Measuring Goals
- Planning Phase
- Definition Phase
- Data Collection Phase:
- Interpretation Phase
(Ethical) Value-based Engineering
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
0 principles for ethical software development
- Assumption of responsibility for the extended system landscape
- Honest integration of critical direct and indirect stakeholders
- Context-sensitive, wise, and continuous observation and anticipation of system unfolding
