Notes for MCA-I (Semester- I)

Subject :- Object Oriented Software Engineering

Requirement Engineering

Requirements Engineering (RE) refers to the process of defining,

documenting, and maintaining requirements in the engineering design process.
Requirement engineering provides the appropriate mechanism to understand
what the customer desires, analyzing the need, and assessing feasibility,
negotiating a reasonable solution, specifying the solution clearly, validating the
specifications and managing the requirements as they are transformed into a
working system. Thus, requirement engineering is the disciplined application of
proven principles, methods, tools, and notation to describe a proposed system's
intended behavior and its associated constraints.

The process to gather the software requirements from client, analyze and
document them is known as requirement engineering.
The goal of requirement engineering is to develop and maintain sophisticated
and descriptive ‘System Requirements Specification’ document.
Requirement Engineering Process

It is a four-step process, which includes -

1. Feasibility Study
2. Requirement Elicitation and Analysis
3. Software Requirement Specification
4. Software Requirement Validation
5. Software Requirement Management

Page 1
1. Feasibility Study:
The objective behind the feasibility study is to create the reasons for developing
the software that is acceptable to users, flexible to change and conformable to
established standards.

When the client approaches the organization for getting the desired product
developed, it comes up with rough idea about what all functions the software
must perform and which all features are expected from the software.

Referencing to this information, the analysts does a detailed study about

whether the desired system and its functionality are feasible to develop.

This feasibility study is focused towards goal of the organization. This study
analyzes whether the software product can be practically materialized in terms
of implementation, contribution of project to organization, cost constraints and

Page 2
as per values and objectives of the organization. It explores technical aspects of
the project and product such as usability, maintainability, productivity and
integration ability.

The output of this phase should be a feasibility study report that should contain
adequate comments and recommendations for management about whether or
not the project should be undertaken.

Types of Feasibility:

1. Technical Feasibility - Technical feasibility evaluates the current

technologies, which are needed to accomplish customer requirements
within the time and budget.
2. Operational Feasibility - Operational feasibility assesses the range in
which the required software performs a series of levels to solve business
problems and customer requirements.
3. Economic Feasibility - Economic feasibility decides whether the
necessary software can generate financial profits for an organization.

2. Requirement Elicitation and Analysis:

This is also known as the gathering of requirements. Here, requirements are
identified with the help of customers and existing systems processes, if
available.

Analysis of requirements starts with requirement elicitation. The requirements

are analyzed to identify inconsistencies, defects, omission, etc. We describe
requirements in terms of relationships and also resolve conflicts if any.

Problems of Elicitation and Analysis

o Getting all, and only, the right people involved.

o Stakeholders often don't know what they want
o Stakeholders express requirements in their terms.
o Stakeholders may have conflicting requirements.
o Requirement change during the analysis process.
o Organizational and political factors may influence system requirements.

Page 3
Requirement elicitation process can be depicted using the following diagram:
Page 4
 Requirements gathering - The developers discuss with the client and
end users and know their expectations from the software.
 Organizing Requirements - The developers prioritize and arrange the
requirements in order of importance, urgency and convenience.
 Negotiation & discussion - If requirements are ambiguous or there are
some conflicts in requirements of various stakeholders, if they are, it is
then negotiated and discussed with stakeholders. Requirements may then
be prioritized and reasonably compromised.
The requirements come from various stakeholders. To remove the
ambiguity and conflicts, they are discussed for clarity and correctness.
Unrealistic requirements are compromised reasonably.

 Documentation - All formal & informal, functional and non-functional

requirements are documented and made available for next phase
processing.

Page 5
Requirement Elicitation Techniques
Requirements Elicitation is the process to find out the requirements for an
intended software system by communicating with client, end users, system users
and others who have a stake in the software system development.
There are various ways to discover requirements
Interviews
Interviews are strong medium to collect requirements. Organization may
conduct several types of interviews such as:
 Structured (closed) interviews, where every single information to gather
is decided in advance, they follow pattern and matter of discussion
firmly.
 Non-structured (open) interviews, where information to gather is not
decided in advance, more flexible and less biased.
 Oral interviews
 Written interviews
 One-to-one interviews which are held between two persons across the
table.
 Group interviews which are held between groups of participants. They
