SRS Template

As on 31/1/2003

SRS Template Guidelines

The objective of the template is to provide guidelines to Project Leaders (PLs) for preparation of the SRS for OOAD projects. It gives a number of sections and sub-sections, all of which may not be relevant to your project. Delete the sections/sub-sections, which are not required. Also, project-specific details can be included as sections/sub-sections wherever required. The text given in <blue italics> specifies instructions to be followed while preparing the SRS. These brackets are to be removed after replacing the instruction with the required information. The text in <black italics> represents sample formats and examples that may be used in the SRS. If you use the samples remove the italics. If you do not use the sample, please delete it from the document. The items mentioned in black regular can be retained. Please delete this page and the next page when you use this document for your project. Important Instructions: a) The template is meant only for the projects following OOAD methodology. b) Structure your document in such a way that you do not have to go beyond Heading 5. c) Use styles Bullet1 and Bullet Indent to give bullet lists. d) Use styles AphaNumber1 and AlphaNumber Indent to give numbered lists. e) Use Normal style for all text. Avoid using Body Text (and all permutations of it) unless absolutely essential. f) Avoid creating more styles. Use the ones included in this template. g) Always save a copy of this template using Save As and then overwrite the required areas. Do not do a Copy and Paste into a new document. This mixes styles from this template with your local normal.dot template, and leads to corrupt documents.

Internal Use Only

SRS Template

As on 31/1/2003

The SRS Template begins from the next section. Please delete this section when you use this template.

Internal Use Only

ii

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

<Name of the Project>

Software Requirements Specifications

Version <nn.rr>

<month, year>

Warning This is a hard copy of a document maintained on electronic media. It may not be the latest version. Kindly ascertain the latest version from the Document Master List available with the Project Leader.

<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>

PREFACE
Purpose of this Document
<State the purpose of the document> This document describes the System Requirements Specifications of the <name of the system>. This document lays down the software requirements for the application that have been captured through a detailed study of the business workflow and functions.

Intended Audience
<State the users for whom this document holds relevance> This document is intended for use by the designers of the system, and for those who may be required to maintain it. The document will enable them to understand all aspects of the system in detail. It will enable the <Client> to know that TCS has captured all the requirements. The document will also be used by <Client> for carrying out the acceptance testing for which it will form the.

Related Documents / References

<Identify each referenced document by title, version or date and publishing organization> <Reference of important and relevant correspondence should also be provided> <Also, refer to all the documents, which need to be looked into for better understanding of this document> The following documents have been referred to for the preparation of this SRS document: 1. Technical Proposal for the study 2. Contract and associated relevant documents 3. <Any other document>

Acronyms and Abbreviations

< List in alphabetical order> Abbreviation/Acronym Description

Organization of this Document

<Brief details for all sections of document and annexures should be provided> This document consists of <X> sections and <X> appendices. Section 1 Section 2

Internal Use Only

ii

<Name of the Project>

Software Requirements Specifications ver. <nn.rr>

TABLE OF CONTENTS
1. INTRODUCTION...................................................................................................................1 1.1 BACKGROUND.........................................................................................................................1 1.2 SCOPE..................................................................................................................................1 1.3 BUSINESS JUSTIFICATION FOR INVESTMENT....................................................................................1 1.4 PRODUCT PERSPECTIVE............................................................................................................2 1.5 KEY ASSUMPTIONS, DEPENDENCIES, CONSTRAINTS AND OVERRIDING PRIORITIES..................................2 1.6 USER CLASSES AND CHARACTERISTICS........................................................................................2 1.7 HARDWARE AND SOFTWARE PLATFORM........................................................................................2 1.8 SITE ADAPTATION....................................................................................................................2 1.9 APPLICATION SECURITY............................................................................................................2 1.10 MIGRATION REQUIREMENTS....................................................................................................2 2. FUNCTIONAL REQUIREMENTS..........................................................................................3 2.1 REQUIREMENT 1.....................................................................................................................3 2.2 REQUIREMENT 2.....................................................................................................................3 3. USER INTERFACE SPECIFICATIONS.................................................................................4 3.1 GUI SCREEN LAYOUTS............................................................................................................4 3.1.1 Navigation Chart...........................................................................................................4 3.1.2 Screen Layout : <Screen Title>...................................................................................4 3.1.3 Screen Description........................................................................................................4 3.2 GUI REPORT LAYOUTS............................................................................................................4 3.2.1 Report Layout................................................................................................................4 3.2.2 Report Description........................................................................................................4 4. EXTERNAL INTERFACE SPECIFICATIONS........................................................................5 4.1 SYSTEM INTERFACES................................................................................................................5 4.2 INTERFACE DESCRIPTIONS.........................................................................................................5 4.2.1 Message/Interface Specifications.................................................................................5 5. OTHER REQUIREMENTS.....................................................................................................6 5.1 GENERIC REQUIREMENTS..........................................................................................................6 5.2 USER ACCESS CONTROL AND SECURITY......................................................................................6 5.3 ARCHIVING AND HOUSEKEEPING..................................................................................................6 5.4 PERFORMANCE REQUIREMENTS..................................................................................................7 6. APPENDIX A: ANALYSIS OBJECT MODEL........................................................................8 7. GLOSSARY OF TERMS.......................................................................................................9 Total Number of pages: 17 <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

