SOFTWARE REQUIREMENTS ENGINEERING

LECTURE 1 : INTRODUCTION & FUNDAMENTALS

ISB23103

By:
Ms. Nik Azlina Nik Ahmad
3
TOPIC AND STRUCTURE OF
THE LESSON

 Importance of Requirements Engineering Legend

 Three Dimensions of Requirements Engineering
 Three Types of Requirements
D Definition

E Example
4
TEACHING
GOALS
The students :
 understand the importance of requirements engineering for the project
success.
 learn the definitions of requirements engineering and related terms.
 understand the three dimensions of requirements engineering and the
requirements engineering process within these dimensions.
 learn the goals of requirements engineering.
 learn different types of requirements.
 Importance of Requirements
Engineering

5
6 CHAOS
Report
 Project Success and Failure

Based on [Wikipedia 2014]

7 CHAOS

Report
Reasons for Resource Overspend and Functional Restrictions
 Reasons related to insufficient and poor requirements engineering! (48.1%)

Based on [The Standish Group 1995]

8 CHAOS

Report
Reasons for Projects Cancelled
• Reasons related to insufficient and poor requirements engineering! (44.1%)

Based on [The Standish Group 1995]

9
TOPIC AND STRUCTURE OF
THE LESSON

 Effort required for correcting requirements defects:

 Defect found after delivery (small & non-critical projects)

 increase of effort required for correction by factor 5!

 Defect found after delivery (large & critical projects)

 increase of effort required for correction by factor 100!
 Three Dimensions of Reqs
Engineering

10
 11
THREE DIMENSIONS
OF RE
Goal
Content

Agreement

Documentation

Based on [Pohl and Ulfat-Bunyadi 2013]

12
(GOALs OF)
REQUIREMENTS
ENGINEERING
D
Requirements engineering (RE) is a cooperative, iterative and incremental process
which aims at ensuring that :

(1) All relevant requirements are explicitly known and understood at the required
level of detail.
(2) A sufficient agreement about the system requirements is
achieved between the stakeholders involved.
(3) All requirements are documented and specified in compliance with the
relevant documentation/specification guidelines.

Based on [Pohl and Ulfat-Bunyadi 2013]

13
REQUIREM
ENT
D A requirement is :
(1) a condition or capability needed by a user to solve a problem or
achieve an objective.
(2) 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.
(3) a documented representation of a condition or capability
as in (1) or (2).

Requirements include the quantified and documented needs, wants and

expectations of stakeholders.

Based on [ISO/IEC/IEEE 24765-2010]

 Three TYPES OF
REQUIREMENTS

14
15
3 types of
REQUIREMENTS

Functional Quality Constraints

16
IS THERE
NFR?

Underspecified functional

=
requirements
Non-functional
requirements
Quality
requirements
17
types of
REQUIREMENTS 1
FUNCTIONAL REQUIREMENTS
(FR)
 These Functional Requirements (FR) are :
 Statements of services the system should provide
 How the system should react to particular inputs and
 How the system should behave in particular situations

 In some cases, the functional requirements may also state what the system should not do.
 When expressed as user requirements, the requirements are usually described in a fairly
abstract way.
 However, functional system requirements describe the system function in detail, its inputs
and outputs, exceptions and so on.
18
types of
REQUIREMENTS 1
FUNCTIONAL REQUIREMENTS
 Examples of FR : (FR)
EXAMPLE

The house information system shall generate monthly statements of allowed

R-4 :
and denied accesses.

If a sensor detects a damage of the window, the system shall inform the
R-6 :
security company.

If a correct PIN is entered at the keyboard of the access system, the system shall
R-9 :
remove the door lock and shall record access date, time and the PIN entered.
19
types of
REQUIREMENTS 2
QUALITY REQUIREMENTS

 The Quality Requirements (FR) are :

A quality requirement defines a quality property for the entire
system, for a system component, for a service or for a function.
 20
types of
REQUIREMENTS 2
QUALITY REQUIREMENTS
Quality in Use System/Software Product Quality

Effectiveness Functional suitability

Efficiency Performance efficiency

Satisfaction Compatibility

Freedom from risk Reliability

Context coverage Security

Maintainability

[Based on ISO/IEC 25010:2011] Portability

21
types of
Quality in Use
REQUIREMENTS 2
QUALITY REQUIREMENTS
Quality Requirement Description

Accuracy and completeness with which users achieve

Effectiveness specified goals.

Resources expended in relation to the accuracy and completeness with which

Efficiency users achieve goals.

Degree to which user needs are satisfied when a product or system is used in a specified
Satisfaction context of use.

Degree to which a product or system mitigates the potential risk to economic status,
Freedom from risk human life, health or the environment.

