Introduction to Requirements

Engineering
C. R. I.
Université de
Paris 1 - Sorbonne

“The hardest single part of building a software

system is deciding precisely what to build”-F.Brooks
 C. R. I.
Université de
Outline
Paris 1 - Sorbonne

• Overview Picture
• Conventional Approaches
• RE Framework
• Recent Approaches
• About the RE process
• Bibliography
• Conclusion
 C. R. I.
Université de
Paris 1 - Sorbonne
Overview Picture

What is Requirements Engineering about?

What is RE?
Notion of a requirement
The requirements engineering process

Why Requirements Engineering is needed?

When to Engineer Requirements?

Approaches to Requirements Engineering

 C. R. I.
Université de
Paris 1 - Sorbonne
What is RE about?

• The WHY question

Why the system needs to be developed?

• The WHAT question

What the system shall do?

« Requirements definition must say

– why a system is needed, based on current or foreseen conditions,

– what system features will satisfy this context,
……………….» (Ross77)

IEEE Computer 85, IEEE SE 91-92, Bubenko94, Mylopoulos92,

Dardenne93, Loucopoulos95, Rolland98 etc..
 C. R. I.
Université de
Paris 1 - Sorbonne
What is RE about?

Tentative Definition

WHY

Requirements Engineering is the activity which

transforms a fuzzy idea into a precise specification of
stakeholders’ needs that shape the system to be built
and therefore, defines the intended link between a
system and its environment WHAT
 C. R. I.
Université de
Paris 1 - Sorbonne
What is RE about?

Mission statement,
goals
WHY ?

The Requirements
Engineering process

Requirements
WHAT ? Specification
 C. R. I.
Université de
Paris 1 - Sorbonne
What is a Requirement?

“Something that the product must do or

a quality that the product must have” (Robertson99)

“A description of how the system shall behave, an information

about the application domain, constraints on operations,
a system property etc.” (Kotonya98)

“A requirement specifies how a goal should be accomplished by a

proposed system” (Anton96)
 C. R. I.
Université de
Paris 1 - Sorbonne
What is a Requirement?

Examples

❤ a constraint : the system shall include a spelling checker

❤ a required function : the system shall identify “old
customers”
❤ a required quality : the print out for old customers shall be
in colour
 C. R. I.
Université de
Paris 1 - Sorbonne
What is a Requirement?

Requirements taxonomy

Functional (1) versus non functional (2)

(1) Things the system must do

(2) Qualities that the product must have

Ex : Send Christmas cards to old customers(1)

print them in colour (2)
 C. R. I.
Université de
What is Engineering Requirements?
Paris 1 - Sorbonne

A complex process with intertwined activities

and multiple actors

User Re
qu
nt
ie
i
En reme
Cl gin n
eer ts
Elic
Valid itat
ation ion
ager
man ct
Proje

r
ato
Specif Neg
ic

ilit
Docum ation otia
tion

fac
entatio
Do n
m
exp ain em
ert Syst st
ly
Ana
 C. R. I.
Université de
What is Engineering Requirements ?
Paris 1 - Sorbonne

Modelling as a core activity

• The existing system (As-Is) has to be modelled

• The alternative hypothetical systems (To-Be) have to be modelled
• Models serve as a basic common interface to the RE activities
(previous slide)
• Models provide the basis for documentation and evolution

Questions What aspects to model in the Why-What range?

 How to model such aspects?
How to define the model precisely?
How to reason about the model?
 C. R. I.
Université de
Why is RE Needed ?
Paris 1 - Sorbonne

" Inadequate, Inconsistent, Incomplete or ambiguous requirements

are numerous and have a critical impact on the quality
of the resulting software" (Bell&Tayer76)

"Late correction of requirements errors

cost up to 200 times as much as during such
requirements engineering" (Boehm81)

"The primary cause of safety-related faults was errors in functional

interface requirements " NASA's Voyager and Galileo programs,
(Brooks87)
 C. R. I.
Université de
Paris 1 - Sorbonne
Why is RE Needed ?

◆ Poor requirements are major source of failures (Standish95)

8000 projects, 350 US companies :
1/3 of projects never completed & 50% succeeded only partially

◆ Most perceived problems are related to requirements specification

( >50%) - (ESI96)
3800 organisations in 17 European countries
 C. R. I.
Université de
Paris 1 - Sorbonne
When to Model Requirements ?

Traditionally : the early phase of the software development cycle

