CHAPTER 1: INTRODUCTION TO REQUIREMENT

ENGINEERING
REQUIREMENT ENGINEERING | ITS64104
IMPORTANCE OF REQUIREMENT ENGINEERING

 The hardest single part of building a software system is deciding

precisely what to build.
 No other part of conceptual work is as difficult as establishing the
technical detailed requirements, including all the interfaces to people,
machines and to other software system.

(Brooks, 1987)
 CHAOS
REPORT-
REASONS FOR
PROJECT
FAILURES
DEFECT FIX
COST
REQUIREMENT ENGINEERING - DEFINITION

 Requirement engineering (RE) is a cooperative, iterative and

incremental process which aims at ensuring that:
 All relevant requirements are explicitly known and understood at
the required level of detail
 A sufficient agreement about the system requirement is achieved
between the stakeholders involved
 All requirements are documented and specified in compliance with the
relevant documentation/ specification guidelines.
REQUIREMENT ENGINEERING FROM 3 DIMENSIONS

THREE (3) GOALS

OF REQUIREMENT
ENGINEERING
 REQUIREMENT ENGINEERING FROM 3 DIMENSIONS
Content dimension
• Also known as specification dimension
• Deals with understanding of the system
requirements
• At the beginning of the requirement
engineering process, only a few
requirements are known and their
understanding is typically vague.

RE Definition: All relevant requirements are

explicitly known and understood at the
required level of detail
 REQUIREMENT ENGINEERING FROM 3 DIMENSIONS
Documentation dimension
• Also known as representation dimension
• Deals with documenting and specifying
the systems requirements using different
and appropriate documentation and
specification format
• At the beginning, requirement is
typically documented non-compliant
with documentation guideline, such as
notes, sketching, drawing, etc

RE Definition: All requirements are

documented and specified in compliance with
the relevant documentation/ specification
guidelines.
 REQUIREMENT ENGINEERING FROM 3 DIMENSIONS
Agreement dimension
• Deals with the level of agreement
achieved between the relevant
stakeholders about the known
requirements.
• Conflicts between the stakeholders about
the requirements have to be detected and
resolved as early as possible

RE Definition: A sufficient agreement about

the system requirement is achieved between
the stakeholders involved
 RELATIONSHIPS BETWEEN DIMENSIONS :
CONTENT & AGREEMENT
 A complete understanding of requirement does not imply a sufficient agreement between
stakeholders about this requirement
 An agreement between stakeholders about a requirement does not imply a complete
understanding of this requirement
PROGRESS
Dimension Impact Example

Agreement Can lead to new requirements which are not Creative solution for a conflict requirement
well understood – content dimension

Content May lead to new conflicts between Eliciting new requirement

stakeholders, or may uncover existing conflicts
– agreement dimension
 RELATIONSHIPS BETWEEN DIMENSIONS :
DOCUMENTATION & CONTENT
 Compliance of a requirement to the documentation guidelines does not imply a
complete understanding of the requirement
 A complete understanding of a requirement does not imply the compliance to the
documentation guideline
PROGRESS
Dimension Impact Example

Documentation Can reveal some gaps in the content Formalization of a requirement according to the
dimension guideline

Content Can lead to drawback in the documentation New elicited requirement

dimension, since most likely the new
requirement is not directly documented
according to the documentation guideline
 RELATIONSHIPS BETWEEN DIMENSIONS :
AGREEMENT & DOCUMENTATION
 An agreement between stakeholders about a requirement does not imply compliance
of the documentation of the requirement to the documentation guideline
 Compliance of a requirement with the documentation guideline does not imply a
sufficient agreement of the stakeholders about this requirement
PROGRESS
Dimension Impact Example
Documentation Can surface a conflict about the requirement Documentation of a requirement according to the
due to better comprehension of the guideline
requirement by the stakeholder
Agreement Can lead to drawback in the documentation Stakeholder solve a conflict by agreeing on a new
dimension, if the new documented alternative requirement
requirement is initially non-compliant with
the documentation guideline.
THREE (3) TYPES OF REQUIREMENTS

 Requirement engineering (RE) is a cooperative, iterative and

incremental process which aims at ensuring that:
 All relevant requirements are explicitly known and understood at
the required level of detail
 A sufficient agreement about the system requirement is achieved
between the stakeholders involved
 All requirements are documented and specified in compliance with the
relevant documentation/ specification guidelines.
 REQUIREMENTS: DEFINITION
 A requirement is:
 A condition or capability needed by a user to solve a problem or achieve an
objective
 A condition or capability that shall be met or possessed by a system, system