Degree to which a product or system can be used with effectiveness, efficiency, freedom from
Context coverage risk and satisfaction in both contexts of use and in contexts beyond those initially explicitly
identified.

[ISO/IEC 25010:2011]
 [ISO/IEC 25010:2011]
22 types of
System/Software Product Quality REQUIREMENTS 2
QUALITY REQUIREMENTS
Quality Requirement Description
Functional suitability Degree to which a product or system provides functions that meet stated and implied needs
when used under specified conditions.
Performance efficiency Performance relative to the amount of resources (e.g., other software products, hardware
configuration, etc.) 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.
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
authorisation.
Maintainability Degree of effectiveness and efficiency with which a product or system can be modified by the
intended maintainers.
Portability Degree of effectiveness and efficiency with which a system, product or component can be
transferred from one hardware, software or other operation or usage environment to another.
23
types of
REQUIREMENTS 2
QUALITY REQUIREMENTS
EXAMPLE
Quality Requirement Type of Quality

The user interface shall be easy to use for the house

R-12 : Satisfaction
owner.

The release of the locking mechanism shall take 0.8 Performance

R-15 :
seconds at most. Efficiency

The user password stored in the system shall be

R-17 : Security
protected against unauthorized access.
 24
types of
REQUIREMENTS 2
QUALITY REQUIREMENTS NFR-12 is clearly an
EXAMPLE underspecified
NFR-12 : The system shall be secure. requirement
requirements, which specify that “the

Each user shall log in to the system with his user name and password prior to
More precise functional and quality

R-12.1 :
using the system.
system shall be secure” are:

R-12.2 : The system shall remind the user every four weeks to change the password.

When the user changes his password, the system shall validate that the new
R-12.3 :
password is at least eight characters long and contains alphanumeric characters.

The user password stored in the system shall be protected against

R-12.4 :
password theft.
25
types of
REQUIREMENTS 3
CONSTRAINTS

D
A constraint is an organizational or technological requirement
which restricts the way the system shall be developed.

Based on [Robertson and Robertson 2006]

26
types of
REQUIREMENTS 2
CONSTRAINTS
EXAMPLE
Constraint Type of Constraint

The user interface shall not contain symbols or graphics

C-9 : Culture
abusive for any culture.

The effort for system development shall not exceed Organisational /

C-16 :
480 person months. project

The electronic control unit in the vehicle interior shall

C-36 : Physical
work at temperatures from -10 to +50 degrees Celsius.

The system shall process personal data in compliance Legal

C-41 :
with the EU’s Data Protection Directive 95/46/EC.
27
types of
REQUIREMENTS 3
C O N S Tof
Influence RA INTS
Constraints
Development Process System

E E
C-16 : The effort for system development C-36 : The electronic control unit in the vehicle
shall not exceed 480 person interior shall work at temperatures from
months. -10 to +50 degrees Celsius.

Constraints characterizing the development process as well as constraints characterizing the system usually
affect the development process and the resulting product of the development process (i.e. the system itself)
28
types of
REQUIREMENTS 3
C O N S Tof
Influence RA INTS
Constraints
R-3 : The output shall be presented on a mobile phone. Possible solutions, e.g.:

iOS Windows 10 Android BlackBerry OS

C-4: Only iOS and Android shall be supported.

Consequence: 2 out of 5 initial solutions left (40.0%)

iOS Windows 10 Android BlackBerry OS

 RE PROCESSES

29
30
RE
processes
• Requirements elicitation
– Requirements discovered through consultation with stakeholders

• Requirements negotiation
– Requirements are analyzed and conflicts resolved through negotiation

• Requirements documentation
– A requirements document is produced

• Requirements validation
– The requirements document is checked for consistency and completeness

• Requirements management
– Involves controlling requirements change and communicating to relevant stakeholders
31
RE
processes
identifying, discovering

Elicitation

classifying,
evaluating, re-evaluate representing,
verifying Validation Negotiation deriving,
negotiating

Specification
documenting, SRS
 WHAT & HOW IN DEVELOPMENT
PROCESS

32
 Influence of Constraints
33
Vision “What?”

Requirements for the whole

“How?”
system “What?”
WHAT & HOW IN

“How?”
DEVELOPMENT

System architecture
“What?”
PROCESS

Requirements for the “How?”

components “What?”

Design model of the “How?”

components “What?”

Implementations
of the components
“How?”
System
34
REDUCTION OF SPACES
DURING DEVELOPMENT
+

“What”
“What”
“What”
“What”
Vision

“What”

“How” “How”
“How” “How”
“How”
Implementation
Design of the
Component components
+ Design of the requirements
Requirements system
architecture
“What?” = Problem description
“How?” = Solution description
 35
