<Client Logo> <Client Name> <Client Location>

<Name of the Project>

Software Requirements Specifications

Version <nn.rr>

< month year>

Warning <# Normal instruction from QMS template to be included>

<Name of the Project>

Software Requirements Specifications ver.<nn.rr>

DOCUMENT RELEASE NOTICE

Document Details: Name Software Requirements Specifications Revision Details Action taken (Add/Del/Change) Preceding Page No. New Page No. Revision Description Version No. <nn.rr> Description SRS document for <name of the project> of <client name>

This document and any revised pages are subject to document control. Please keep them upto-date using the release notices from the distributor of the document. Approved by: Authorised by: Date: Date:

Internal Use Only

<Name of the Project>

Software Requirements Specifications ver.<nn.rr>

TABLE OF CONTENTS 1. INTRODUCTION.................................................................................................................. 1 1.1 PURPOSE.......................................................................................................................... 1 1.2 SCOPE.............................................................................................................................. 1 1.3 DEFINITIONS, ACRONYMS AND ABBREVIATIONS...................................................................2 1.4 REFERENCES.................................................................................................................... 2 1.5 OVERVIEW........................................................................................................................ 2 2. GENERAL REQUIREMENTS............................................................................................... 3 2.1 PRODUCT PERSPECTIVE.................................................................................................... 3 2.1.1 System Interface....................................................................................................... 3 2.1.2 User Interface........................................................................................................... 4 2.1.3 Hardware Interface................................................................................................... 4 2.1.4 Software Interface.................................................................................................... 4 2.1.5 Communication Interface..........................................................................................5 2.1.6 Memory Constraints.................................................................................................5 2.1.7 Operations................................................................................................................ 5 2.1.8 Site Adaptation requirements...................................................................................5 2.2 PRODUCT FUNCTIONS........................................................................................................ 5 2.3 USER CHARACTERISTICS................................................................................................... 5 2.4 CONSTRAINTS................................................................................................................... 5 2.5 ASSUMPTIONS AND DEPENDANCIES....................................................................................5 2.6 PRIORATISING OF THE REQUIREMENTS...............................................................................5 3. SPECIFIC REQUIREMENTS................................................................................................ 6 3.1 EXTERNAL INTERFACES..................................................................................................... 6 3.2 FUNCTIONS....................................................................................................................... 6 3.3 PERFORMANCE REQUIREMENTS......................................................................................... 6 3.4 LOGICAL DATABASE REQUIREMENTS..................................................................................6 3.5 DESIGN CONSTRAINTS....................................................................................................... 6 3.6 SOFTWARE SYSTEM ATTRIBUTES........................................................................................ 7 3.7 ORGANIZING THE SPECIFIC REQUIREMENTS........................................................................7 3.8 ADDITIONAL COMMENTS ................................................................................................... 7 4. APPENDIX............................................................................................................................ 8 5. INDEX................................................................................................................................. 10 Total Number of pages: 14 <To update the number, right-click on it and select Update Field. It will insert the actual number of pages in the document>

Internal Use Only

ii

<Name of the Project>

Software Requirements Specifications ver.<nn.rr>

1. Introduction
1.1 Purpose
<Describe the purpose of the SRS and intended audienece for the SRS. Describe the client details>

1.2 Scope
<Describe in high-level terms the agreed scope of the project. Make a reference to the relevant section in the proposal/contract/agreement wherein the objectives and the scope of the application is defined and include the same in this document> <Include the following: Software product(s) to be produced by name (e.g. Host DBMS, Report Generator, etc) Key functionality (including the Statutory and Regulatory requirements) that will be provided at all levels (e.g. corporate, regional, etc.) Functionality that will not be supported, if necessary by the product(s) Areas that are excluded from the proposal Geography (e.g. local/global) Target systems that will be replaced by proposed development Projected impact on existing applications (e.g. bridging requirement) Impact on customers, suppliers, third party interfaces >

Internal Use Only

<Name of the Project>

Software Requirements Specifications ver.<nn.rr>

1.3 Definitions, Acronyms and Abbreviations

<All the terms used in the application must be defined in a clear manner in the definitions. The objective of this is to have in one place common and clear definitions of all the terms. > The following abbreviations and Acronyms have been used in this document. <Please list in alphabetical order> Abbreviation/Acronym Description