iii

<Name of the Project>

Software Requirements Specifications ver. <nn.rr>

1. Introduction
1.1 Background
This document outlines the software requirement specification for the <xxxx> Application System. It is the outcome of the Analysis Phase during which discussions were held with the users. The objective of this Analysis Phase was to: Define the scope for the <specify name of the system>. Serve as the baseline for the design of the <specify name of the system>.

Any changes to requirements after acceptance of this document will be through appropriate Change Management procedure, as detailed in the contract. Both the user and designer should go through the document carefully in order to ensure that : All the user requirements which need to be supported by the system have been identified and detailed. The document is a clear and unambiguous statement of functionality required from the system for the design and development team. The document can be used as a basis for development of the System Test data. It is essential to identify the problems, if any, with the basic structure of the proposed system at this stage. If these are not taken care of at this stage, it may be difficult to incorporate the desired modifications to overcome the shortcomings at a later stage. <Describe client details, project details and broad requirements of the project/module>

1.2 Scope
<Describe in high level terms, the agreed scope of the project. Make a reference to the proposal/contract/agreement wherein the objectives and the scope of the application are defined and/or include the same in this document.> <Include the following: key functionality (including the Statutory and Regulatory requirements) that will be provided at all levels (e.g. corporate, regional, etc.) areas that are excluded from the proposal main business users at all levels geography (e.g. local/global) target systems that will be replaced by proposed new system projected impact on existing applications (e.g. bridging requirement) impact on customers, suppliers, third party interfaces >

1.3 Business Justification for Investment

<Reconfirm the business case for the investment. Areas covered should include: > Main drivers for change Main business benefits envisaged - short term and longer term Critical Success Factors etc. from the business and IT point of view Required target delivery dates

Internal Use Only

<Name of the Project>

Software Requirements Specifications ver. <nn.rr>

1.4 Product Perspective

<Describe the context and origin of the product being specified in this SRS. For example, state
whether this product is a follow-on member of a product family, a replacement for certain existing systems, or a new, self-contained product. If the SRS defines a component of a larger system, relate the requirements of the larger system to the functionality of this software and identify interfaces between the two. A simple diagram that shows the major components of the overall system, subsystem interconnections, and external interfaces can be helpful.>

1.5 Key Assumptions, Dependencies, Constraints and Overriding Priorities

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.

Constraints > None

1.6 User Classes and Characteristics

<Identify the various user classes that you anticipate will use this product. User classes may be
differentiated based on frequency of use, subset of product functions used, technical expertise, security or privilege levels, educational level, or experience. Describe the pertinent characteristics of each user class. Certain requirements may pertain only to certain user classes. Distinguish the most important user classes for this product from those who are less important to satisfy.>

1.7 Hardware and Software Platform

<Define the Hardware and Software platform on which the application is proposed to be built.>

1.8 Site Adaptation

< Give the details of how the operational site will adapt itself to the IT solution>

1.9 Application Security

<Provide details of what kind of application security, database security will be provided>

1.10 Migration Requirements

< Detail the Migration strategy for data that needs to be migrated from the existing system to the proposed system >
Internal Use Only 2

<Name of the Project>

Software Requirements Specifications ver. <nn.rr>