component, product or service to satisfy a contract, an agreement, standard,
specification or other formally imposed documents
 A documented representation of a condition or capability as in (1) and (2)

Note: Requirements include the quantified and documented needs, wants and expectations of stakeholders
THREE TYPES OF REQUIREMENTS

Functional requirement

Quality requirements

Constraints
THREE TYPES OF REQUIREMENTS

Functional requirement

• Statements of services the system should provide, how the system should react to
particular input and how the system should behave in particular situations
• In some cases, the functional requirements may also state what the system should not do
• Functional system requirements describe the system function in detail, its input, output,
exceptions and so on

Quality requirements

Constraints
FUNCTIONAL REQUIREMENTS : EXAMPLES

R1 – The house information system shall generate monthly statements of allowed and
denied access

R2 – If a sensor detects damage of the window, the system shall inform the security
company

R3 – If a correct PIN is entered at the keyboard of the access system, the system shall
remove the door lock and shall record access time, date and the associated ID entered.
THREE TYPES OF REQUIREMENTS

Functional requirement

Quality requirements

• Defines a quality property for the entire system, for a system component, for service
or a function
• Usually associated with quality model (e.g ISO25010 2011, Boehm model, etc)

Constraints
ISO25010 2011: PRODUCT QUALITY MODEL
QUALITY REQUIREMENTS
Quality characteristics Description
Functional suitability This characteristic represents the degree to which a product or system provides
functions that meet stated and implied needs when used under specified conditions.

Performance Efficiency This characteristic represents the performance relative to the amount of resources used
under stated conditions

Compatibility Degree to which a product, system or component can exchange information with other
products, systems or components, and/or perform its required functions, while sharing
the same hardware or software environment.

Usability Degree to which a product or system can be used by specified users to achieve
specified goals with effectiveness, efficiency and satisfaction in a specified context of
use.
QUALITY REQUIREMENTS
Quality characteristics Description
Reliability Degree to which a system, product or component performs specified functions under
specified conditions for a specified period of time.

Security Degree to which a product or system protects information and data so that persons
or other products or systems have the degree of data access appropriate to their
types and levels of authorization

Maintainability Degree of effectiveness and efficiency with which a product or system can be
modified to improve it, correct it or adapt it to changes in environment, and in
requirements

Portability Degree of effectiveness and efficiency with which a system, product or component can
be transferred from one hardware, software or other operational or usage
environment to another.
ISO25010 2011: QUALITY IN USE
 NON-FUNCTIONAL REQUIREMENTS??

Is quality requirement considered as non-functional requirement?

YES and NO

• The term non-functional requirement is widely Underspecified functional

used in practice and literature Non functional requirements
• Whenever a requirement is called non-functional requirements =
requirements, the requirement itself is typically Quality
insufficiently understood requirements
 NON-FUNCTIONAL REQUIREMENTS: EXAMPLE

Non functional requirement More precise functional and quality requirement

The system shall be secure • Each user shall log in to the system with his user name and
password prior to using the system
This is a clearly underspecified requirement.
• The system shall remind the user every 4 weeks to change the
password

• When the user changes his password, the system shall validate
that the new password is at least 8 characters long and contains
alphanumeric character
THREE TYPES OF REQUIREMENTS

Functional requirement

Quality requirements

Constraints
• Is an organizational or technological requirement which restricts the way the system
shall be developed
• Global issues that shapes the requirements
 EXAMPLES OF TYPES OF CONSTRAINTS

Type of Constraints Example

Culture The user interface shall not contain symbol or graphics abusive of any culture

Organisational/ project The effort for system development shall not exceed 480 person months.

Physical The electronic control unit in the vehicle interior shall work at temperatures from
-10 to +50 degrees Celsius.

Legal The system shall process personal data in compliance with the EU’s Data
Protection Directive 95/46/EC.
RESTRICTIONS IMPOSED BY CONSTRAINTS

R1: The output shall be presented on a mobile phone.

Possible solutions: examples

iOS Blackberry Windows 10 Android Palm

OS
RESTRICTIONS IMPOSED BY CONSTRAINTS

R1: The output shall be presented on a mobile phone, with only iOS and Android shall be supported.

Possible solutions: examples

Co
nse
5 s que
ol u n
t i on c e s :
s le 2 ou
ft ( t of
40%
)

iOS Blackberry Windows 10 Android Palm

OS
REQUIREMENT ENGINEERING FRAMEWORK
Requirement Engineering Context
System Context
Development
Subject Usage IT system

Cross- Sectional Activity

Cross- Sectional Activity

