re concepts, system & context boundaries, elicitation...

RE Concepts, System & Context Boundaries,

Elicitation, Stakeholders

Lecture 2, DAT230, Requirements EngineeringRobert Feldt, 2012-09-05

onsdag 5 september 12

• Software Engineering is more than technology

• RE in particular: human-centered => multi-disciplinary

• RE mistakes very costly

• No matter which process: Requirements still key

• Engineers focus on solutions - RE on problem domain

• Constant “battle” - never enough time/resources

• RE is more than writing requirements

• Req = need/characteristic/property of system

• Types: Functional, Quality/NFR, Dev Constraints

Basic concepts and activities

SWEBOK

http://swebok.org

SWEBOK

http://swebok.org

Purpose: Consensus definition of what SE is

and is not

SWEBOK KA1.1.1 Definition

Req = property a SW must exhibit to solve real-world problem

Reqs must be verifiable

Reqs often have other attributes like priority rating

Reqs have unique identifier for configuration control and management

throughout lifecycle

SWEBOK KA1.1.2 Product & Process Reqs

Product Req = req on software to be developed

Process Req = development constraint

SWEBOK KA1.1.3 FR & NFR

Functional Req describes functions of SW

Non-Functional Reqs constrain the solution (also called Constraints or Quality Reqs)

SWEBOK KA1.1.4 Emergent Properties

Some reqs represent Emergent Properties

EPs cannot be satisfied by single component, determined by how all components interoperate

SWEBOK KA1.1.5 Quantifiable

Reqs stated clearly, unambiguously & quantitatively

Should not rely on subjective judgment

“The software shall be reliable”

“The software should be user-friendly”

“The call center software must increase the center’s throughput by

20%”

“The call center software must increase the center’s throughput by

20%”

“The probability of a fatal error during one hour of operation should

be less than 10^-8”

SWEBOK KA1.1.6 System & Software Reqs

System = interacting combination of elements to accomplish a given objective

Elements include hardware, software, firmware, people, information, techniques, facilities, services

and other support elements

System reqs are for the system as a whole

A system with software components has software requirements

SWEBOK KA1.2.1 Process Models

Req Process is NOT discrete front-end activity

Req Process configuration manages all reqs

Req Process needs adaptation to organization and project context

Req Process includes input activities like marketing and feasability studies

SWEBOK KA1.2.2 Process Actors

Req specialist must mediate between domain of stakeholder and that of SE

User = operates the software

Customer = commisioned software or is target market

Market analysts = establish market or are proxy customers

Regulators = establish regulations sw must comply with

SW Engs job to negotiate trade-offs; not all stakeholders can be perfectly satisfied

What is Req Elicitation?

“The art of determining the needs of stakeholders”

“The process of discovering the requirements for a system by communication with

stakeholders and through the observation of them in their domain”

What are the “Other sources”?

• Stakeholders are key but also DOMAIN knowledge

• Problem/application domain

• What is the problem? Who can explain it?

• Process descriptions? Mission statements?

• History

• Previous & current systems/solutions

• Documentation, Old reqs & designs

• Competitors

• Is/are there a (partial) solution(s) out there?

• Environment

• Other systems?

• Processes to be supported? Processes that influence?

• Organizational descriptions?

What are the “Other sources”?

Limits for Elicitation work?

What is a stakeholder?

Stakeholder Identification [Sharp1999]

Baseline

System

affect

Baseline

System

Support affect

Baseline

System

Support affect

info & tasks

Baseline

System

Support affect

info & tasks

Client

Baseline

System

Support affect

info & tasks

Client

products

Baseline

System

Support affect

info & tasks

Client

products

Satellites

Baseline

System

Support affect

info & tasks

Client

products

Satellites interacts

Baseline

Users - operate the SW

Developers - develop the SW

Legislators - constrains the SW

Decision-makers - takes decisions

Baseline

Frequent users, occasional users, future & past users, users of products from sw

Baseline

Developers, Analysts, Designers, QA, Maintainers, Trainers, Project managers

Baseline

Government, Community, Trade unions, Legal representatives, Standard bodies (ISO, IEEE),

Auditors (TUV)

Baseline

Government, Community, Trade unions, Legal representatives, Standard bodies (ISO, IEEE),

Auditors (TUV)

Dev & user managers, Financial managers/controllers

1. Identify all relevant groups of baseline stakeholders

2. Identify all relevant roles within each baseline group

3. For each baseline role:

1. Who supplies information to this role? Who performs supporting tasks? => Support stakeholders

2. Who processes or inspects products from this role? => Client

3. Who interacts with this role in other ways? => Satellite

4. Repeat 3 above for newly found stakeholders

5. Consider relations between identified stakeholders: “in charge of”, “supports”, “is crucial to”, “provides info for”, ...

• Who are the stakeholders?

• Do we have access to them?

• What are their expectations and interests?

• What are their influence and role in project?

Stakeholder Analysis

Rainbow diagram

• Expectations and interests

• Personal: Work or Family focus, Job satisfaction, Org satisfaction, Improving knowledge, Sufficient appreciation, Workload/Responsibility

• Social: Peer recognition, Cover incompetence, Sponsorships, Undermining, On the move, Power hierarchies

• Material: Money, Tools, Office, Travels

re concepts, system & context boundaries, elicitation...

Documents

photo elicitation project

chap3 re elicitation

1 elicitation ii. 2 non-functional requirements knowledge...

scenario elicitation

preference elicitation

inse - lecture 4a requirements elicitation. requirements...

knowledge elicitation methods

req elicitation

requirement elicitation & techniques

requirements elicitation -...

qut digital repository: · classification to delineate...

expert elicitation - aquaclew

expert elicitation: methodological suggestions for its...

requirements elicitation & speciﬁcation -...

requirements elicitation & review -...

choosing elicitation techniques

in the beginning - challenges in requirements...

elicitation methods

l4 requirements elicitation

requirements: elicitation