2. Functional Requirements
<This includes describing the required system functionality at sufficient level of detail to produce a high level logical design of the system. Itemise the detailed functional requirements associated with this feature. These are the software capabilities that must be present in order for the user to carry out the services provided by the feature, or to execute the use case. Include how the product should respond to anticipated error conditions or invalid inputs. Requirements should be concise, complete, unambiguous, verifiable, andessential. > Each requirement should be uniquely identified with a sequence number or a meaningful tag of some kind.>

2.1 Requirement 1
<Provide a complete description of the requirement, the business logic and validations in it.>

2.2 Requirement 2
<Provide a complete description of the requirement, the business logic and validations in it.>

Internal Use Only

<Name of the Project>

Software Requirements Specifications ver. <nn.rr>

3. User Interface Specifications

<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.>

3.1 GUI Screen Layouts

<Give a brief description of the sub-section>

3.1.1 Navigation Chart

<A navigation chart showing the access routes to the screens should be included. A high-level chart can be produced and decomposed to the number of detail levels required.>

3.1.2 Screen Layout : <Screen Title>

<The screen layout should be included; a bitmap may be used where available.>

3.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

3.2 GUI Report Layouts

<Give a brief description of the sub-section>

3.2.1 Report Layout

<The Report layout should be included in this section.>

3.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 any specific processing logic

Internal Use Only

<Name of the Project>

Software Requirements Specifications ver. <nn.rr>

4. External Interface Specifications

<Give a brief description of the section>

4.1 System Interfaces

<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.>

4.2 Interface Descriptions

<The following sections will be repeated for each interface required.>

4.2.1 Message/Interface Specifications

<Detail the definition of the requirement. A small description of messages may be given. A sample format is included below.> Title: Description: Business Purpose: < Message title > < Description/Content of the message > <The context and rationale for each message >

Internal Use Only

<Name of the Project>

Software Requirements Specifications ver. <nn.rr>

5. Other Requirements
<Give a brief description of the section>

5.1 Generic Requirements

<Requirements which do not belong within a process flow, should be described within a separate section (a process model would not be required). An example of this would be multiple-language functionality.>

5.2 User Access Control and Security

<Describe the business requirements in the area of user access control and security. These requirements by and large will be addressed within the framework established for the generic service environment.> <Security provisions may be made at the following levels: Operating System Level Each user may be given separate log-in Id and password. They may be divided into three groups. Application User may have access to Application software only. These users may not have any access to the Operating System commands outside of Application Menus Operating System User may have access to user level Operating System commands in addition to the Application software and certain RDBMS tools Super User may have access to all the commands, including super user commands, at Operating System level apart from the above two. Besides above each user will be assigned a user code at the time of implementation of the system. It will be possible to set or change the password interactively. Each user or group of users will have access to certain screens/functions of the system relevant to his area of operation. The access rights for each user code will be recorded within the system. Each user will have to log-on to the system using the correct user code and password. In case of an invalid combination of these two codes, the system will display an error message and prevent further processing.>

5.3 Archiving and Housekeeping

<Define the requirements for removing, preserving and restoring key data (archiving) and housekeeping.> <Provisions may be made at the following levels by dividing the users into following groups, user interface for which may be provided. Database Administrator (DBA) may own the database. These users may create, update and drop database objects, namely, table-spaces, tables and indexes etc.. The maintenance of the access rights may be done by them. Only they may have access to the security / access maintenance screens. Any modifications to the access rights may be made only with proper authorization. They may be responsible for overall maintenance and management of the RDBMS. System Administrator (SYSADMIN) may own the application. It may create, update and drop users, user groups for the application and provide required access to them.
Internal Use Only 6

<Name of the Project>

Software Requirements Specifications ver. <nn.rr>

5.4 Performance Requirements

<Describe the system availability requirements and the system performance requirements (e.g. response times and capacity) in critical areas of the system, and the envisaged system workload patterns and peak activity.>

Internal Use Only

<Name of the Project>

Software Requirements Specifications ver. <nn.rr>

6. Appendix A: Analysis Object Model

<This section presents a list of the fundamental objects that must be modelled 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. 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>

7. Glossary of Terms
<All the terms used in the application must be defined in a clear manner in the glossary. The objective of this is to have in one place common and clear definitions of all the terms. In addition the glossary must contain the list of allowed values for the term in one place>

Internal Use Only