help to uncover any missing requirement as numerous people are
involved.
Surveys
Organization may conduct surveys among various stakeholders by querying
about their expectation and requirements from the upcoming system.
Questionnaires
A document with pre-defined set of objective questions and respective options
is handed over to all stakeholders to answer, which are collected and compiled.
A shortcoming of this technique is, if an option for some issue is not mentioned
in the questionnaire, the issue might be left unattended.

Page 6
Task analysis
Team of engineers and developers may analyze the operation for which the new
system is required. If the client already has some software to perform certain
operation, it is studied and requirements of proposed system are collected.

Domain Analysis
Every software falls into some domain category. The expert people in the
domain can be a great help to analyze general and specific requirements.
Brainstorming
An informal debate is held among various stakeholders and all their inputs are
recorded for further requirements analysis.
Prototyping
Prototyping is building user interface without adding detail functionality for
user to interpret the features of intended software product. It helps giving better
idea of requirements. If there is no software installed at client’s end for
developer’s reference and the client is not aware of its own requirements, the
developer creates a prototype based on initially mentioned requirements. The
prototype is shown to the client and the feedback is noted. The client feedback
serves as an input for requirement gathering.
Observation
Team of experts visit the client’s organization or workplace. They observe the
actual working of the existing installed systems. They observe the workflow at
client’s end and how execution problems are dealt. The team itself draws some
conclusions which aid to form requirements expected from the software.
Software Requirement Specification (SRS) :

Software requirement specification is a kind of document which is created by a

software analyst after the requirements collected from the various sources - the
requirement received by the customer written in ordinary language. It is the job
of the analyst to write the requirement in technical language so that they can be
understood and beneficial by the development team.

When the client approaches the organization for getting the desired product
developed, it comes up with rough idea about what all functions the software
must perform and which all features are expected from the software.

Page 7
Referencing to this information, the analysts does a detailed study about
whether the desired system and its functionality are feasible to develop.

This feasibility study is focused towards goal of the organization. This study
analyzes whether the software product can be practically materialized in terms
of implementation, contribution of project to organization, cost constraints and
as per values and objectives of the organization. It explores technical aspects of
the project and product such as usability, maintainability, productivity and
integration ability.

The output of this phase should be a feasibility study report that should contain
adequate comments and recommendations for management about whether or
not the project should be undertaken.

The models used at this stage include ER diagrams, data flow diagrams (DFDs),
function decomposition diagrams (FDDs), data dictionaries, etc.

o Data Flow Diagrams: Data Flow Diagrams (DFDs) are used widely for
modeling the requirements. DFD shows the flow of data through a
system. The system may be a company, an organization, a set of
procedures, a computer hardware system, a software system, or any
combination of the preceding. The DFD is also known as a data flow
graph or bubble chart.
o Data Dictionaries: Data Dictionaries are simply repositories to store
information about all data items defined in DFDs. At the requirements
stage, the data dictionary should at least define customer data items, to
ensure that the customer and developers use the same definition and
terminologies.
o Entity-Relationship Diagrams: Another tool for requirement
specification is the entity-relationship diagram, often called an "E-R
diagram." It is a detailed logical representation of the data for the
organization and uses three main constructs i.e. data entities,
relationships, and their associated attributes.

Software Requirement Validation:

After requirement specifications developed, the requirements discussed in this

document are validated. The user might demand illegal, impossible solution or
experts may misinterpret the needs.

Page 8
After requirement specifications are developed, the requirements mentioned in
this document are validated. User might ask for illegal, impractical solution or
experts may interpret the requirements incorrectly. This results in huge increase
in cost if not nipped in the bud. Requirements can be checked against following
conditions -

 If they can be practically implemented

 If they are valid and as per functionality and domain of software
 If there are any ambiguities
 If they are complete
 If they can be demonstrated

Requirements Validation Techniques

o Requirements reviews/inspections: systematic manual analysis of the

requirements.
o Prototyping: Using an executable model of the system to check
requirements.
o Test-case generation: Developing tests for requirements to check
testability.
o Automated consistency analysis: checking for the consistency of
structured requirements descriptions.

Software Requirement Management:

Requirement management is the process of managing changing requirements

during the requirements engineering process and system development.

New requirements emerge during the process as business needs a change, and a
better understanding of the system is developed.