RUP,
(Jacobson98) Inception Elaboration Construction Transition

Requirements

Analysis

Design

Implementation

Tests Life Cycle Life Cycle Initial Operational Product

Objectives Architecture Capability Release
 C. R. I.
Université de
Exercise
Paris 1 - Sorbonne

Decide what is to be the contents of a student registration system for

your University
 C. R. I.
Université de
Outline
Paris 1 - Sorbonne

• Overview Picture
• Conventional Approaches
• RE Framework
• Recent Approaches
• About the RE process
• Bibliography
• Conclusion
 C. R. I.
Université de
The Conventional View Point
Paris 1 - Sorbonne

"Abstracting from the users wishes, constraints,

needs.. the conceptual specification of the system to
build” : the acquisition, modelling, validation cycle

UNIVERSE Acquisition of domain

OF DISCOURSE knowledge and IS specification

Validation
CONCEPTUAL
WHAT
Requirements Engineering SCHEMA
Design

Correction
Requirements specification
INTERNAL
= conceptual specification HOW SCHEMA
System Engineering
 C. R. I.
Université de
Modelling Perspectives
Paris 1 - Sorbonne

Three perspectives : Data, Function, Behaviour

Data
E/R Data Driven
CIAM Approaches
NIAM
SHM
REMORA ERAE
MERISE

Behavioural &
Temporal
Approaches
SADT Function

IE

(Rolland01) SART Structured Analysis &

Behaviour Design Approaches
 C. R. I.
Université de
Modelling Perspectives
Paris 1 - Sorbonne

Data
Computerise hotel
reservations

Manage Reservations Manage Resources

Function

Create Modify
Reservations Reservations
Behaviour
 C. R. I.
Université de
Modelling Perspectives
Paris 1 - Sorbonne

Data

for in
Reservation Room Hotel
1,N 1,N 1,1 1,N

Function

Behaviour
 C. R. I.
Université de
Modelling Perspectives
Paris 1 - Sorbonne

Data
Request
Arrival

Create Update
Wait List
Room
Reservation Availability
Request
Increased
availability

Create Function
Update

Behaviour
 C. R. I.
Université de
Integrating Perspectives
Paris 1 - Sorbonne

OO approaches
Data
E/R Data Driven
CIAM Approaches
NIAM
SHM
REMORA ERAE
MERISE
UML
Temporal &
Object Oriented
Behavioural OOA
Approaches O* Approaches

OMT OOA&D SADT Function

IE

SART Structured Approaches

Behaviour
 C. R. I.
Université de
Integrating Perspectives
Paris 1 - Sorbonne

Customer

Data
Hotel Update
Availability
Create
Room
Close Update
Availability
Accept
Availability Reservation

Cancel

Function
Create

Behaviour
 C. R. I.
Université de
Exercise
Paris 1 - Sorbonne

Place the method that you are most familiar within the framework

Place OMT in the framework

 Limits & Assumptions of
Conventional Approaches
C. R. I.
Université de
Paris 1 - Sorbonne

• Requirements are supposed to be stable and known

• Users just need to be questioned about their needs

• RE is too much centred on the technical solution

• Notations are far too abstract

• RE is driven by computer engineers

 Revisiting Conventional
Approaches
C. R. I.
Université de
Paris 1 - Sorbonne

Embed schema production in organisational context

modelling

UNIVERSE Acquisition of domain

OF DISCOURSE knowledge and system
specification

Validation
CONCEPTUAL
Requirements Engineering SCHEMA
Design

Correction
INTERNAL
SCHEMA
System Engineering
 C. R. I.
Université de
New RE perspectives
Paris 1 - Sorbonne

• Enlarge modelling scope : from E/R to EM

(from modelling system functions to modelling the
organisational context of the system to be built)

• Consider requirements as a lifecycle 'product'

• Rethink the RE process :

requirements need to be elicited, discovered,
grown!

• Intensify participation of various stakeholders :

engineering requirements must be a co-operative
activity involving domain experts, engineers,
business executives etc..
 RE in a Change
Perspective
C. R. I.
Université de
Paris 1 - Sorbonne

«Elaborate the change vision in its organisational context»

(Jarke93)

Initial New
model model
Change
(As-Is) (To-Be)
definition

Reverse Change
Legacy
analysis implementation
integration New
Existing
system system
 C. R. I.
Université de
Outline
Paris 1 - Sorbonne