1.4 References
<Identify each referenced document by title, version or date and publishing organisation> <Reference of important correspondence should also be mentioned> <Refer to all the documents, which need to be looked into for better understanding of this document. For example. The following documents have been referred to for preparation of this SRS document: 1. Technical Proposal for the study 2. Contract document 3. Any other document >

1.5 Overview
<Brief details for all sections of document and how they have organized > < For e.g. This document consists of <X> sections and <Y> appendices. Section 1 Section 2 >

Internal Use Only

<Name of the Project>

Software Requirements Specifications ver.<nn.rr>

2. General Requirements
2.1 Product Perspective
< Describe how the product operates inside various constraints. A block diagram showing major components of the large system, interconnections and external interfaces. Identify the main processes to be automated as process P1, P2, etc. Draw the overall process map for these main processes and the sub-processes within these. The sub-processes can be identified as P1.1, P1.2, etc.> <A sample Process Map is given below.>

P1 Litigation

P2 Trademark & Copyright Process

P3 Patency P4 Designing

Database

EDP Staff

Accounts

Figure 2-1: Name of process

2.1.1 System Interface

<Describe in high level terms the requirements for integrating with other systems. Briefly define the messages/interfaces that need to be processed between the systems. Describe in high level terms the requirements for electronic trading with third parties, such as customers, statutory authorities and suppliers, using different communication modes including EDI, internet, fax and email.>
Internal Use Only 3

<Name of the Project>

Software Requirements Specifications ver.<nn.rr>

2.1.2 User Interface

<These sections captures functionality from the user perspective, hence the interfaces are described in business terms i.e. what would be visible to the end user. Data references should be to entities and attributes (rather than tables and fields). In other words, this describes what is done rather than how it is done.> <Describe at a high level the screens, statistics and reports, enquiry screens and reports that are required to be maintained by the system for reporting purposes. This should include screens, which are needed specifically for enquiry purposes control and management information as well as the enquiry screens/reports, which are part of the main processes covered by the business process models.>

2.1.2.1 Screen Layouts

<Give a brief description of the sub-section> 2.1.2.1.1 Navigation Chart <A navigation chart showing the access routes to the screens should be included. A highlevel chart can be produced and decomposed to the number of detail levels required.> 2.1.2.1.2 Screen Layout : <Screen Title> <The screen layout should be included; a bitmap may be used where available.> 2.1.2.1.3 Screen Description <Each screen layout should have an accompanying narrative. a. <Details of the screen may be given in the following format:> Attribute Name Description Remarks

2.1.2.2 Report Layouts

<Give a brief description of the sub-section> 2.1.2.2.1 Report Layout: <Report Title> <The Report layout should be included in this section.> 2.1.2.2.2 Report Description <Each report should be briefly described. A sample format is given below:> Title: Purpose: Intended Users: Frequency: Report Sequence: Business Logic: Title of the report Business purpose for the report Intended distribution Frequency of generation Description of the required sequence Description of the business logic

2.1.3 Hardware Interface

<Specify the logical characteristics of each interface between software products and hardware components of the system.>

2.1.4 Software Interface

<Specify the use of other required software products and interfaces with other application system.>

Internal Use Only

<Name of the Project>

Software Requirements Specifications ver.<nn.rr>

2.1.5 Communication Interface

<Specify the various interfaces to communication such as local network protocols>

2.1.6 Memory Constraints

<Specify any applicable characteristics and limits on primary and secondary memory>

2.1.7 Operations
<Specify the normal and special operations required by the user.>

2.1.8 Site Adaptation requirements

<Specify the requirements for any data or initialization sequences that are specific to a given site, mission or operational mode.>

2.2 Product Functions

< Specify the summary of major functions that the software will perform>

2.3 User Characteristics

<Define the main set of users who would be handling the application and for which specific functions and roles.>

2.4 Constraints
<Specify the limitations that affect the software development>

2.5 Assumptions and Dependancies

The successful execution of the assignment will depend on the following factors: <Assumptions Prompt responses from the client on queries from the project

Dependencies < Involvement of the end users in signing off this SRS document. Availability of System Software from the client for development. Availability of installed hardware/System software for implementation. Feedback on this report will be provided as per the agreemnent in the contract. Any delay in the feedback will have impact on the schedule and cost of the project. >