The priority of requirements from different viewpoints changes during

development process.

The business and technical environment of the system changes during the
development.

Page 9
Software Requirements Characteristics
Gathering software requirements is the foundation of the entire software
development project. Hence they must be clear, correct and well-defined.
A complete Software Requirement Specifications must be:
 Clear
 Correct
 Consistent
 Coherent
 Comprehensible (understandable)
 Modifiable
 Verifiable
 Prioritized
 Unambiguous
 Traceable
 Credible source

Prerequisite of Software requirements

Collection of software requirements is the basis of the entire software

development project. Hence they should be clear, correct, and well-defined.

A complete Software Requirement Specifications should be:

o Clear
o Correct
o Consistent
o Coherent
o Comprehensible (understandable)
o Modifiable
o Verifiable
Page 10
 o Prioritized
o Unambiguous
o Traceable
o Credible source
o User Interface requirements
o UI is an important part of any software or hardware or hybrid system. A
software is widely accepted if it is -
o easy to operate
o quick in response
o effectively handling operational errors
o providing simple yet consistent user interface
o User acceptance majorly depends upon how user can use the software. UI
is the only way for users to perceive the system. A well performing
software system must also be equipped with attractive, clear, consistent
and responsive user interface. Otherwise the functionalities of software
system can not be used in convenient way. A system is said be good if it
provides means to use it efficiently. User interface requirements are
briefly mentioned below -
o Content presentation
o Easy Navigation
o Simple interface
o Responsive
o Consistent UI elements
o Feedback mechanism
o Default settings
o Purposeful layout
o Strategically use of color and texture.
o Provide help information
o User centric approach
o Group based view settings.

Software Requirements: Largely software requirements must be categorized

into two categories:

1. Functional Requirements: Functional requirements define a function

that a system or system element must be qualified to perform and must be

Page 11
 documented in different forms. The functional requirements are
describing the behavior of the system as it correlates to the system's
functionality.

Requirements, which are related to functional aspect of software fall into

this category.

They define functions and functionality within and from the software
system.

Examples -

 Search option given to user to search from various invoices.

 User should be able to mail any report to management.
 Users can be divided into groups and groups can be given separate rights.
 Should comply business rules and administrative functions.
 Software is developed keeping downward compatibility intact.

2. Non-functional Requirements: This can be the necessities that specify

the criteria that can be used to decide the operation instead of specific
behaviors of the system.

Non-functional requirements are divided into two main categories:

o Execution qualities like security and usability, which are

observable at run time.
o Evolution qualities like testability, maintainability, extensibility,
and scalability that embodied in the static structure of the software
system.

Requirements, which are not related to functional aspect of software, fall into
this category. They are implicit or expected characteristics of software, which
users make assumption of.

Non-functional requirements include -

 Security
 Logging
 Storage

Page 12
  Configuration
 Performance
 Cost
 Interoperability
 Flexibility
 Disaster recovery
 Accessibility
Requirements are categorized logically as
 Must Have : Software cannot be said operational without them.
 Should have : Enhancing the functionality of software.
 Could have : Software can still properly function with these
requirements.
 Wish list : These requirements do not map to any objectives of software.

While developing software, ‘Must have’ must be implemented, ‘Should have’ is

a matter of debate with stakeholders and negation, whereas ‘could have’ and
‘wish list’ can be kept for software updates.

Four Phases of Requirement Engineering:-

Requirement Engineering is the process of defining, documenting and
maintaining the requirements. It is a process of gathering and defining service
provided by the system. Requirements Engineering Process consists of the
following main activities:

 Requirements elicitation
 Requirements specification
 Requirements verification and validation
 Requirements management

Requirements Elicitation:

It is related to the various ways used to gain knowledge about the project
domain and requirements. The various sources of domain knowledge include
customers, business manuals, the existing software of same type, standards and
other stakeholders of the project.
The techniques used for requirements elicitation include interviews,
brainstorming, task analysis, Delphi technique, prototyping, Elicitation does not
produce formal models of the requirements understood. Instead, it widens the
domain knowledge of the analyst and thus helps in providing input to the next
stage.

Page 13
Requirements Specification:

