SCSJ 2253

REQUIREMENTS ENGINEERING
AND SOFTWARE MODELING

TOPIC 3:
REQUIREMENTS ELICITATION

update: October 2020 (NI)

1
Noraini Ibrahim, March 2021
Recap from Topic 1 (Intro & Foundation)

Topic 3
 RECAP ON TOPIC 2
System context, system boundary,
scope, context boundary, system
Definitions context objects, interfaces, grey
zone

WHY?

Context of a system
Concepts
Grey zone

Structured approach
Documenting
system context Object-oriented (OO)
approach
 TOPIC 3 OVERVIEW

Definition of requirements elicitation

Sources of requirements

Kano classification of requirements

Elicitation techniques
 PART 1
• Definitions
 Definition of Requirements elicitation

• The process of seeking, capturing and consolidating

requirements from available requirements sources.
May include the re-construction or creation of
requirements. (Pohl and Rupp, 2011)

• Synonym: Requirements discovery, gathering

 PART 2
• Sources of requirements
 Begin with an end in mind
Recall your understanding
on system context objects
(SCO) in Topic 2 (System
and context).
Based on the Library
System and its context
visualization, can you
name at least THREE (3)
for each of the following
SCO?
1. people (stakeholders)
2. documents
3. system in operation
(software/hardware)

Credit to: Mathhias Lampe, CPRE (2018)

Sources of requirements

Stakeholder

Documents

Systems in operation
 #1 Sources of requirements

Stakeholder
An object for a context

Has knowledge about several

context objects and their
relationships

Examples:
User, employer, client, manager…
Operator, developer, architect,
tester…
 #2 Sources of requirements

Documents
Contain important information
that can provide requirements

Examples:
• Universal documents : laws, norms,
standards
• Domain-or-organization- specific
documents : concepts, professional
articles, printed papers,
incidents/error reports of legacy
systems
 #3 Sources of requirements

Systems in
operation Examples:
• Existing or legacy systems
• External system
• Competitor 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 collaboration – Stakeholder obligations
Introduce the requirements engineer to the application domain

Supplies the requirements

Make timely decisions

Respects the estimation of costs and feasibility

Prioritize 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 collaboration – Requirements engineer obligations
Speaks the language of the stakeholder

Becomes thoroughly familiar with the application domain

Creates a requirement document

Able to make the document understandable

Maintains a respectful relationship with any stakeholder

Presents ideas and alternatives

Ensures that the system satisfies the demands of the stakeholders

 PART 3
• Kano Classifications
 Kano Model : Stakeholders’ satisfaction

Satisfaction Excitement factors

very satisfied (Delighters)

Performance
factors
(Satisfiers)

complete
Coverage
insufficient
Basic factors
(Dissatisfiers)
Change in time

unsatisfied

Pohl & Rupp (pg.23)

 Kano Model : 1) Basic Factors

Satisfaction Excitement factors

very satisfied (Delighters)

Performance
factors
(Satisfiers)

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
unsatisfied saying)
 Kano Model : 1) Basic Factors

Satisfaction Excitement factors

very satisfied (Delighters)

Performance
factors
(Satisfiers)

complete
Coverage
insufficient
Basic factors
(Dissatisfiers)

Elicitation
techniques :
Observation &
unsatisfied
Document-centric
 Kano Model : 2) Performance factors

Satisfaction Excitement factors

(Delighters)
very satisfied

Performance factors
(Satisfiers)
- in focus of stakeholders
- conscious and intended
- explicitly communicated
complete
Coverage
insufficient
Basic factors
(Dissatisfiers)

unsatisfied
 Kano Model : 2) Performance factors
Excitement factors
Satisfaction (Delighters)
very satisfied
Performance
factors
(Satisfiers)
Elicitation
technique : Survey

complete
Coverage
insufficient
Basic factors
(Dissatisfiers)

unsatisfied
 Kano Model : 3) Excitement factors
Excitement factors
(Delighters)
Satisfaction
- unexpected for stakeholders
very satisfied - not yet conscious
- never communicated

Performance
factors
(Satisfiers)
complete
Coverage
insufficient
Basic factors
(Dissatisfiers)

unsatisfied
 Kano Model : 3) Excitement factors

Satisfaction Excitement factors

very satisfied (Delighters)
Elicitation
technique :
Creativity-based
Performance
factors
(Satisfiers) complete
Coverage
insufficient
Basic factors
(Dissatisfiers)

unsatisfied
Think about ATM machine in Banking
system domain

ATM ATM ATM

 PART 4
• Elicitation Techniques
 Supporting technique – Prototyping

• An initial version of a system which may be used for

experimentation
• Strengths
– Experiment and discover what they really need to support
their work
– Establishes feasibility and usefulness before high
development costs are incurred
– Essential for developing the ‘look and feel’ of a user
interface
– Can be used for system testing and the development of
documentation
• Weakness
– Forces a detailed study of the existing 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 difficulties to customers and which are the hardest to
understand.
– Requirements which are well-understood need not be implemented
by the prototype.

2. Evolutionary prototyping
– intended to deliver a workable system quickly to the customer.
– Therefore, the requirements which should be supported by the initial
versions of this prototype are those which are well-understood and
which can deliver useful end-user functionality. It is only after
extensive use that poorly understood requirements should be
implemented.
51
 Summary
1. Definition of requirement elicitation ~ discovery
2. Requirements sources – stakeholder, documents, existing
systems
3. Kano Model for satisfaction factor – basic (dissatisfier),
performance (satisfier) & excitement (delighter)
4. Requirement elicitation techniques
² Survey-based
² Group-based
² Observation
² Creativity
² Document centric
 TOPIC 3 SUMMARY

Definition of requirements elicitation

Sources of requirements

Kano classification of requirements

Elicitation techniques
update: August 2019 (sharinhh)

68