Chapter 3

Requirements Engineering Process

Definition: The Process of establishing the services that are provided by the systems and the
constraints under which the system must operate is called Requirements Engineering
Process.

Classification of requirements:

- Functional req.: Describes the system services or functions

- Non-functional req: Indicates the constraints placed on the system.

The requirement engineering process is based on “three distinct definitions” which explains
the necessity of engineering process.

 Requirement Definition: It is a statement in natural language along with the

diagrams that represent services of the system. In the process constraints on the
system is also understood.
 Requirement Specification: It is a structured document which sets out the system
services process. These are then used by system end-users, system architects.
 Software Specification:It is an abstract description of the system which is the
basis for design and implementation. It is used by client end-users, system
architects.

Requirements Engineering Process: The four distinct phases of engineering process are :

1. Feasibility study
2. Req. Analysis
3. Req. Definition
4. Req. Specification

1
1. Feasibility study
 Survey of the needs of the needs of the users which may be satisfied using the
present H/W and S/W technologies
 The study also reviews whether the system proposed is effective from business
point of view.
 This yields feasibility report- tells whether to continue with further process or to
stop
2. Requirement analysis

 Deriving the system requirements through observation of existing systems

 Discussing with users and customers
 Development of one or more system models - helps analyst to understand the
process
 System prototypes developed – help to understand the requirements
3. Requirement Definition

 Translate information into document

 Defines set of requirements
 Leeds to production of requirement documenting
4. Requirement specification

 Detailed and précised description of system requirements – basis for a contract

between the clients & S/W developers
 It concentrates on high level design where the errors of requirement definition
discovered

S/W Requirement Document: It is a paper document that contains requirement definition and
specification. SRS should satisfy the following six requirements:
1. It should specify only external behaviour of the system
2. It should specify the constraints on the implementation
3. It should be easy to change
4. It should serve as a tool for maintainrs
5. It should record forethoughts about life cycle of the system
6. It should characterize acceptable responses to undesired events

Requirements document structure contains the following chapters

 Introduction  System models
 Glossary  System evolution
 User requirements definition  Appendices
 System architecture  Index
 System requirements specification

2
A SRS has a fixed structure having number of chapters. The structure is as shown

Chapter Meaning & Description

Introduction • describe need for the system

• describes its functions & how it will work with other systems
• describe how it can be fitted in business or strategic objectives
of organizing

Glossary It should define the technical terms used in SRS

System Models It should show one or more model the indicates relationship between
system components and system and its environment such as semantic
models, object model etc

Functional Req. • contains description of services provided for the users

Definition • Natural language are used along with suitable diagrams

Non-Functional • Describes the constraints placed on the system and its design
Req. Definition • includes details of specific data representations, response time
and memory requirements
• Provides standards and norms for the product and the process

System • describes the fundamental assumptions of the system and

evolution anticipated changes due to the changes in the user needs, H/W
and S/W technology

Requirement • Describes the functional requirements in detail related to

specification internal external interfaces

Appendices • It covers
-- H/W req,
-- dabase req,
-- Index of terminology used in SRS

Requirement Validation:

• It is the process of checking the correctness of the s/w product w.r.t needs and
requirements of the user.
• Check that the right product is being built
• Accessing right data
• Ensures that the software being developed will satisfy its stakeholders
• Checks the software requirements specification against stakeholders goals and
requirements

3
To carry out the validation operation one must consider the following aspects of the
requirements
• Validity: A s/m may have diverse users with different needs. Therefore each of these
needs must be validated
• Consistency: A req. should not conflict with other requirements
• Completeness: The definition should include all functions and constraints needed by the
user of the system
• Realism: Since a s/w is developed to manage a real life problem. Therefore the
requirements must be highly realistic

Requirement validation Techniques:

1. Prototyping
2. Requirement review
3. Automated consistency analysis

1. Prototyping:
It is a process of creating an executable model of the system which is demonstrated to
the user. It gives a hand on experience such that they can see how it supports their
requirements to the users

2. Requirement review:
It is a manual process which involves multiple leaders from both client and contractor
sides. It is carried out to check the requirement document for the anomalies. Reviews may
be formal and informal. Good communications between developers, customers and users
can resolve problems at an early stage.

Requirement review is carried out in two ways:

a) A formal review
b) Informal review
c)
a) A formal review: A formal review is conducted on large scale where the teams from both
client and developer side should check the following items:
1. Verifiability of requirements
2. Comprehensibility of requirements
3. Traceability of requirements
4. Adaptability of requirements