This activity is used to produce formal software requirement models. All the
requirements including the functional as well as the non-functional
requirements and the constraints are specified by these models in totality.
During specification, more knowledge about the problem may be required
which can again trigger the elicitation process.
The models used at this stage include ER diagrams, data flow diagrams(DFDs),
function decomposition diagrams(FDDs), data dictionaries, etc.

Requirements verification and validation:

Verification:

It refers to the set of tasks that ensures that the software correctly implements a
specific function.

Validation: It refers to a different set of tasks that ensures that the software that
has been built is traceable to customer requirements.
If requirements are not validated, errors in the requirement definitions would
propagate to the successive stages resulting in a lot of modification and rework.
The main steps for this process include:
 The requirements should be consistent with all the other requirements i.e
no two requirements should conflict with each other.
 The requirements should be complete in every sense.
 The requirements should be practically achievable.
Reviews, buddy checks, making test cases, etc. are some of the methods used
for this.

Requirements Management :-
Requirement management is the process of analyzing, documenting, tracking,
prioritizing and agreeing on the requirement and controlling the communication
to relevant stakeholders. This stage takes care of the changing nature of
requirements. It should be ensured that the SRS is as modifiable as possible so
as to incorporate changes in requirements specified by the end users at later
stages too. Being able to modify the software as per requirements in a

Page 14
systematic and controlled manner is an extremely important part of the
requirements engineering process.

Structure and Content of SRS :-

A software requirements specification (SRS) is a description of a software
system to be developed. It is modeled after business requirements
specification , also known as a stakeholder requirements specification .The
software requirements specification lays out functional and non-functional
requirements, and it may include a set of use cases that describe user
interactions that the software must provide to the user for perfect interaction.
Software requirements specification establishes the basis for an agreement
between customers and contractors or suppliers on how the software product
should function. Software requirements specification is a rigorous assessment of
requirements before the more specific system design stages, and its goal is to
reduce later redesign. It should also provide a realistic basis for estimating
product costs, risks, and schedules. Used appropriately, software requirements
specifications can help prevent software project failure.
The software requirements specification document lists sufficient and necessary
requirements for the project development. To derive the requirements, the
developer needs to have clear and thorough understanding of the products under
development. This is achieved through detailed and continuous communications
with the project team and customer throughout the software development
process
An example organization of an SRS is as follows:
1. Purpose
1. Definitions
2. Background
3. System overview
4. References
2. Overall description
1. Product perspective
1. System Interfaces
2. User interfaces
3. Hardware interfaces
4. Software interfaces
5. Communication Interfaces
6. Memory constraints
2. Design constraints
1. Operations
2. Site adaptation requirements

Page 15
 3. Product functions
4. User characteristics
5. Constraints, assumptions and dependencies
3. Specific requirements
1. External interface requirements
2. Performance requirements
3. Logical database requirement
4. Software system attributes
1. Reliability
2. Availability
3. Security
4. Maintainability
5. Portability
5. Functional requirements
1. Functional partitioning
2. Functional description
3. Control description
6. Environment characteristics
1. Hardware
2. Peripherals
3. Users
7. Other

A Software Requirements Specification (SRS) is a document that describes the

nature of a project, software or application. In simple words, SRS document is a
manual of a project provided it is prepared before you kick-start a
project/application. This document is also known by the names SRS report,
software document. A software document is primarily prepared for a project,
software or any kind of application.
There are a set of guidelines to be followed while preparing the software
requirement specification document. This includes the purpose, scope,
functional and nonfunctional requirements, software and hardware requirements
of the project. In addition to this, it also contains the information about
environmental conditions required, safety and security requirements, software
quality attributes of the project etc.

A Software requirements specification document describes the intended

purpose, requirements and nature of software to be developed. It also includes
the yield and cost of the software.

Page 16
In this document, flight management project is used as an example to explain
few points.

Table of Contents

Page 17
1. INTRODUCTION
1.1 PURPOSE
The purpose of this document is to build an online system to manage flights and
passengers to ease the flight management. <<Include the purpose as applicable to
your project >>

Page 18
1.2 DOCUMENT CONVENTIONS
This document uses the following conventions. <<Include the conventions as per
your application >>

DB Database

DDB Distributed Database

ER Entity Relationship

1.3 INTENDED AUDIENCE AND READING SUGGESTIONS