• Overview Picture
• Conventional Approaches
• RE Framework
• Recent Approaches
• Bibliography
• Conclusion
 C. R. I.
RE Framework
Université de
Paris 1 - Sorbonne

Structuring the context :

The worlds of Requirements Engineering

How does IS represent

How is Information about SUBJECT information
Subject World used in the WORLD about the Subject World
IS environment

Intentional relationship
USAGE SYSTEM
WORLD WORLD
Usage fit relationship

Justification of DEVELOPMENT Design

development goals WORLD decisions

(Jarke92, Jarke93)
 C. R. I.
Université de
RE Framework
Paris 1 - Sorbonne

2 sources of
requirements
Understanding the
The social Intentional
perspective Relationship
SUBJECT
is essential to
WORLD comprehend the
System system rationale
Environment

USAGE Goal driven

WORLD approaches
Inte
Rel ntion
atio
nshal SYSTEM
ip WORLD
 C. R. I.
Université de
RE Framework
Paris 1 - Sorbonne

2 sources of
requirements
Understanding the
Usage Fit
The individual,
Relationship
pragmatic is essential to meet
perspective SUBJECT users'
WORLD expectations
System
Environment

USAGE Scenario Driven

Approaches
WORLD
Us a
rela ge F SYSTEM
tion it
ship WORLD
 C. R. I.
Université de
RE Framework
Paris 1 - Sorbonne

Understanding the
Domain Genericity
2 sources of
Relationship
requirements helps
eliciting generic
SUBJECT D requirements
om
WORLD ai
System n
G
Environment en
er
ic
ity
USAGE re
la
WORLD Usa tio
ge F ns
it re hi
latio p
nsh SYSTEM
Inte ip
rela ntion
tion al WORLD
ship
 C. R. I.
Université de
Outline
Paris 1 - Sorbonne

• Overview Picture
• Conventional Approaches
• RE Framework
• Recent Approaches
• About the RE process
• Bibliography
• Conclusion
 C. R. I.
Université de
Usage World and IS Rationale
Paris 1 - Sorbonne

The usage world is the social and organisational

environment in which the system is intended to function

Goal driven analysis is an approach to link the various

parts the usage world among them and with the system.

Modelling this link allows to understand

“WHY”
a new system has to be developed or a legacy
system has to be revised
 C. R. I.
Université de
The EKD Approach
Paris 1 - Sorbonne

Objectives model

motivates
motivates
motivates motivates
motivates

Concepts model Activities model Actors model

concerns
concerns concerns

IS requirements model

Modelling organisational objectives to derive

functional and non-functional system requirements,
(Bubenko94)
 C. R. I.
Université de
Example: Car Repair Shop
Paris 1 - Sorbonne

Problem
Goal motivates The number of old
Gain the respect and the clients is decreasing
confidence of the old clients
motivates
Goal Rule
Keeping good contacts Old clients are those with a car more than 10 years old
with the old clients being repaired twice during the last three years
motivates

Concepts Model Activities Model Actors Model

Client Activity Role
- name Sending wishes card for the new Manager
- address use year
repair Preparing Cards
order owner
Role
Signing Cards
Repair Car Employee
- amount - age
- date - type Sending Cards

needs needs
Functional IS Requirements Model Non functional IS Requirement Model

Functional Requirement Non Functional Requirement

Select the old clients Cards must be colour printed
 C. R. I.
Université de
Example: Car Repair Shop
Paris 1 - Sorbonne

Problem
Goal motivates The number of
Gain the respect and old clients is
the confidence of the decreasing
old clients
motivates
Goal
Rule
Keeping good
Old clients are those with a car more than 10 years old
contacts with the
being repaired twice during the last three years
old clients
motivates
 C. R. I.
Université de
Example: Car Repair Shop
Paris 1 - Sorbonne

Problem
Goal motivates The number of old
Gain the respect and the clients is decreasing
confidence of the clients
motivates
Goal Rule
Keeping good contacts Old clients are those with a car more than 10 years old
with the clients being repaired twice during the last three years
motivates

Concepts Model Activities Model Actors Model

Client Activity Role

- name Sending wishes card for Manager
- address
use the new year
repair
order owner Preparing Cards
Role
Repair Car Signing Cards Employee
- amount - age
- date - type
Sending Cards
 C. R. I.
Université de
Example: Car Repair Shop
Paris 1 - Sorbonne

Concepts Model Activities Model Actors Model

