New Mansoura University

Faculty of Computer Science and Engineering

CSE-251 Software Engineering

Lecture 03: Requirements Engineering
Objectives

• To introduce the concepts of user and system requirements

• To describe functional and non-functional requirements
• To explain how software requirements may be organised in a
requirements document
• To describe requirements engineering, related activities and
processes

2
Topics covered

• Functional and non-functional requirements

• User requirements
• System requirements
• Interface specification
• The software requirements document
• Requirements engineering activities
• Requirements engineering processes

3
Requirements Engineering

•Establishing what the customer requires

from a software system
Requirements Engineering

• The process of establishing the:

• services that the customer requires from a system
• constraints under which the system operates
• constraints under which the system is developed.
• Requirements may be functional or non-functional
• Functional requirements describe system services or features.
• Non-functional requirements is a constraint on the system or on the
development process.
What is a Requirement?

• It may range from a high-level abstract statement of a service (or of a

system constraint) to a detailed mathematical functional
specification.
• This is inevitable as requirements may serve a dual function:
• May be the basis for a bid for a contract - therefore must be open to
interpretation.
• May be the basis for the contract itself - therefore must be defined in detail.
• Both these statements may be called requirements.
Requirements Definition/Specification

• Requirements Definition
• A statement in natural language of the services the system provides and its
operational constraints.
• Written for customers.
• Requirements Specification
• A structured document setting out detailed descriptions of the system
services.
• Written as a contract between client and contractor.
• Written for contractors and developers.
Definitions and specifications
User requir ement definition

1.T he softw are m ust pr ovide a means of repr esenting and

1. accessing e xternal files cr ea ted b y other tools .

System requir ements specification

1.1The user shouldbe pr ovided with facilities to define the type of

1.2 external files .
1.2Eache xternal file type ma y have an associa ted tool w hich ma y be
1.2 applied to the file .
1.3Eache xternal file type ma y be r epr esented as a specific icon on
1.2 the user’ s displa y.
1.4F acilities should be pr o vided for the icon r epr esenting an
1.2 external file type to be defined b y the user .
1.5Whena user selects aniconr epr esenting an e xternal file , the
1.2 effect of that selection is to apply the tool associated with the type of
1.2 the external file to the file represented by the selected icon.
8
Requirements Readers
C l ient managers
S y stem end-users
R equirements
C l ient engi neers
defi ni tion
C ontractor managers
S y stem archi tects

S y stem end-users
R equirements C l ient engi neers
specifi cation S y stem archi tects
S oftware dev elopers
Reasons for Inconsistency

• Large software systems must improve the current situation. It is hard

to anticipate the effects that the new system will have on the
organization.
• Different users have different requirements and priorities.
• System end-users and organizations who pay for the system have
different requirements.
• Prototyping is often required to clarify requirements.
Problems with Natural Language

• Natural language relies on the specification readers and writers using

the same words for the same concept.
• A natural language specification is over-flexible and subject to
different interpretations.
• Requirements are not partitioned by language structures.
Natural Language Alternatives

• Structured natural language

• Graphical notations
• Mathematical specifications
The RE process
Feasibility Requirements
study analysis
Requir ements
definition
Feasibility Requirements
report specification
System
models
Definition of
requirements

Requirements Specification of
document requirements
The Requirements Document

• The requirements document is the official statement of what is

required of the system developers.
• Should include both a definition and a specification of requirements.
• It is NOT a design document. As far as possible, it should set out
WHAT the system should do rather than HOW it should do it.
Requirements Document Requirements

• Specify external system behavior.

• Specify implementation constraints.
• Easy to change.
• Serve as reference tool for maintenance.
• Record forethought about the life cycle of the system i.e., predict
changes.
• Characterize responses to unexpected events.
Requirements Document Structure
• Introduction (Requirements Definition)
• Describe need for the system and how it fits with business objectives.
• Functional Requirements
• Describe the services to be provided in detail.
• Non-functional Requirements
• Define constraints on the system and the development process.
• System Evolution
• Define fundamental assumptions on which the system is based and anticipated
changes.
• Glossary
• Define technical terms used.
• Index
Requirements Definition

• Should specify external behavior of the system.

• The requirements should not be defined using a computational
model.
Writing Requirements

• Natural language is typically used when writing requirements