2.6 Prioratising of the Requirements

<Specify the requirements that may be delayed until future versions of the system >

Internal Use Only

<Name of the Project>

Software Requirements Specifications ver.<nn.rr>

3. Specific Requirements
<Specify the requirements that will be perceived externally by the users or other external system >

3.1 External Interfaces

<Specify the inputs and outputs of the software systems > Name of the Item Description of Purpose Source of input/Destination of output Valid range, Accuracy and/or Tolerance Units of measure Timing Relationship to other inputs/outputs Screen formats/Organizatio n Window format/Organization Data format Command formats End messages

3.2 Functions
<Specify the fundamental actions that must take place in the software in accepting/generating and processing the input and outputs >

3.3 Performance Requirements

<Specify the static and dynamic numerical requirements placed on the software on human interaction with the software as a whole>

3.4 Logical Database Requirements

<Specify the logical requirements that are to be placed in the database >

3.5 Design Constraints

<Specify the design constraints that can be imposed by other standards, hardware limitations etc >

Internal Use Only

<Name of the Project>

Software Requirements Specifications ver.<nn.rr>

3.6 Software system attributes

<Specify the attributes of the software such as reliability, availability, security, maintainability and portability that can serve as requirements>

3.7 Organizing the Specific Requirements

<List the organization of the requirements based on system mode, user class, objects, feature, stimulus, response and functional hierarchy Refer section 3.7 of analysis guidelines for more details and formats >

3.8 Additional Comments

<Specify any additional requirements that are not covered under Section 3.7 >

Internal Use Only

<Name of the Project>

Software Requirements Specifications ver.<nn.rr>

4. Appendix
<Specify any additional information that helps the readers of the SRS. Specify if the appendixes form part of SRS or not> <Include High Level Information Model for SSAD methodology or Analysis Object Model for OOAD methodology depending upon the software product> <Cover the following in High level Information model, if SSAD methodology is used> <Describe in high level business terms the main groups of business data that need to be maintained by the system to meet the requirements and specify who the data is owned by at the relevant point in the process. Include the entity and attribute descriptions.> < Include the reference data and codification requirements including: Reference data that are shared with other applications Reference data that are private> <Entity Descriptions can be given in the following format:> <Entity Name> Attribute Name Description

<The setting up and updating of the reference data need to be reflected in the process models.> <Provide estimates for transaction volumes and specify the requirements for growth.> <Also, provide Entity Relationship Diagram> <Cover the following in Analysis Object Mode, if OOAD methodology is used> <This section presents a list of the fundamental objects that must be modeled within the system to satisfy its requirements. The purpose is to provide an alternative; "structural" view on the requirements stated above and how they might be satisfied in the system. The RSI (Requirement/Services/Interfaces) approach should be taken for use case analysis of the system. This appraoch provides a framework for analysing and understanding potential use case deliverables and their inter-relationships. It also provides a framework for decision making on the appropriate "granularity" and "content" of use cases.The requirement use case should be defined at this stage in the format mentioned below. During the design process, the requirement use cases should be extended and based on it Service and Interface use case categories can be defined. From a process perspective, two phases of use case analysis emerge: high level requirement use case gathering and detailed service and interface use case specification. service and interface use case definition are undertaken in parallel, as interface use cases drive the definition of the set of query service necessary in the system. Requirement use cases document business processes for which automated support may be required. They detail the requirements driving the development of a system, but do not define the detail of a system's functionality. interface use cases provide a detailed description of the interfaces presented to the system's actors and association functionality. service use cases provide a detailed description of the underlying functionality a system offers in a manner independent of the needs of any particular interface.
Internal Use Only 8

<Name of the Project>

Software Requirements Specifications ver.<nn.rr>

The Analysis Object Model (AOM) will contain the following: a. Use Case View: (i) (ii) Use Case diagram Activity Diagram to realize Business use cases

b. Analysis View: (i) (ii) (iii) Class diagram State transition diagram (If classes need to store state information, more pertinent for Embedded systems application) Sequence diagram (or) Collaboration diagram.>

AOM will be done using a tool supporting UML notation, like Rational Rose.

Internal Use Only

<Name of the Project>

Software Requirements Specifications ver.<nn.rr>

5. Index
<List all items to locate easily>

Internal Use Only

10