What & how within
development phase
Differentiation between “what” and “how” also occurs within a development phase.

E Requirements Engineering Phase

What? How?

• R-12: The navigation system shall allow the
driver to enter the destination of the trip
conveniently.
• R-12.1: When the driver starts a new trip, the
navigation system shall display a roadmap of
the area centered on the current position.
• R-12.2: The navigation system shall allow the driver
to scroll and zoom into the roadmap.
• R-12.3: After the driver has selected a destination on
the roadmap, the system shall allow the
driver to edit the destination details (city,
street and house number).
 CONTINUOUS REQUIREMENTS
ENGINEERING

36
37
ESSENCE VS
INCARNATION
D Essence of a System

A true requirement is a feature or capability a system shall possess in order to fulfil its purpose,
regardless of how the system is implemented. We call the complete set of true requirements for a
system the essence of the system or the essential requirements.

D Incarnation of a System

The sum of people, wires, paper clips, carbon paper, pencils, typewriters, computer terminals, office
furniture, file cabinets, offices, telephones, CPUs and so forth that are used to implement the
essential activities and memory of a system are what we call its incarnation.
38
RE AS CROSS-PROJECT & CROSS-
PRODUCT ACTIVITY
 Continuously creates, changes and deletes requirements.

 The requirements base contains requirements under development as well as agreed, complete and
correctly specified requirements.

 At a given point in time a set of requirements to be realized in the next system or system
release is selected from the requirements base.

Requirements base
39
RE AS CROSS-PROJECT & CROSS-
PRODUCT ACTIVITY
Requirements base

Development of system A

Development of system B

Select requirements from the Continuous feedback during

requirement base. development.
40
ADVANTA
GES
Shorter product development times
 Time-consuming analysis of the current
Systematic learning process state at the beginning of each project is
 Institutionalized learning process in which the prevented.
stakeholders involved continuously extend and
improve their understanding of the
requirements.
 Sharing of requirements across projects.
Reuse across projects and products
 Facilitates the reuse of requirements and
related development artefacts across projects
and products.
Requirements are always up to date
 Up-to-date requirements base across products
and projects. Clear responsibilities
 Ensures that changes are integrated into the
requirements base.  One or multiple people are explicitly responsible
for the development and the management of the
requirements across projects and products.
41
SUMMA
RY

 Requirements engineering is a critical success factor for software-intensive systems.

 Definition of requirements engineering and requirement.
 Requirements engineering has three main goals characterised by the three
dimensions of requirements engineering (content, documentation and agreement).
 Three types of requirements:
 Functional requirements,
 quality requirements and
 constraints
42
SUMMA
RY

 Non-functional requirements are underspecified functional requirements and/or

quality requirements!
 Requirements engineering is embedded within organizational processes.
 Requirements engineering as an early phase of system development has significant
shortcomings.
 Continuous requirements engineering as cross-project and cross-system activity
overcomes these shortcomings.
 43
LITERA
[Boehm and Basili 2001] T UReduction
B. Boehm, B. Basili: Software Defect R E Top
10 List. IEEE Computer, Vol. 34, No. 1, IEEE Computer Society, Los Alamitos, 2001, pp. 135-137.

[Brooks 1987] F.P.Brooks: No Silver Bullet – Essence and Accidents

of Software Engineering. IEEE Computer, Vol. 20, No. 4, IEEE Computer Society, 1987, pp. 10-19.

[ISO/IEC 25010-2011] ISO/IEC 25012:2008(E) Software product Quality

Requirements and Evaluation (SQuaRE) — Data quality model", Switzerland, 2008.

[ISO/IEC/IEEE 24765-2010] Institute of Electrical and Electronics Engineers:

ISO/IEC/IEEE FDIS 24765 - Systems and Software Engineering Vocabulary. IEEE, 2010.

[Pohl and Ulfat-Bunyadi 2013] K. Pohl, N. Ulfat-Bunyadi: The Three Dimensions of Requirements Engineering: 20 Years Later.
In J. Bubenko et al., eds. Seminal Contributions to Information Systems Engineering.
Springer Berlin Heidelberg, pp. 81–87, 2013.

[Robertson and Robertson 2006] S. Robertson, J. Robertson: Mastering the Requirements Process.
2nd edition, Addison-Wesley, Amsterdam, 2006.

[Sommerville 2007] I. Sommerville: Software Engineering. 8th edition, Addison-Wesley, Boston, 2007

[The Standish Group 1995] The Standish Group Report: CHAOS. The Standish Group, 1995.
44
REFERE
NCE

 Klaus Pohl, Requirements Engineering Fundamentals, Principles and

Techniques 1st edition, Springer,2010.