b) A informal review:In this the contractor simply discuss the requirements directly with
clients. Therefore it is a face to face meeting and is done on small scale.

4
Requirement Evolution:

The time required to analyze the requirements and to develop a large system may
take several years. Over this period the environment of original system and its objectives may
also change.

Requirement evolution explains two types of requirements:

1. Enduring requirements
2. Volatile requirements

1. Enduring requirements. Stable requirements derived from the core activity of the
customer organization. E.g. a hospital will always have doctors, nurses, etc. May be
derived from domain models
2. Volatile requirements. Requirements which change during development or when the
system is in use. In a hospital, requirements derived from health-care policy

Classification of requirements:

1. Mutable requirements: Requirements that change due to the system’s environment

2. Emergent requirements: Requirements that emerge as understanding of the system
develops
3. Consequential requirements: Requirements that result from the introduction of the
computer system
4. Compatibility requirements: Requirements that depend on other systems or
organizational processes

Methods used in requirement analysis

1. View point oriented analysis
2. Method based analysis

1. View point oriented analysis:

View point arise when different end users came out with different
requirements. For ex: An ATM s/m used by no.of end users like
a) Bank Customers-who will receive banking services from s/m
b) Managers-who need management information from ATM m/c
c) Staff-who need this s/m to generate report of day to day transactions

5
 Types of viewpoint

1. Data sources or sinks: Viewpoints are responsible for producing or

consuming data. For ex: customers viewpoint allows to do transactions,
update their balance.
2. Representation frameworks: Viewpoints represent particular types of
system model. For ex: the screens and menus may act as framework for
customer
3. Receivers of services:Viewpoints are external to the system and receive
services from system. For ex: view point of bank staff is external to ATM
operation which generates a report of the entire days transactions
Advantages:
1. In an interactive s/m end-users are the receivers of the system and its
services
2. Viewpoints are external to the s/m.
3. Viewpoints explains how important it is in the entire s/m
4. Viewpoints and services may be used to structure non-functional
requirements

2. Method-based analysis:
Widely used approach to requirements analysis. It depends on the application of a
structured method to understand the system. The result of method-based analysis
expressed as a set of system models

The structured method used in this analysis include the following:

1. Process Model: defines the activities in the method. Such as data flow analysis,
control scenarios, identifications etc
2. System modeling notations: there are pictorial notations such as ER diagram,
DFD’s, Object Oriented Diagrams
3. Rules applied to the system model: Such rule may hold within a single model or
across the model.Ex: In a DFD writing the activity on arrow mark() is a rule
4. Design guidelines: These are the hints used in design of a method.
5. Report templates: These define how the information is collected during the
analysis.
6. The information in diagrams are normally supplemented by text messages which
help the analysts understand the method properly

Advantages:
It can be applied systematically to carryout requirement analysis

6
System Context Diagram:

It defines the boundary between the system, or part of a system, and its environment,
showing the entities that interact with it. This diagram is a high level view of a system. It
represent all external entities that may interact with a system .In diagram pictures the system
at the center, with no details of its interior structure, surrounded by all its interacting systems,
environments and activities.

The objective of the system context diagram is to focus attention on external factors and
events that should be considered in developing a complete set of systems requirements and
constraints. System context diagrams are used early in a project to get agreement on the scope
under investigation.[4] Context diagrams are typically included in a requirements document.
These diagrams must be read by all project stakeholders and thus should be written in plain
language, so the stakeholders can understand items within the document. Context diagram for
ATM (fig1) and library(fig2) are as shown

7
Social and organizational factors:
 Software systems are used in a social and organizational context. This can influence
or even dominate the system requirements
 Social and organizational factors are not a single viewpoint but are influences on all
viewpoints
 Good analysts must be sensitive to these factors but currently no systematic way to
tackle their analysis

System Model

System modeling helps the analyst to understand the functionality of the system and
models are used to communicate with the customers.

Types of models are :

1. Data Flow Model

2. Semantic Model
3. Object Model

1. Data Flow Model : It shows how data is processed within a system based on inputs and
outputs. All data flow diagrams include four main elements: entity, process, data store and
data flow.

 Entity – Also known as actors, sources or sinks, and terminators. Entities produce
and consume data.
 Process – An activity that changes or transforms data flows.
 Data Store –simply holds data for later access.
 Data Flow – Movement of data between entities, processes and data stores is
represented with an arrow symbol, which indicates the direction of flow.

Notations of DFD:

8
Ex:DFD for ATM System:

Order processing DFD:

Checked and
Completed Signed Signed Send to signed order
order form order form order form supplier + order
Or der
notification
details + Complete Valida te Record
blank order form order order
order form Adjust
Order available
Signed budget
details order form
Order
amount
+ account
details
Orders Budget
file file

9
 2. Semantic model: Used to describe the logical structure of data processed by the
system. An entity-relation-attribute model sets out the entities in the system, the
relationships between these entities and the entity attributes .Widely used in database
design. Can readily be implemented using relational databases. The relationship can
be 1:1, 1:n, n:n among the entities. It consists of no.of notations like rectangles,
diamonds, ovals, arrow marks etc.

Notations used in Semantic Model:

ER diagram

10
Semantic model of library

3.Object model: Object models describe the system in terms of object classes and their
associations. An object class is an abstraction over a set of objects with common attributes
and the services (operations) provided by each object.

Object model notation

Various object models may be produced

a. Inheritance models;
b. Aggregation models;
c. Interaction models.

11
a)Inheritance Model: Organise the domain object classes into a hierarchy. Classes at the top
of the hierarchy reflect the common features of all classes. Object classes inherit their
attributes and services from one or more super-classes.

Example 1:

In this example, a Student is a type of Person. Likewise, a Employee is a type of Person. Both
Student and Employee inherit all the attributes and methods of Person. Student has a locally
defined student ID attribute. Employee has a locally defined employee ID attribute.So, if you
would look at a Student object, you would see attributes of name, date of birth, parents,
children, and student ID

Example 2:

Libr ary user

Name
Address
Phone
Registration #
Register ()
De-r egister ()

Reader Borrower
Affiliation Items on loan
Max. loans

Staff Student
Department Major subject
Department phone Home address

12
b)Object aggregation: Aggregation means collection of related items of the content so that
they can be linked. An aggregation model shows how classes that are collections are
composed of other classes. Aggregation models are similar to the part-of relationship in
semantic data models.

Example: 1:

c)Service Usage model: These presents more functional and data processing views which are
nothing but the services associated with the objects. Ex: Consider the library user,
issue/return, and library item and library staff. The services are register, deregister, acquire
catalog, etc. The block diagram is as shown

13
Requirement Definition:

Requirements are descriptions of the services that a software system must provide and
the constraints under which it must operate. It is a statement in natural language along with
the diagrams that represent services of the system.

Types of requirements:

1. Functional req.: Describes the system services or functions. How the system should
react to particular inputs and how should it behave in particular situations Ex: In a pen
s/m refill, topen, body are the functions and each functions has specific requirement
2. Non-functional req: Indicates the constraints placed on the system. They include
time constraints, development constraints, standard constraints etc. Ex: In a pen s/m
topen should not be big, the body should not e long etc are the constraints
Problems with Req. Definition:
Req. definition are written using natural language it has 3 problems
1. Lack of clarity: some times language fails to provide required clarity when proper
words are not used
2. Requirement confusion: Functional requirements, non-functional requirements, may
not be clearly distinguished.
3. Requirement Amalgamation: Several different requirement may be exposed as a
single requirement

Requirement Specification:
It adds further details to the requirement definitions. Usually presented with system
models which are developed during the requirement analysis. These models may define part
of the system to be developed. Requirement Specification is written using natural language
like English but this can be problematical.
Alternatives to Natural Language:
a) Structured natural language: consists of templates or standard forms
b) Design description language: It uses a language like programming language with
more abstract features
c) Req. specification language: These are special purpose languages designed to
express software requirements. Ex:PDL(Program Development Language),
RLS(Requirement Language Specification) etc
d) Graphical Notations: It contains complex notations to express s/w requirements. Ex:
SADT
e) Mathematical specifications: These notations are based on mathematical concepts
such as finite state machines. It uses set of theories, semantic notations to reduce the
ambiguity in requirement specification

14
Non-functional requirements

1. Define system properties and constraints e.g.reliability, response time and storage
requirements. Constraints are I/O device capability, system representations, etc.
2. Process requirements may also be specified mandating a particular CASE system,
programming language or development method
3. Non-functional requirements may be more critical than functional requirements. If
these are not met, the system is useless

Non-functional classifications

1. Product requirements
• Requirements which specify that the delivered product must behave in a
particular way e.g. execution speed, reliability, etc.
2. Organisational requirements
• Requirements which are a consequence of organisational policies and procedures
e.g. process standards used, implementation requirements, etc.
3. External requirements
• Requirements which arise from factors which are external to the system and its
development process e.g. interoperability requirements, legislative requirements,
etc.

15