This project is a prototype for the flight management system and it is restricted within
the college premises. This has been implemented under the guidance of college
professors. This project is useful for the flight management team and as well as to
the passengers.

1.4 PROJECT SCOPE

The purpose of the online flight management system is to ease flight management
and to create a convenient and easy-to-use application for passengers, trying to buy
airline tickets. The system is based on a relational database with its flight
management and reservation functions. We will have a database server supporting
hundreds of major cities around the world as well as thousands of flights by various
airline companies. Above all, we hope to provide a comfortable user experience
along with the best pricing available.

1.5 REFERENCES
www.irtc.co.in
www.airindia.com

2. OVERALL DESCRIPTION
2.1 PRODUCT PERSPECTIVE
A distributed airline database system stores the following information.
 Flight details:

It includes the originating flight terminal and destination terminal, along
with the stops in between, the number of seats booked/available seats
between two destinations etc.

 Customer description:

Page 19
 It includes customer code, name, address and phone number. This
information may be used for keeping the records of the customer for any
emergency or for any other kind of information.

 Reservation description:

It includes customer details, code number, flight number, date of booking,

date of travel.

2.2 PRODUCT FEATURES

The major features of airline database system as shown in below entity–
relationship model (ER model)

Page 20
The diagram shows the layout of airline database system – entity–relationship
model

2.3 USER CLASS and CHARACTERISTICS

Page 21
Users of the system should be able to retrieve flight information between two
given cities with the given date/time of travel from the database. A route from
city A to city B is a sequence of connecting flights from A to B such that: a)
there are at most two connecting stops, excluding the starting city and
destination city of the trip, b) the connecting time is between one to two hours.
The system will support two types of user privileges, Customer, and Employee.
Customers will have access to customer functions, and the employees will have
access to both customer and flight management functions. The customer should
be able to do the following functions:
 Make a new reservation

• One-way

• Round-Trip

• Multi-city

• Flexible Date/time

• Confirmation

 Cancel an existing reservation

 View his itinerary

The Employee should have following management functionalities:

 CUSTOMER FUNCTIONS.

• Get all customers who have seats reserved on a given flight.

• Get all flights for a given airport.

• View flight schedule.

• Get all flights whose arrival and departure times are on time/delayed.

• Calculate total sales for a given flight.

 ADMINISTRATIVE

Page 22
 • Add/Delete a flight

• Add a new airport

• Update fare for flights.

• Add a new flight leg instance.

• Update departure/arrival times for flight leg instances.

Each flight has a limited number of available seats. There are a number of
flights which depart from or arrive at different cities on different dates and time.

2.4 OPERATING ENVIRONMENT

Operating environment for the airline management system is as listed below.
<<Include the details as per your application >>
 distributed database
 client/server system
 Operating system: Windows.
 database: sql+ database
 platform: vb.net/Java/PHP
2.5 DESIGN and IMPLEMENTATION CONSTRAINTS
1. The global schema, fragmentation schema, and allocation schema.
2. SQL commands for above queries/applications
3. How the response for application 1 and 2 will be generated. Assuming
these are global queries. Explain how various fragments will be combined
to do so.
4. Implement the database at least using a centralized database management
system.
2.6 ASSUMPTION DEPENDENCIES
Let us assume that this is a distributed airline management system and it is used
in the following application:
 A request for booking/cancellation of a flight from any source to any
destination, giving connected flights in case no direct flight between the
specified Source-Destination pair exist.
 Calculation of high fliers (most frequent fliers) and calculating
appropriate reward points for these fliers.
Assuming both the transactions are single transactions, we have designed a
distributed database that is geographically dispersed at four cities Delhi,
Mumbai, Chennai, and Kolkatta as shown in fig. below.

Page 23
3. SYSTEM FEATURES
 DESCRIPTION and PRIORITY
The airline reservation system maintains information on flights, classes of seats,
personal preferences, prices, and bookings. Of course, this project has a high
priority because it is very difficult to travel across countries without prior
reservations.
 STIMULUS/RESPONSE SEQUENCES
 Search for Airline Flights for two Travel cities
 Displays a detailed list of available flights and make a
“Reservation” or Book a ticket on a particular flight.
 Cancel an existing Reservation.
 FUNCTIONAL REQUIREMENTS