Activity Role
Client
- name Sending wishes card for the Manager
- address use new year
repair
order owner Preparing Cards
Role
Repair Car Signing Cards Employee
- amount - age
- date - type
Sending Cards

needs needs
Functional IS Requirements Model Non functional IS Requirement Model
Functional Requirement Non Functional Requirement
Select the old clients Cards must be colour printed
 C. R. I.
Université de
Exercise
Paris 1 - Sorbonne

Write one path from a high level objective to requirements in the

student registration system
 C. R. I.
Université de
Scenario Based RE
Paris 1 - Sorbonne

The “User” point of view

Actor C

System

Requirements
Collection
Scenario 1

Scenario
Actor A
Actor B
Actor A Actor B

Every Actor has his/her view Every Actor describes the way
on how to use the system he/she would like to interact
with the system
 C. R. I.
Université de
Example : The Meeting Scheduler
Paris 1 - Sorbonne

Temporal sequence of interactions between the system-to-be & its environment

(Potts94)
 C. R. I.
Université de
Scenario Based RE
Paris 1 - Sorbonne

Scenarios are important artefacts used for a variety of purposes

- elicitation of requirements (Potts94, Rolland98)

- identify exceptional cases (Potts95)
- to populate abstract models (Rumbaugh91, Rubin92)
- to validate requirements in conjunction with prototyping
(Sutcliffe98), animation (Dubois93), or plan generation tools
(Fickas92) and generate acceptance tests (Hsia94)

The use of scenarios raise problems :

coverage, combinatorial explosion, procedural nature,
leave intended system properties implicit, force to
premature choices
 C. R. I.
Université de
Outline
Paris 1 - Sorbonne

• Overview Picture
• Conventional Approaches
• RE Framework
• Recent Approaches
• About the RE process
• Bibliography
• Conclusion
 C. R. I.
Université de
Paris 1 - Sorbonne
The RE process

The development world is concerned with methods,

models and tools to support the RE process

Maturity levels
It is necessary to improve the
• INITIAL (80%)
maturity level of development teams
• REPEATABLE
Including RE teams • DEFINED
• MANAGED
• OPTIMISED

(Humphrey89)
 C. R. I.
Université de
Paris 1 - Sorbonne
The RE process

How to improve the current practice?

 Improving methods : the methodological impact

From handicraft to industrial performance:

formalisation of the RE process (definition of process models)
and tool driven guidance

 Improving RE process management : the managerial

impact

Continuous improvement cycle

and mechanisms for capitalising from experience
 C. R. I.
Université de
Pohl’s View
Paris 1 - Sorbonne

Understanding the process

Agreement
common views

personal views Representation

opaque al al
rm rm
nfo fo
i
complete

Specification (Pohl94)
 C. R. I.
Université de
Paris 1 - Sorbonne
Pohl’s view of the RE process

• Elicitation/specification (representation axis):

Requirements shall be discovered and specified

according to some representation system

• Negotiation (agreement axis) :

Requirements might be conflicting with one another and

must be negotiated depending on their costs and priority

• Compliance to standards (specification axis) :

Requirements must comply with quality standards

 Potts’s View
Inquiry Cycle Model
C. R. I.
Université de
Paris 1 - Sorbonne

Expression
- requirements documents
- goals
- scenarios

Discussion
- questions
- answers
- open questions

Commitment
- change requests

(Potts94)
 C. R. I.
Université de
Tracing the RE Process
Paris 1 - Sorbonne

Example of trace model : IBIS

Pro (+)
Position
Argument
Con (-)

Is a response to
is suggested
by
Issue Passenger is not an
Entity-Type

An entity must be identified:

Is Passenger an
the system does not need to
Entity-Type ?
Identify every passenger
 Tracing the RE Process
Potts’s example
C. R. I.
Université de
Paris 1 - Sorbonne
 Guiding the RE Process
NATURE example
C. R. I.
Université de
Paris 1 - Sorbonne

(a) Guidance is based on situated knowldge : cardinality ‘0’

o.n
SITUATION Person Car
owns

(b) Guidance suggests improvements : decision to partition ET

DECISION "Partition" the ET Person

(c) If guidance is embedded in a CASE tool the decision is applied
automatically

Person
ACTION
is.a is.a

1.n
Non car owner Car owner Car
owns

ARGUMENT to remove Null values (Rolland96)

 Process centred environment