definitions.
• This is universally understandable but three types of problem can
arise:
• Lack of clarity. Precision is difficult without making the document difficult to
read
• Requirements confusion. Functional and non-functional requirements tend
to be mixed-up
• Requirements amalgamation. Several different requirements may be
expressed together
Definition and Specification

• Requirements definition
• Customer-oriented descriptions of the system’s functions and constraints on
its operation.
• Requirements specification
• Precise and detailed descriptions of the system’s functionality and constraints.
• Intended to communicate what is required to system developers and serve as
the basis of a contract for the system development.
Functional Requirements using Structured
Language

• A limited form of natural language may be used to express

requirements.
• This removes some of the problems resulting from ambiguity and
flexibility and imposes a degree of uniformity on a specification.
• Often best supported using a forms-based approach.
Examples of Functional Requirements

1. The user shall be able to search either all of the initial set of
databases or select a subset from it.
2. The system shall provide appropriate viewers for the user to read
documents in the document store.
3. Every order shall be allocated a unique identifier (ORDER_ID) which
the user shall be able to copy to the account’s permanent storage
area.
Form-based Functional Specifications

• Definition of the function or entity.

• Description of inputs and where they come from.
• Description of outputs and where they go to.
• Indication of other entities required.
• Pre and post conditions (if appropriate).
Example of a Form-based Functional
Specification
ECLIPSE/Workstation/Tools/DE/FS/3.5.1

Function Add node

Description Adds a node to an existing design. The user selects the type of node, and its position.
When added to the design, the node becomes the current selection. The user chooses the node position by
moving the cursor to the area where the node is added.
Inputs Node type, Node position, Design identifier.
Source Node type and Node position are input by the user, Design identifier from the database.
Outputs Design identifier.
Destination The design database. The design is committed to the database on completion of the
operation.
Requires Design graph rooted at input design identifier.
Pre-condition The design is open and displayed on the user's screen.
Post-condition The design is unchanged apart from the addition of a node of the specified type
at the given position.
Side-effects None
Definition: ECLIPSE/Workstation/Tools/DE/RD/3.5.1
Tabular specification

• Used to supplement natural language.

• Particularly useful when you have to define a number of possible
alternative courses of action.

24
Tabular specification

Condition Action
Sugar level falling (r2 < r1) CompDose = 0
Sugar level stable (r2 = r1) CompDose = 0
Sugar level increasing and rate of CompDose = 0
increase decreasing ((r2-r1)<(r1-r0))
Sugar level increasing and rate of CompDose = round ((r2-r1)/4)
increase stable or increasing. ((r2-r1)  If rounded result = 0 then
(r1-r0)) CompDose = MinimumDose

25
Graphical models

• Graphical models are most useful when you need to show how state
changes or where you need to describe a sequence of actions.
• Different graphical models are explained in Chapter 8.

26
Sequence diagrams

• These show the sequence of events that take place during some user
interaction with a system.
• You read them from top to bottom to see the order of the actions
that take place.
• Cash withdrawal from an ATM
• Validate card;
• Handle request;
• Complete transaction.

27
Sequence diagram of ATM withdrawal
ATM Database

Card
Card number

Card OK
PIN request
PIN
Option menu Validate card

<<exception>>
invalid card

Withdraw request Balance request

Balance
Amount request
Handle request
Amount
Debit (amount)

<<exception>> Debit response

insufficient cash

Card

Card removed
Complete
Cash transaction

Cash removed
Receipt
28
Requirements Rationale

• It is important to provide rationale with requirements.

• This helps the developer understand the application domain and why
the requirement is stated in its current form.
• Particularly important when requirements have to be changed. The
availability of rationale reduces the chances that change will have
unexpected effects.
Non-functional Requirements

• Define system properties and constraints e.g., reliability, response

time and storage requirements. Constraints are I/O device capability,
system representations, etc.
• Process requirements may also be specified mandating a particular
CASE system, programming language or development method.
• Non-functional requirements may be more critical than functional
requirements. If these are not met, the system is useless.
Non-functional Requirement Types
Non-functional
requir ements

Product Or ganizational External

requir ements requir ements requirements

Ef ficiency Reliability Portability Interoperability Ethical

requir ements requir ements requirements requirements requirements

Usability Delivery Implementation Standards Legislative

requirements requirements requir ements requirements requirements

Performance Space Privacy Safety

requirements requir ements requirements requirements