Other system features include:
DISTRIBUTED DATABASE:
Distributed database implies that a single application should be able to operate
transparently on data that is spread across a variety of different databases and
connected by a communication network as shown in below figure.

Distributed database located in four different cities

CLIENT/SERVER SYSTEM
Page 24
The term client/server refers primarily to an architecture or logical division of
responsibilities, the client is the application (also known as the front-end), and
the server is the DBMS (also known as the back-end).
A client/server system is a distributed system in which,
 Some sites are client sites and others are server sites.
 All the data resides at the server sites.
 All applications execute at the client sites.

4. EXTERNAL INTERFACE REQUIREMENTS

4.1 USER INTERFACES
 Front-end software: Vb.net version
 Back-end software: SQL+
4.2 HARDWARE INTERFACES
 Windows.
 A browser which supports CGI, HTML & Javascript.
4.3 SOFTWARE INTERFACES
Following are the software used for the flight management online application.
<<Include the software details as per your project >>
Software used Description

We have chosen Windows operating system for its

Operating system best support and user-friendliness.

To save the flight records, passengers records we

Database have chosen SQL+ database.

To implement the project we have chosen Vb.Net

VB.Net language for its more interactive support.

4.4 COMMUNICATION INTERFACES

This project supports all types of web browsers. We are using simple electronic
forms for the reservation forms, ticket booking etc.

Page 25
5. NONFUNCTIONAL REQUIREMENTS
5.1 PERFORMANCE REQUIREMENTS
The steps involved to perform the implementation of airline database are as
listed below.
A) E-R DIAGRAM
The E-R Diagram constitutes a technique for representing the logical structure
of a database in a pictorial manner. This analysis is then used to organize data as
a relation, normalizing relation and finally obtaining a relation database.
 ENTITIES: Which specify distinct real-world items in an application.
 PROPERTIES/ATTRIBUTES: Which specify properties of an entity
and relationships.
 RELATIONSHIPS: Which connect entities and represent meaningful
dependencies between them.

The diagram shows the ER diagram of airline database

Page 26
B) NORMALIZATION:
The basic objective of normalization is to reduce redundancy which means that
information is to be stored only once. Storing information several times leads to
wastage of storage space and increase in the total size of the data stored.
If a database is not properly designed it can give rise to modification anomalies.
Modification anomalies arise when data is added to, changed or deleted from a
database table. Similarly, in traditional databases as well as improperly designed
relational databases, data redundancy can be a problem. These can be
eliminated by normalizing a database.
Normalization is the process of breaking down a table into smaller tables. So
that each table deals with a single theme. There are three different kinds of
modifications of anomalies and formulated the first, second and third normal
forms (3NF) is considered sufficient for most practical purposes. It should be
considered only after a thorough analysis and complete understanding of its
implications.

5.2 SAFETY REQUIREMENTS

If there is extensive damage to a wide portion of the database due to
catastrophic failure, such as a disk crash, the recovery method restores a past
copy of the database that was backed up to archival storage (typically tape) and
reconstructs a more current state by reapplying or redoing the operations of
committed transactions from the backed up log, up to the time of failure.

5.3 SECURITY REQUIREMENTS

Security systems need database storage just like many other applications.
However, the special requirements of the security market mean that vendors
must choose their database partner carefully.

5.4 SOFTWARE QUALITY ATTRIBUTES

 AVAILABILITY: The flight should be available on the specified date
and specified time as many customers are doing advance reservations.
 CORRECTNESS: The flight should reach start from correct start
terminal and should reach the correct destination.
 MAINTAINABILITY: The administrators and flight in chargers should
maintain correct schedules of flights.
 USABILITY: The flight schedules should satisfy a maximum number of
customers needs.

IEEE Standard format :-

1.Overview

Page 27
 1.1 Scope
2. Reference

3. Definition
3.1 Contract
3.2 Customer
3.3 Supplier
3.4 User

4. Consideration of producing good SRS

4.1 Nature of SRS (Functionality, External Interface, Performance,
Attributes, Design Constraints)
4.2 Environment of SRS