Context

MANAGEMENT
Facet Facet Facet
VALIDATION

Documentation Elicitation
Core
Activities Negotiation

Requirement Artefacts

Goals Scenarios Solution – oriented requirements

 REQUIREMENT ENGINEERING FRAMEWORK: CONTEXT
Requirement Engineering Context

System Context
System context
IT Development
Subjec Usage
system Context • the part of the context in which the system to be
t Facet Facet
Facet developed is operating/embedded.
Cross- Sectional Activity

Cross- Sectional Activity

MANAGEMENT
Development context
VALIDATION

Documentatio
Core Elicitation
Activities
n • the part of the context in which the system is being
developed
Negotiation

Additional requirements engineering context objects

Requirement Artefacts • which have to be considered during requirements
Goals
Scenari Solution – oriented engineering, but which are not part of the system
os requirements
context nor the development context.
 REQUIREMENT ENGINEERING FRAMEWORK: CONTEXT
Requirement Engineering Context

Subject facet
System Context
Development
• which information is represented in the system or
IT
Subjec
t Facet
Usage
Facet
system Context which influence or constrain the representation of
Facet information in the system.
Cross- Sectional Activity

Cross- Sectional Activity

Usage facet

MANAGEMENT
VALIDATION

• comprises of people and/or systems which directly or

Documentatio
Core n
Elicitation indirectly interact with the system or which influence
Activities
or benefit from the usage of the system.
Negotiation
IT system facet
• comprises technical and operational environment in
Requirement Artefacts
which the system is going to be deployed in or which
influence or constraint the deployment of the system
Goals
Scenari Solution – oriented and/or the use of technology by the system such as
os requirements
sensors, actuators or other systems.
 REQUIREMENT ENGINEERING FRAMEWORK: CONTEXT
Requirement Engineering Context

Subject facet
System Context
Development
• which information is represented in the system or
IT
Subjec
t Facet
Usage
Facet
system Context which influence or constrain the representation of
Facet information in the system.
Cross- Sectional Activity

Cross- Sectional Activity

Usage facet

MANAGEMENT
VALIDATION

• comprises of people and/or systems which directly or

Documentatio
Core n
Elicitation indirectly interact with the system or which influence
Activities
or benefit from the usage of the system.
Negotiation
IT system facet
• comprises technical and operational environment in
Requirement Artefacts
which the system is going to be deployed in or which
influence or constraint the deployment of the system
Goals
Scenari Solution – oriented and/or the use of technology by the system such as
os requirements
sensors, actuators or other systems.
REQUIREMENT ENGINEERING FRAMEWORK: ACTIVITIES
Requirement Engineering Context
System Context
Development
Subject Usage IT system

Cross- Sectional Activity

Cross- Sectional Activity

Context

MANAGEMENT
Facet Facet Facet
VALIDATION

Documentation Elicitation
Core
Activities Negotiation

Requirement Artefacts

Goals Scenarios Solution – oriented requirements

GOALS OF REQUIREMENT ENGINEERING
1) All relevant requirements are explicitly known and
understood at the required level of detail. [CONTENT]

2) A sufficient agreement about the system requirements is

achieved between the relevant stakeholders.
[AGREEMENT]

3) All requirements are documented and specified in

compliance with the relevant documentation/ specification
guidelines. [DOCUMENTATION]

Documentation Elicitation
Core
Activities Negotiation
 CORE ACTIVITIES: ELICITATION

GOAL OF ELICITATION
Core Documentati
Elicitation
(1) Identify relevant requirements sources.
Activities on
(2) Elicit existing requirements from the identified
sources.
(3) Develop new and innovative requirements.
Negotiation

• Requirements sources are not always known at the beginning of

the process!
• Relevant requirements sources include: n tent
in co
- stakeholders involved in the process, ess nsion
gr
- existing documents, Pro dime
- existing systems.
 CORE ACTIVITIES: NEGOTIATION

GOAL OF NEGOTIATION
Core Documentati
Elicitation
(1) Identify conflicts.
Activities on
(2) Analyse the cause of each conflict.
(3) Resolve the conflicts by means of appropriate
strategies.
Negotiation (4) Document conflict resolution and their rationale.

• Wishes and needs of the stakeholders m ent

e
typically vary and can be in conflict. agre
ss in ion
• Conflicts shall be identified and should be ro gr imens
e
P d
resolved.
 CORE ACTIVITIES: DOCUMENTATION

