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

Recap Types of Requirements

Functions

Requirements

Functional
Requirements
Functionality (Use
Cases)

Business Rules
Data
State
Error handling
Interfaces

R e q u i r e
concerning a
behaviour that
provided by a
of the system.

m e n t
result of
shall be
function

Big
influence on
system
architecture

Quality
Requirements
Details of Functionality
(Security, Accuracy)

Reliability
Usability
Efficiency
Maintainability
Portability

Requirement that pertains

to a quality concern that is
not covered by a functional
requirement.

Are not implemented, but

limit the solution space

Constraints
(organisational, technical)
Development Process
Budget
Deadlines
Team
Legislation
Norms
Guidelines
Standards
Operations

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

Non-functional Requirements

ElicitaEon

Management

RE Core
Ac<vi<es

ValidaEon &
NegoEaEon

DocumentaEon

Chapter 2:
System & Context Boundaries

Recap Context & System

Grey zone of the system
boundary

not relevant

System boundary

System
Context

Grey zone of the context

Scope

within the system boundary

Recap System boundary & interfaces

Business process

Document
(ex. Law)

System
Hardware
system

Event

Software
system

System context
System boundary

Chapter 3:
Requirements ElicitaEon

Outline
1. Deni<on of requirement elicita<on
2. Types of requirements sources
3. Requirement elicita<on techniques
Survey-based
Group-based
Observa<on
Crea<vity
Document centric

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<on

#1 Sources of requirements

Stakeholders

People of organiza<ons that

inuence (direct or indirectly) the
requirements of a system
Examples:
User, employer, client, manager
Operator, developer, architect,
tester

#2 Sources of requirements

Documents

Contain important informa<on

that can provide requirements
Examples:
Universal documents : laws, norms,
standards
Domain-or-organiza<on- specic
documents : concepts, professional
ar<cles, printed papers, incidents/
error reports of legacy systems

#3 Sources of requirements

Systems in
opera<on

Examples:
Exis<ng or legacy systems
External system
Compe<tor systems

Give the stakeholders a chance to

try out the systems, so:
Gain impression of the current system
Request for extensions or changes

Roles for collaboraEon Stakeholder obligaEons

Introduce the requirements engineer to the applica<on domain
Supplies the requirements
Make <mely decisions
Respects the es<ma<on of costs and feasibility
Priori<ze the requirements
Checks the documented requirements
Communicates immediately the changes in requirements
Complies with the agreed procedure for changes
Respects the agreed RE procedure

Roles for collaboraEon Requirements engineer obligaEons

Speaks the language of the stakeholder
Becomes thoroughly familiar with the applica<on domain
Creates a requirement document
Able to make the document understandable
Maintains a respec^ul rela<onship with any stakeholder
Presents ideas and alterna<ves
Ensures that the system sa<ses the demands of the stakeholders

Working with the stakeholders

ELICITATION TECHNIQUES

The Kano Model : Stakeholders saEsfacEon

Pohl & Rupp (pg.23)
Satisfaction

Excitement factors
(Delighters)
very satisfied
Performance factors
(Satisfiers)

complete
insufficient

Coverage

Basic factors
(Dissatisfiers)
Change in time

unsatisfied

The Kano Model : 1) Basic Factors

Satisfaction

Excitement factors
(Delighters)
very satisfied
Performance factors
(Satisfiers)

complete

Coverage

insufficient

Basic factors
(Dissatisfiers)
- Must be fulfilled by the system

unsatisfied

- Stakeholders take it for granted

- Stakeholder nearly not aware anymore
- never communicated (goes without
saying)

The Kano Model : 1) Basic Factors

Satisfaction

Excitement factors
(Delighters)
very satisfied
Performance factors
(Satisfiers)

complete

Coverage

insufficient

Basic factors
(Dissatisfiers)

unsatisfied

ElicitaEon
techniques :
ObservaEon &
Document-centric

The Kano Model : 2) Performance factors

Satisfaction
very satisfied

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

Coverage

insufficient

Basic factors
(Dissatisfiers)

unsatisfied

The Kano Model : 2) Performance factors

Satisfaction
very satisfied

Excitement factors
(Delighters)
Performance factors
(Satisfiers)

ElicitaEon technique :
Survey
complete

Coverage

insufficient