4.3 Characteristics of good SRS (Correct, Complete, consistent

, unambiguous, verifiable, Modifiable , Traceable )
4.4 Prototyping
4.5 Design in SRS
4.6 Project requirement in SRS
5. Parts of an SRS
5.1 Introduction
5.1.1 Purpose
5.1.2 Scope
5.1.3 Definition
5.1.4 References
5.1.5 Overview
5.2 Overall description
5.2.1 Product Perspective
5.2.2 System Interface
5.2.3 User Interface
5.2.4 Hardware Interface
5.2.5 Software Interface
5.2.6 Communication Interfaces (e.g. local network protocols)
5.3 Specific Requirement
5.3.1 External Interface
5.3.2 Functions
5.3.3 Performance Requirement
5.3.4 Logical Database Requirement
5.3.5 Design Constraints
5.3.6 Software System Attribute
Page 28
 5.3.6.1 Reliability
5.3.6.2 Availability
5.3.6.3 Security
5.3.6.4 Maintainability
5.3.6.5 Portability
5.3.7 Organizing the specific requirement
5.3.7.1 System Mode
5.3.7.2 User Class
5.3.7.3 Object
5.3.7.4 Feature
5.3.7.5 Stimulus
5.3.7.6 Response
5.3.7.7 Functional Hierarchy
5.3.8 Additional Comment
5.4 Supporting Information
5.4.1 Table of Content & Index
5.4.2 Appendixes

Note :-
 User Interface: - The logical characteristics of each interface between
the software product and its users. All the aspects of optimizing the
interface with the person who must use the system

 Hardware Interface: This should specify the logical characteristics of

each interface between the software product and the hardware
components of the system. This includes configuration characteristics
(number of ports, instruction sets, etc.). It also covers such matters as
what devices are to be supported, how they are to be supported, and
protocols. For example, terminal support may specify full-screen support
as opposed to line-by-line support.

 Software interfaces
This should specify the use of other required software products (e.g., a data
management system, an operating system, or a mathematical package), and
interfaces with other application systems (e.g., the linkage between an accounts
receivable system and a general ledger system). For each required software
product

following should be provided:

- Name;
- Mnemonic;
Page 29
- Specification number;
- Version number;
- Source.

 Logical database requirements

This should specify the logical requirements for any information that is to be
placed into a database. This may include the following:

a) Types of information used by various functions;

b) Frequency of use;
c) Accessing capabilities;
d) Data entities and their relationships;
e) Integrity constraints;
f) Data retention requirements

 System mode :- Some systems behave quite differently depending on the

mode of operation. For example, a control system may have different sets
of functions depending on its mode: training, normal, or emergency. The
choice depends on whether interfaces and performance are dependent on
mode.
 User class
Some systems provide different sets of functions to different classes of users.
For example, an elevator control system presents different capabilities to
passengers, maintenance workers, and fire fighters.
 Objects
Objects are real-world entities that have a counterpart within the system. For
example, in a patient monitoring system, objects include patients, sensors,
nurses, rooms, physicians, medicines, etc. Associated with each object is a set
of attributes (of that object) and functions (performed by that object). These
functions are also called services, methods, or processes
 Stimulus
Some systems can be best organized by describing their functions in terms of
stimuli. For example, the functions of an automatic aircraft landing system may
be organized into sections for loss of power, wind shear sudden change in roll,
vertical velocity excessive, etc
 Response
Some systems can be best organized by describing all the functions in support
of the generation of a response. For example, the functions of a personnel
system may be organized into sections corresponding to all functions associated
Page 30
with generating paychecks, all functions associated with generating a current
list of employees, etc.

 Functional hierarchy
When none of the above organizational schemes prove helpful, the overall
functionality can be organized into a hierarchy of functions organized by either
common inputs, common outputs, or common internal data access. Data flow
diagrams and data dictionaries can be used to show the relationships between
and among the functions and data.

(Another) SRS Format With IEEE Standard :-

1. Introduction
a. Background
b. Overall Description
c. Environmental Characteristics
i. Hardware
ii. Peripherals
iii. People
d. Interfaces
i. Interface with Device
ii. Interface with OS
iii. Interface with Database used
iv. Interface with the user
e. Constraints

2. Functional Requirements
a. Functional Partitioning
b. Functional Description
c. Control Description
3. Non Functional Requirements

4. Behavioral Description
a. System State
b. Event &Action

5. Validation Criteria
a. Performance Bound
b. Classes of Test
c. Response to undesired events

Page 31
Page 32