framework
C. R. I.
Université de
Paris 1 - Sorbonne

Process Model Domain Real World Development Domain

Agents,
Activities
Process models
Methods

Enactment Guidance
Feedback Control Information

Enactment Domain
(adapted from
Dowson93)
Enactment
Mechanism

• Process Tracing => Trace Model

• Process Guidance => Guidance Model
 C. R. I.
Université de
Process Management Aspects
Paris 1 - Sorbonne

• CMM Adaptation to RE processes

(Ian Sommerville & Peter Sawyer
Requirements Engineering :A Good practice Guide,
Wiley 1997)

• IEE standard
IEEE/ANSI 830-1993
IEEE/ANSI 830-1998
Standards, Guidelines and Examples on System and Software
RE, M.Dorfman, R.H.Tayer, IEEE Computer Society Press, 1993&1998

• CASE tools for requirements management

DOORS , Quality Software & Software
RequisitePro 4.0, Rational Software
 Sommerville’s Adaptation of the
CMM
C. R. I.
Université de
Paris 1 - Sorbonne

The first three levels are reconsidered :

Initial : ad-hoc process definition leaving many

problems in the performance of RE processes

Repeatable : definition of a list of activity types

and of a standard for documentation. Leads to a
better mastering of projects of the same nature.

Defined : Guided process through patterns of

good practice. Mechanisms for process
improvement are installed.
 Sommerville’s Adaptation of the
CMM
C. R. I.
Université de
Paris 1 - Sorbonne

Team evaluation and process improvement are based on

guidelines classified as :
Basic guidelines, Intermediate guidelines & advanced guidelines

Ex : the ‘ top ten ’

Define a standard document structure
Make the document easy to change
Uniquely identify each requirement
Define policies for requirements management
Define standard templates for requirements description
Use language simply, consistently and concisely
Organise formal requirements inspections
Define validation checklist
Use checklist for requirements analysis
Plan for conflicts and conflict resolution
 IEEE standard 830-1993
C. R. I.
Université de
Paris 1 - Sorbonne

1 Introduction
Purpose of the requirements document
Scope of the product
Definitions, acronyms and abbreviations
References
Overview of the remainder of the document
2 General description
Product perspective
Product functions
User characteristics
General constraints
Assumptions and dependencies
3 Specific requirements, functional, non-functional,
and interface requirements.
 C. R. I.
Université de
Bibliography
Paris 1 - Sorbonne

Software requirements : Objects, Functions and States

A.Davis, Prentice Hall, 1993
« software and structured analysis oriented  »

System Requirements Engineering

P. Loucopoulos, V. Karakostas, Mcgraw-Hill, 1995
« overview »

Exploring Requirements : Quality Before Design

D.C Gause, G.M. Weinberg, Dorset House, 1989
« if you like stories »

Software Requirements and Specifications: A Lexicon of

Practise, Principles and Prejudices
M. Jackson, Addison Wesley, 1995
« good »
 C. R. I.
Université de
Bibliography
Paris 1 - Sorbonne

Requirements Engineering : A Good Practice Guide

Ian Sommerville & Pete Sawyer, John Wiley, 1998
« a ‘ cookbook ’ CMM like »

Mastering the Requirements Process

S. Robertson, J. Roberston, Addison Wesley, 1999
« the GUILDE view point; the Amazon's must in 2002»

Non-Functional Requirements in Software Engineering

L. Chung, B.A. Nixon, E. Yu, J. Mylopoulos, Kluwer, 2000
« THE book on NFR! »

System and Software Requirements Engineering

R.H. Thayer, M. Dorfman, 2nd ed 1999, IEEE Computer Press
« selected papers on RE »
 C. R. I.
Université de
Conclusion
Paris 1 - Sorbonne

❋ Abandon the 'system' centred approach

❋ Favour the 'usage' view point

❋ Forget about system analyst prominence

❋ Prefer a 'facilitator' to conduct co operative work

with all concerned stakeholders

❋ Define the RE process, trace and guide it

 C. R. I.
Université de
Readings
Paris 1 - Sorbonne

1- “From Conceptual Modelling to Requirements Engineering”

C. Rolland, N. Prakash
Special issues of Annals of Software Engineering on ‘Comparative
Studies of Engineering Approaches’, 2001

2- “The Three Dimensions of Requirements Engineering: a framework and its

application”
K. Pohl
Information Systems Vol 19, N 3, pp 243-258, 1994