Basic factors
(Dissatisfiers)

unsatisfied

The Kano Model : 3) Excitement factors

Satisfaction
very satisfied

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

Performance factors
(Satisfiers)
complete

Coverage

insufficient

Basic factors
(Dissatisfiers)

unsatisfied

The Kano Model : 3) Excitement factors

Satisfaction
very satisfied

Excitement factors
(Delighters)

ElicitaEon technique :
CreaEvity-based
Performance factors
(Satisfiers)
complete

Coverage

insufficient

Basic factors
(Dissatisfiers)

unsatisfied

Inuencing factors on elicitaEon technique choices

Human influences

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

Function-content influences
Domain (complexity)
System size
Norms and Standards

Required level of detail

Organizational influences

Processes and structures

System landscape
Given Budget
Availability of
Stakeholders
Resources

Risk factors

Damage to humans & nature

Contract penalty
System criticality
Damage to reputation

Requirements elicitaEon techniques

Numerous techniques can be employed
Many types of informa<on to be discovered
Dierent stakeholders, dierent approaches
Dierent techniques, dierent explora<ons and outcomes

Including:
1. facilitated ac<vi<es: interact directly with stakeholders,
discover business & user requirements
2. independent ac<vi<es : work on your own, reveal needed
func<onality that the stakeholder might not aware of.

Most projects use combina<on of both facilitated &

independent ac<vi<es

Requirements elicitaEon techniques

Interviews

Workshops/
Brainstorm

Focus groups

Observa<ons

Ques<onnaires

System interface
analysis

User interface
analysis

Document analysis

Prototypes

Requirements elicitaEon techniques

Facilitated
ac<vi<es :
Survey-based

Interviews

Ques<onnaires

Workshops/
Brainstorm

Focus groups

Observa<ons

System
interface
analysis

User interface
analysis

Document
analysis

Prototypes

Survey technique - Interview

The stakeholders can be ques<oned directly
Use a prepared list of ques<ons
Note and/or record the answers

Strengths
Raise opinions and new issues immediately
Ideal to nd out performance factors (Kano)

Weakness
Depends on moderators experience & skills
Time-consuming

Survey technique - QuesEonnaire

Form with mul<ple choice and/or open ques<ons
In document distribu<on or online

Strengths
A lot of informa<on in short <me with low costs
Reaches a large and distributed target audience
Dicult to rephrase obtained feedbacks from
stakeholders

Weakness
Ask about known topics only
Dicult to develop good ques<onnaires
Further enquiry ohen not possible

Requirements elicitaEon techniques

Interviews

Ques<onnaires

Workshops/
Brainstorm

Focus groups

Observa<ons

System
interface
analysis

User interface
analysis

Document
analysis

Prototypes

Facilitated
ac<vi<es:
Group-based

Group-based & CreaEve technique Workshop/

Brainstorming
Group with moderator, 5 to 10 people
Par<cipa<on from all relevant stakeholders and roles
(facilitator, scriber, mul<ple users, developers, testers)

Strengths
Generate many new ideas in a short <me
Par<cipants inspired to each other

Weakness
Inuence of dominant par<cipants, dicult group
dynamics
Not applicable to elicit detailed requirements (basic factor-
Kano)

Group-based & CreaEve technique Focus group

A representa<ve group of users
Generate input and ideas on products func<onal and
quality requirements

Strengths
Useful for exploring users aitudes, impressions,
preferences and needs
Valuable for commercial products development with no
access to the end users in the company

Weakness
Wrong selec<on for par<cipants will lead to insucient
turnaround
Par<cipants normally do-not have decision-making
authority for requirements

Requirements elicitaEon techniques

Interviews

Workshops/
Brainstorm
System
interface
analysis

Ques<onnaires

Crea<vity approach
Interac<ve @ silent

Focus groups

Observa<ons

User interface
analysis

Document
analysis

Prototypes

Facilitated
ac<vi<es:
Group-based

Group-based & ObservaEon technique Field observaEon

Observa<on of the users at work in real context
How they perform their daily @ rou<ne tasks
Might be silent and interac<ve approach

Strengths
If stakeholders have no <me
If stakeholders are not good in phrasing their knowledge
Iden<es basic factor requirements in detail