GOAL OF NEGOTIATION
Core Documentati (1) Document relevant requirements information
Activities Elicitation
on
according to the defined documentation guidelines.
(2) Specify requirements according to the defined
specification guidelines.
Negotiation
(3) Choose documentation formats and notations which
fit the stakeholder needs, and are defined for the project.
(4) Ensure consistency between different documentation
formats used. on
nt ati
• In addition to the requirements, information about elicitation and negotiation should be
c ume
documented. i n do ion
re ss mens
• Early in requirements engineering, information is often documented g di
Pro
informally/unstructured and thus not compliant with the documentation and specification
rules.
 CROSS SECTIONAL ACTIVITY: VALIDATION
Requirement Engineering Context THREE (3) VALIDATION GOALS
System Context (1) Validation of requirement artifacts.
IT Development • Aims at detecting defects in requirements.
Subjec Usage Context
system • Validating the artefacts with regard to the content, the documentation and the
t Facet Facet
Facet
agreement dimensions.
Cross- Sectional Activity

Cross- Sectional Activity

• Checking the fulfilment of validation criteria.

MANAGEMENT
VALIDATION

(2) Validation of the core activities.

Documentatio • Checking the compliance of the activities performed and the process and/or
Core Elicitation
n activity specifications.
Activities
• Have all required steps been performed?
Negotiation • Have the required stakeholders been involved in the activities?
(3) Validation of the context consideration
• Checking whether the context has been considered adequately in the activities.
Requirement Artefacts • Have all relevant requirements sources been considered?
Scenari Solution – oriented • Have the required stakeholders been involved?
Goals
os requirements • Have all parts of the requirements engineering context been sufficiently
considered?
 CROSS SECTIONAL ACTIVITY: MANAGEMENT
Requirement Engineering Context THREE (3) MANAGEMENT GOALS
System Context (1) Management of the requirements artifacts throughout the system lifecycle:
IT Development
Subjec Usage Context • Prioritization of requirements.
system
t Facet Facet
Facet • Persistent recording.
• Configuration management.
Cross- Sectional Activity

Cross- Sectional Activity

• Change management.

MANAGEMENT
VALIDATION

• Requirements traceability.
Documentatio
Core Elicitation
n (2) Management of the core activities:
Activities
• Ensure an efficient and effective overall RE process.
Negotiation
• Plan and control the execution of the RE activities.
• Alignment of the process to the current project situation.

Requirement Artefacts (3) Management of the context:

Scenari Solution – oriented • Identifying changes in the context relevant for the system.
Goals
os requirements • Changes typically require (re-)initiating or (re-)scheduling of one or more RE
activities.
 CROSS SECTIONAL ACTIVITY: MANAGEMENT
Requirement Engineering Context THREE (3) MANAGEMENT GOALS
System Context (1) Management of the requirements artifacts throughout the system lifecycle:
IT Development
Subjec Usage Context • Prioritization of requirements.
system
t Facet Facet
Facet • Persistent recording.
• Configuration management.
Cross- Sectional Activity

Cross- Sectional Activity

• Change management.

MANAGEMENT
VALIDATION

• Requirements traceability.
Documentatio
Core Elicitation
n (2) Management of the core activities:
Activities
• Ensure an efficient and effective overall RE process.
Negotiation
• Plan and control the execution of the RE activities.
• Alignment of the process to the current project situation.

Requirement Artefacts (3) Management of the context:

Scenari Solution – oriented • Identifying changes in the context relevant for the system.
Goals
os requirements • Changes typically require (re-)initiating or (re-)scheduling of one or more RE
activities.
 REQUIREMENT ENGINEERING FRAMEWORK:
REQUIREMENT ARTEFACTS
Requirement Engineering Context
Definition

System Context • A goal describes a high level objective of one or more stakeholders
IT Development
Subjec Usage Context
about a property of the system to be developed or the development
system
t Facet Facet
Facet
project.
Cross- Sectional Activity

Cross- Sectional Activity

Characteristics of a goal

MANAGEMENT
VALIDATION

Documentatio
Elicitation
• Prescriptive nature.
Core n
Activities • Expresses stakeholders’ intentions.
• Refines the system vision into more detailed objectives to be
Negotiation
fulfilled by the system
• Should be solution free

Requirement Artefacts

Scenari Solution – oriented

Goals
os requirements
 REQUIREMENT ENGINEERING FRAMEWORK:
REQUIREMENT ARTEFACTS
Requirement Engineering Context
EXAMPLE:
System Context
IT Development
Subjec Usage Context
system
t Facet Facet
Facet
Comfortable and
fast navigation to
Cross- Sectional Activity

Cross- Sectional Activity

destination

MANAGEMENT
VALIDATION

