software requirements specification template · web viewamendment record document sign-off sheet ...

Version No Nature of Change/Remarks Prepared By Approved by Release Date

SOFTWARE REQUIREMENTS SPECIFICATION

Doc ID : <ProjectID>_SRS_vM-n

Private and Confidential

No part of this publication may be reproduced or distributed in any form or by any means, or stored in a database or retrieval system, without prior written permission of the publisher.

Amendment Record

Software Requirements Specification

Doc ID : <ProjectID>_SRS_vM-n Page No : 2 of 11

Document Sign-Off Sheet

<Client Name> and <Company name> Sdn. Bhd. both acknowledge that they have review this Software Requirement Specification, understand it, and that once it is signed by both parties’ Authorized Representatives, agree to be bound by its requirements scope. The signature below signifies that the parties involved have accepted this requirement specification as final.

<Client Name>

Name Role/Title Date Sign-Off

Project Manager

Owner

<Company name> Sdn Bhd

Name Role/Title Date Sign-Off

Project Manager

SA



TABLE OF CONTENTS

1. Introduction.....................................................................................................................5

1.1 Background...............................................................................................................5

1.2 Purpose....................................................................................................................5

1.3 Glossary....................................................................................................................5

1.4 Reference.................................................................................................................5

2. Detailed Process Flow.......................................................................................................6

3. Use Case...........................................................................................................................7

4. Functional Requirements..................................................................................................8

5. Non-Functional Requirement..........................................................................................10

6. Interface Requirements..................................................................................................10

Appendix...............................................................................................................................11



1. Introduction

1.1 Background

This document is the Software Requirements Specification for:

Project ID:

Project Name:

Brief Description of Project: <Extraction from Project Initiation Note>

<Use “Guidelines for Requirements Development” to help on developing SRS.>

<Use “Checklist for Requirements Elicitation” to ensure the important details is written down.>

1.2 Purpose

State the purpose of the project’s software requirements specification, intended audience and what part of project activities are covered in this document.

1.3 Glossary

Specify terms and abbreviations used in this document and their definitions that are needed to understand this document. Put them in table format, if necessary.Abbreviations Definition

URS User Requirement Specification

… …

1.4 Reference

List documents need to be referred to for getting an in-depth understanding of this document.

Document Name Document ID

User Requirement Specification <ProjectID>_URS_vM-n



2. Detailed Process Flow

3. Use Case

Use Case Diagram:



Use Case Scenario:

Scenario # Related SRS ID Scenario Description

Flow Pre-condition Post Condition

SC-001 SRS-01 Apply Car Loan 1. The actor selects Loan Application module.2. The actor enters all loan application details.3. The actor submits the loan application for approval.

A customer file must exist. Car Loan product parameters are set up.

Loan Application successfully created in the system.

4. Functional Requirements

<Describe functional requirements for the allocated modules. Each requirement is represented using process flow diagrams and use cases modeling. Each representation is described in details.)



The following table lists the functionalities/features to be included. Details of representation are described in section 3, 4, 5 and Appendix A:

NOTE:

i. Gap Type consist of the following variants: -

a. B (Business Rule) - The functional requirement only relates to the change to the existing business rules or acts as a Business Rule which is deemed relevant to the rest of the requirement development. There may not be any changes to the existing functionalities or the user interface(s).

b. F (Functionality) – The occurrence of functionality variance which requires changes in terms of the system’s functionality. (Usually triggered from the Business Rule variance)

c. U (User Interface) - The occurrence of user interface variance which requires changes to the system’s existing user interface(s). (Usually triggered from the Business Rule or Functional variances, both)

ii. One Functional Requirement may bear more than one (1) Gap Type.



URS ID SRS ID Functional Requirements Data Capture

Gap Type

B/F/U

Representation

URS-01. SRS#-1.1 . System to allowed user (administrator) to define the authorized user(s) to the system.

. User(administrator) will be allowed to define the access rights for each access group

. Username & password are alphanumeric, max 10 characters

. Freeze account after 3 failed tries

F/U UC1 <Diagram Flow, Scenarios>, prototype etc

URS-02. SRS#-1.2 . System to have a setup to allowed the limit setup by:

a. Counter Party Limitb. Dealer Limitc. Signatory Limit

. Limit will be grouped according to:

a. Limit Type (Counter Party/Dealer/Signatory)b. Product Categoryc. Product Typed. Currency Type

. Limit is specified in monetary value.

…

URS-03. SRS#-1.3 . All successfully submitted deal will be flag for confirmation.

. Only deal(s) eligible for confirmation will appear/listed.

. Only authorized (pre-defined/pre-setup) user will be allowed to perform the confirmation submission.

…

URS-04. … … …



5. Non-Functional Requirement

Describe the behavioral properties that the System must have, such as performance, usability, Operational, Maintainability and Portability, Security, Cultural and Political, and Legal.

Examples

• The response shall be fast enough to avoid interrupting the user’s flow of thought

• Only Academic staffs can see the details personnel records of students.

• Only authorized user can access the modules.

• The product shall protect itself from intentional abuse.

• Personal information shall be implemented so as to comply with the data protection act.

• Etc..

6. Interface Requirements

For example:

Online interfaces shall follow standard <Client System> host request/reply messages format over the <Client System> Universal Financial Platform (UFP) API

X: Third Party System; C: Client System

No. Third Party System

Nature of system

Interface Method Requirements Specification

1. VBM (Virtual Banking Management)

Internet Banking

X to C

Requires Host extraction of account and transaction data for FTP to HP server

<Elaborate in detail>

2. BDS (Branch Delivery System)

Branch-banking

X to C

Auto update the ABC GL System for transactions made via BDS

3. … … …



Appendix



software requirements specification template · web viewamendment record document sign-off sheet ...

Documents