Weakness
Risk to reuse inecient processes and solu<ons
Iden<es only performance factor that already exist
Not applicable for new processes

Requirements elicitaEon techniques

Interviews

Ques<onnaires

Workshops/
Brainstorm

Focus groups

System
interface
analysis

User interface
analysis

Prototypes

Observa<ons

Document
analysis

Independent
ac<vi<es:
Document-
centric

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<ng know-how is conserved
Iden<es basic factor requirements in detail

Weakness
Requires familiarity with implementa<on language
A lot of works
Exis<ng improper solu<ons are kept

Document-centric technique User interface analysis

Synonym to system archeology
Explora<on of func<onality of exis<ng system
Use screen shots in sohware manuals

Strengths
Iden<fy list of screens for poten<al features
Learn common user steps in the exis<ng system
Reveals real data that the users need to see
Iden<es basic factor requirements in detail

Weakness
Tendency to make assump<ons on certain func<onality or
its ows in the current system must be implemented in
future system
Less excitement factor

Document-centric technique Document analysis

Examining any exis<ng & useful documenta<on
Requirements specica<ons, business processes, user
manuals, standards policies

Strengths
Reveals corporate or industry standards, regula<ons to
comply
Reveals func<onality that need to be retained and
obsolete one
Iden<es basic factor requirements in detail

Weakness
Available documents might not up to date changes are
not well specied
Have to put trust on the exis<ng documents

Requirements elicitaEon techniques

Interviews

Ques<onnaires

Workshops/
Brainstorm

Focus groups

Observa<ons

System
interface
analysis

User interface
analysis

Document
analysis

Prototypes

Independent
ac<vi<es:
Other support

Other support technique Prototyping

An ini<al version of a system which may be used for
experimenta<on
Strengths
Experiment and discover what they really need to support
their work
Establishes feasibility and usefulness before high
development costs are incurred
Essen<al for developing the look and feel of a user
interface
Can be used for system tes<ng and the development of
documenta<on

Weakness
Forces a detailed study of the exis<ng requirements

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<es to customers and which are the hardest to
understand.
Requirements which are well-understood need not be implemented
by the prototype.

2. EvoluEonary prototyping
intended to deliver a workable system quickly to the customer.
Therefore, the requirements which should be supported by the ini<al
versions of this prototype are those which are well-understood and
which can deliver useful end-user func<onality. It is only aher
extensive use that poorly understood requirements should be
implemented.
48

Suggested elicitaEon techniques by project characterisEcs

Elicita<on techniques

Project characterisEc

Mass-market sohware

Internal corporate sohware

Replacing exis<ng system

Enhancing exis<ng system

New applica<on

x
x

Packaged sohware implementa<on

Embedded systems

Geographically distributed stakeholders

* Elicita<on techniques
1 Interviews

2 Workshops

3 Focus groups

4 Observa<ons

Source: Wiegers & BeaAy, 2014 (pg. 130)

5 Ques<onnaires
6 System interface analysis
7 User interface analysis
8 Document analysis

CorrelaEon of elicitaEon techniques with Kano Model

Technique

Basic factor

Performance
factor

Excitement
factor

Interviews
Ques<onnaires
Crea<vity
Observa<on

+
-
-
++

++
+
++
+

+
-
++
+

Document centric

++

-
Source: Pol & Rupp (2011))

Summary
1. Deni<on of requirement elicita<on ~ discovery
2. Requirements sources stakeholders, documents,
exis<ng systems
3. Kano Model for sa<sfac<on factor basic,
performance & excitement
4. Requirement elicita<on techniques
Survey-based
Group-based
Observa<on
Crea<vity
Document centric

Problem solving
Based on the previous Vision and Scope
document for Cafeteria Ordering System:
1. Iden<fy and categorize the user requirements
based on the 3 categories of Kano Model
sa<sfac<on factors (Basic, Performance &
Excitement factors)
2. Suggest the suitable techniques to elicit the user
requirements for the 3 categories of Kano Model
sa<sfac<on factors. Jus<fy the reasons.

References
K. Wiegers and J. Beawy, Sohware Requirements, 3rd Edi<on.
Washington: Microsoh Press, 2014.
K. Pohl and C. Rupp, Requirements Engineering
Fundamentals, 1st edi<on. CA, USA: Rocky Nook, 2011.