__________________________________________________________________

1.0 DOCUMENT CONTROL

Author / Owner Reviewer Authoriser

Signature

Name Purnima Menon Shrikant Brahme Raj Dhillon

Designation SEPG Head – SEPG Management Representative

2.0 INTRODUCTION

Preparing the Requirements Specification is a key software life cycle event, for all turnkey
software projects executed by ZENSAR. The customer may ask ZENSAR to prepare a
Requirements Specification or the customer could supply the Requirements Specification.

3.0 OBJECTIVE

The objective of this document is to provide a guideline to arrive at a Requirements

Specification which is unambiguous, complete as far as possible, verifiable, modifiable,
traceable and usable during the development of software or maintenance of installed turnkey
software or already existing software.

4.0 SCOPE

This format applies to all Requirements Specification documents, unless otherwise a separate
standard is explicitly specified by the customer.

The purpose of the project

User problem or background of the project effort
In existing system what kind of problems faced by the user and background work done by the
client.
Goals of the project
It should includes what exactly wants to achieve from this system by keeping that goal in
mind implementation should be done.

Technology Used:

Software and Hardware Requirements:

_________________________________________________________________
__________________________________________________________________

iii) User of the product

Hands on users – people who operate the product and number of simultaneous users
Priorities assigned to users
User participation – an estimate of needed involvement in the project
User classes may vary as an end-user, super user or administrator with there specific
characteristics.
iv) Benefit
Here, will describe the details of who is the beneficiary of this system that may be client
perspective, administration point of view, end-user point of view, planner point of view or
etc.
v) Limitations
Limitations of the system in terms of number of transactions, batch processing, hardware
configuration and etc.
vi) Critical success factors
In order to make development successful, enlist the critical factors and taken into
consideration while going through software development life cycle.

2) Architecture about flow of the system

It would deals with what way data is to be processed and information has to be passed to the
destination through bridges, routers or hub etc.

3) Project constraints
i) Mandated constraint
Solution design constraint
Implementation environment of the current system
Partner or collaborative applications to be used by the product
Off the shelf software used within the product
Anticipated workplace environment
Project duration budget
Financial budget for the project
ii) Relevant Facts, Assumptions and Dependencies
Factors that have an effect on the product but are not mandated requirements
iii) Constraints
Assumption the team is making about the project

46.7 System Objectives

The system objectives should cover the business objectives and the quality objectives, as far
as possible in full detail and in measurable terms.

This process tries to ensure that all aspects necessary to satisfy the customer's need regarding
the deliverable software and associated accessories are defined and/or mentioned. All such
objectives could be addressed in this section.

As a guideline to write these objectives, the following points must be considered:

a) Functional requirements:

_________________________________________________________________
__________________________________________________________________

i) Functionality - A set of attributes characterising what the software

does to fulfil the user's functional needs. Each functional requirement
should be stated in terms of input and output and the needed
transformation, as seen by the user.
ii) Interoperability - Ability to interact with specified systems as
mentioned in the section System Interfaces later in this standard.
iii) Compliance - Adherence to application related standards, conventions
or regulations.
Data requirements
Volumes of data, normalization, etc

5b) Reliability requirements:

i) Fault tolerance - Ability to maintain a specified level of performance in

case of software faults or of infringement of its specified interface. Fail
safe capability.
ii) Recoverability - Capability to re-establish its level of performance and
recover the data directly affected in case of a failure.
iii) Load / Stress – Requirements to evaluate a system or component at or
beyond the limits of its specified boundaries.
c) Usability

i) Understandability - User's effort for recognising the logical concept

and its applicability.
ii) Learnability - User's effort for learning the application.
iii) Operability - User's effort for operation of the application and
operational control.
d) Efficiency:

i) Time behaviour - Response and processing time and throughput rates.

ii) Resource behaviour - Amount of resources used.

e) Performance

i) Performance in terms of response time, number of simultaneous users,

administration efforts etc
Non-Functional Requirements
Look and feel requirements
Look and feel of screens and sub screens
User interfaces
o GUI screen layout / Screen Transitions
It should consist all types of screen layouts.
o GUI report layout
It should consist all types of report layouts
Interface appearance
How it looks like.
Usability and Humanity Requirements

_________________________________________________________________
__________________________________________________________________
i) Understandability - User's effort for recognising the logical concept
and its applicability.
ii) Learnability - User's effort for learning the application.
iii) Operability - User's effort for operation of the application and
operational control.

Ease of use
Personalization and Internationalization requirements
Ease of learning
Accessibility requirements
Performance requirements
Response time requirement
Speed and latency requirements
Safety critical requirements
Precision requirements
Reliability and availability requirements
i) Fault tolerance - Ability to maintain a specified level of performance
in case of software faults or of infringement of its specified interface.
Fail safe capability.
iv) Recoverability - Capability to re-establish its level of performance and
recover the data directly affected in case of a failure.
v) Load / Stress – Requirements to evaluate a system or component at or
beyond the limits of its specified boundaries.

Robustness requirements
Capacity requirements
Scalability or extensibility requirements
Operational requirements
Expected physical environment
What kind of hardware configuration to be used for development and testing and which
operating system and software to be used for development.
Expected technological environment
Partner applications
Productization requirements
Maintainability and support requirements
Maintenance requirements
Special conditions for maintenance
Supportability
Adaptability requirements
Security requirements
Access requirements
Integrity requirements
Privacy requirements
Audit requirements
Immunity requirements (temporary or permanent security requirement)

New problems
New problems caused by installing the product in the current environment
Affects on the installed system
_________________________________________________________________
__________________________________________________________________
Adverse effects on existing users
Limitations of the anticipated implementation environment
Other problems
Tasks
Steps to be taken to deliver the product
Development phases
Risks
Pertaining to market risk, credit risk and operational risk.
Costs

Database Design:

6.2 Glossary

The Glossary of Terms should contain a list of all the acronyms used in the Requirements
Specification. Barring standard terminology already accepted between ZENSAR and the
customer, all new or ambiguous terminology must be explained sufficiently so as to prevent
multiple interpretations, provide only a unique interpretation and ensure that there are no
semantic or syntactic variations across the document. If possible, synonyms, simple phrases,
analogies or references to related standard terminology, which is widely accepted, should be
used.

_________________________________________________________________