Documentatio
Core Elicitation
n
Activities Circumnavigating Easy entry of Automatic
traffic jams destination navigation
Negotiation

Requirement Artefacts

Scenari Solution – oriented

Goals
os requirements
 REQUIREMENT ENGINEERING FRAMEWORK:
REQUIREMENT ARTEFACTS
Requirement Engineering Context

Definition
System Context
IT Development
Subjec Usage Context • describes a concrete example of satisfying or failing to satisfy a goal
system
t Facet Facet
Facet (or set of goals).
Cross- Sectional Activity

Cross- Sectional Activity

MANAGEMENT
VALIDATION

Documentatio
Core Elicitation
n Characteristics of a scenario
Activities

Negotiation
• Documents a concrete example of system usage.
• Typically defines a sequence of interaction steps executed to satisfy
(or not satisfy) a goal or set of goals.
Requirement Artefacts
• Puts requirements into their context.
Scenari Solution – oriented • Increases the comprehensibility of goals.
Goals
os requirements
 REQUIREMENT ENGINEERING FRAMEWORK:
REQUIREMENT ARTEFACTS
Requirement Engineering Context

EXAMPLE
System Context
IT Development
Subjec
t Facet
Usage
Facet
system Context Entry of destination:
Facet
1. Driver selects the navigation to a desired destination.
Cross- Sectional Activity

Cross- Sectional Activity

2. Navigation system asks for the address of the destination.

MANAGEMENT
3. Driver types in the address.
VALIDATION

Documentatio
Elicitation
4. Navigation system checks the inserted information.
Core n
Activities

Negotiation

Requirement Artefacts

Scenari Solution – oriented

Goals
os requirements
 REQUIREMENT ENGINEERING FRAMEWORK:
REQUIREMENT ARTEFACTS
Requirement Engineering Context
Definition

System Context
Development
• Specify requirements at a level of detail sufficient for supporting
IT
Subjec Usage
system Context later development activities such as design and test
t Facet Facet
Facet
Cross- Sectional Activity

Cross- Sectional Activity

MANAGEMENT
Characteristics
VALIDATION

Documentatio
Core Elicitation
n • Often imply a conceptual/logical solution.
Activities
• Should be conflict-free.
Negotiation • Should be agreed on by all stakeholders.
• Should be as complete as possible.

Requirement Artefacts

Scenari Solution – oriented

Goals
os requirements
 REQUIREMENT ENGINEERING FRAMEWORK:
REQUIREMENT ARTEFACTS
Requirement Engineering Context THREE (3) TYPES OF SOLUTION-ORIENTED REQUIREMENTS

System Context
IT Development (1) Data
Subjec Usage Context
system
t Facet Facet
Facet • considers the static data structures
Cross- Sectional Activity

Cross- Sectional Activity

• defines data types, attributes and relationships between data types.

MANAGEMENT
VALIDATION

Documentatio (2) Functional

Core Elicitation
n
Activities
• considers the manipulation of data by system functions
Negotiation • defines the transformation of inputs by functions into outputs.

(3) Behavioural
Requirement Artefacts
• considers the system behaviour
Scenari Solution – oriented
Goals • defines the reactions to external stimuli in form of permitted states,
os requirements
transitions and outputs.
REQUIREMENT ENGINEERING FRAMEWORK:
EXAMPLE OF SOLUTION-ORIENTED REQUIREMENTS
 REQUIREMENT ENGINEERING FRAMEWORK:
REQUIREMENT ARTEFACTS
Requirement Engineering Context Goals, Scenarios and solution-oriented requirements are
used complementarily during requirements engineering.
System Context
IT Development
Subjec Usage Context
t Facet Facet
system
Facet
INTERRELATIONS:
Cross- Sectional Activity

Cross- Sectional Activity

 Developing goals and scenarios prior to or along with

MANAGEMENT
VALIDATION

Documentatio
solution-oriented requirements leads to a significant
Elicitation
Core
Activities
n improvement of the quality of the requirements.
 Scenarios put requirements into context and thus provide a
Negotiation
basis for deriving and developing solution-oriented
requirements.
 Goals and scenarios support the refinement of requirements
Requirement Artefacts
across different layers of abstraction.
Scenari Solution – oriented
Goals
os requirements
REQUIREMENT ENGINEERING FRAMEWORK:
REQUIREMENT ARTEFACTS

TYPES OF REQUIREMENT
REQUIREMENT ARTEFACTS
• Functional • Goals
• Quality • Scenarios
• Constraint • Solution Oriented
Requirements

Can be defined by