Chapter 3 Requirements Elicitation

SCSJ 2253: REQUIREMENTS ENGINEERING &

SOFTWARE MODELLING

Semester 2, 2014/205 Noraini Ibrahim

Chapter 1: IntroducEon & FoundaEon

Recap - DeniEon of Requirement

(1) A condition or capability needed by a problem or achieve an objective.

(2) A condition or capability that must be met or possessed by a system or system component, to satisfy a contract, standard, specification, or other formally imposed documents.

(3) A documented representation of a condition or capability as in (1) or (2).

IEEE Std. 610.12-1990

Recap Requirements Engineering

A systematic and disciplined approach to the specification and management of requirements

Recap Stakeholder

a person, group of people or an organisation who has directly or indirectly influence on the requirements

of the regarded system

Functions Requirements Are not implemented, but limit the solution space

Big influence on

system architecture

Team

Norms

Standards

R e q u i r e m e n t concerning a result of behaviour that shall be provided by a function of the system.

Requirement that pertains to a quality concern that is not covered by a functional requirement. Requirement that limits the

solution space beyond what is necessary for meeting the given functional and quality requirements.

Non-functional Requirements

Constraints (organisational, technical)

Development Process Budget Deadlines

Legislation

Guidelines

Operations

Quality Requirements

Details of Functionality (Security, Accuracy)

Reliability Usability Efficiency Maintainability Portability

Functional Requirements

Functionality (Use Cases) Business Rules Data State Error handling Interfaces

Recap Types of Requirements

RE Core Ac

Chapter 2: System & Context Boundaries

Grey zone of the system boundary not relevant

System boundary

Context Grey zone of the context

Scope within the system boundary

System

Recap Context & System

Recap System boundary & interfaces

Business process

Document (ex. Law)

System Hardware system

Software system

context System

Event System boundary

Chapter 3: Requirements ElicitaEon

Outline

1. Deni

DEFINITION OF ELICITATION

What is Requirement elicitaEon?

The art of determining the needs of stakeholders

The process of discovering the requirements

for a system by communicaEon with stakeholders and through the observaEon of

them in their domain

DeniEon of Requirements elicitaEon

The process of seeking, capturing and consolida0ng requirements from available requirements sources. May include the re-construc7on or crea7on of requirements. (Pohl and Rupp, 2011)

Synonym: Requirements discovery

REQUIREMENTS SOURCES

Sources of requirements

Stakeholders

Documents

Systems in opera

#1 Sources of requirements

People of organiza


Contain important informa


Examples: Exis

Roles for collaboraEon Stakeholder obligaEons

Introduce the requirements engineer to the applica

Roles for collaboraEon Requirements engineer obligaEons

Speaks the language of the stakeholder

Becomes thoroughly familiar with the applica

ELICITATION TECHNIQUES Working with the stakeholders

The Kano Model : Stakeholders saEsfacEon

Satisfaction very satisfied

Performance factors (Satisfiers)

Excitement factors (Delighters)

complete Coverage insufficient Basic factors

(Dissatisfiers)

Change in time

unsatisfied

Pohl & Rupp (pg.23)

The Kano Model : 1) Basic Factors


complete Coverage

insufficient Basic factors (Dissatisfiers) - Must be fulfilled by the system - Stakeholders take it for granted - Stakeholder nearly not aware anymore - never communicated (goes without saying) unsatisfied



The Kano Model : 1) Basic Factors


complete Coverage

insufficient Basic factors (Dissatisfiers)

unsatisfied



ElicitaEon techniques : ObservaEon & Document-centric

The Kano Model : 2) Performance factors


Performance factors (Satisfiers) - in focus of stakeholders - conscious and intended - explicitly communicated


complete Coverage


unsatisfied

The Kano Model : 2) Performance factors




complete Coverage


unsatisfied

ElicitaEon technique : Survey

The Kano Model : 3) Excitement factors



Excitement factors (Delighters) - unexpected for stakeholders - not yet conscious - never communicated

complete Coverage


unsatisfied

The Kano Model : 3) Excitement factors




complete Coverage


unsatisfied

ElicitaEon technique : CreaEvity-based

Human influences Organizational influences

Domain knowledge Communication skills Homogeneity of interests Group dynamics Implicit knowledge Cultural differences

Processes and structures System landscape Given Budget Availability of

Stakeholders Resources

Function-content influences Risk

factors Damage to humans & nature Contract penalty System criticality Damage to reputation

Domain (complexity) System size Norms and Standards

Required level of detail

Inuencing factors on elicitaEon technique choices

Requirements elicitaEon techniques

Numerous techniques can be employed Many types of informa


Interviews Workshops/ Brainstorm Focus groups

Observa


Interviews Ques

Survey technique - Interview

The stakeholders can be ques

Survey technique - QuesEonnaire

Form with mul


Interviews Ques

Group-based & CreaEve technique Workshop/Brainstorming

Group with moderator, 5 to 10 people Par

Group-based & CreaEve technique Focus group

A representa


Interviews Ques

Group-based & ObservaEon technique Field observaEon

Observa


Interviews Ques

Document-centric technique System interface analysis

How other systems connects to Reveals data exchange and services between systems

Strengths Independent of the stakeholders The exis

Document-centric technique User interface analysis

Synonym to system archeology Explora

Document-centric technique Document analysis

Examining any exis


Interviews Ques

Other support technique Prototyping

An ini

Types of prototyping 1. Throw-away prototyping

intended to help elicit and develop the system requirements. The requirements which should be prototyped are those which cause

most dicul

Project characterisEc Elicita

Technique Basic factor Performance factor

Excitement factor

Interviews + ++ + Ques

Summary

1. Deni

Problem solving

Based on the previous Vision and Scope document for Cafeteria Ordering System: 1. Iden

References

K. Wiegers and J. Beawy, Sohware Requirements, 3rd Edi

Chapter 3 Requirements Elicitation

Documents

Transcript of Chapter 3 Requirements Elicitation