System Requirement Specification

Document Name


Table of Contents

Document Information. 3

Document History. 3

Final Document Approval 3

Abbreviations & Definitions. 4

Introduction. 5

  1. Purpose. 5
  2. References. 5

Solution overview.. 6

  1. Product Perspective. 6
  2. Product Scope. 6

2.2         Scope Diagram.. 6

2.3         Scope. 6

  1. User Classes and Characteristics. 6
  2. Risks. 6
  3. Operating Environment “Architect Role. 7
  4. Design and Implementation Constraints Architect Role. 7
  5. User Documentation KT team.. 7
  6. Assumptions and Dependencies. 7

8.1         Key Assumptions. 7

8.2         Dependencies. 7

External Interface Requirements. 8

  1. User Interfaces another team.. 8
  2. Hardware Interfaces Architect Role. 8
  3. Software Interfaces Architect Role. 8
  4. Communications Interfaces Architect Role. 8

Functional Requirements. 9

  1. Actors and their Roles and Responsibilities Permissions. 9
  2. Workflow “Activity Diagram”. 10
  3. Use Case Diagram.. 11
  4. Tractability MATRIX. 12

Use Cases. 13

UC-001.. 13

Nonfunctional Requirements. 15

  1. Performance Requirements. 15
  2. Security Requirements. 15

4.1         Data Validation. 15

4.2         Authentication. 15

  1. Software Quality Attributes. 15
  1. Business Rules. 17
  2. Messages. 17

Other Requirements “optional”. 18

Appendix. 19

Analysis Models. 19



Document Information


Document Name System Requirements Specification
Opportunity Number
Opportunity Name
Document Author  
Version 1.0
Date 4-Nov-20
Status Draft


Document History


Revision Number Date Revision Description
Second Draft    


Final Document Approval


Electronic approvals will be stored to confirm that this document will serve as the System Requirements Specification.


Name Role Signature / Date
<Insert Customer Name>    



Abbreviations & Definitions

Term / Acronym Definition








  1. Purpose

<Identify the product whose software requirements are specified in this document, including the revision or release number. Describe the scope of the product that is covered by this SRS, particularly if this SRS describes only part of the system or a single subsystem.>

  1. References

<List any other documents or Web addresses to which this SRS refers. These may include user interface style guides, contracts, standards, system requirements specifications, use case documents, or a vision and scope document. Provide enough information so that the reader could access a copy of each reference, including title, author, version number, date, and source or location.>

Name of document Version Date Document Location


Solution overview

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

<Provide a short description of the software being specified and its purpose, including relevant benefits, objectives, and goals. Relate the software to corporate goals or business strategies. If a separate vision and scope document is available, refer to it rather than duplicating its contents here, and can be referenced by the BRD and CR>

  • Scope Diagram

The Scope diagram defines what within the scope of the technology track of the system



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


  1. Operating Environment “Architect Role

<Describe the environment in which the software will operate, including the hardware platform, operating system and versions, and any other software components or applications with which it must peacefully coexist.>

<Describe any items or issues that will limit the options available to the developers. These might include: corporate or regulatory policies; hardware limitations (timing requirements, memory requirements); interfaces to other applications; specific technologies, tools, and databases to be used; parallel operations; language requirements; communications protocols; security considerations; design conventions or programming standards (for example, if the customer’s organization will be responsible for maintaining the delivered software).>

  1. User Documentation KT team


  1. Assumptions and Dependencies


  • Key Assumptions

This section provides the summary of overall assumptions and constraints.

Sr. NO Description

Table 1 : Assumptions

  • Dependencies

This section provides the list of both internal and external dependencies for the solution:

Sr. NO Description

Table 2: Dependencies

External Interface Requirements

  1. User Interfaces UI Team


  1. Hardware Interfaces Architect Role

<Describe the logical and physical characteristics of each interface between the software product and the hardware components of the system. This may include the supported device types, the nature of the data and control interactions between the software and the hardware, and communication protocols to be used.>


  1. Communications Interfaces Architect Role




Functional Requirements


Category Group Permissions Business Rules






  1. Use Case





  1. Tractability MATRIX


ID UC Title UC Desc. Actors

Table 1: Use Case Inventory


Use Cases


Requirement ID REQ-
Primary Actor   Secondary actor  N/A  
Basic Flow
Actor Action System Action


Actor Action System Action
Business Rules
Post-Condition ü   
Data Dictionary
“Ar & Eng” Data Type/Field type Mandatory? Initial Value BR Validation Comments  


Mockups Figure 1:
Additional Info.  




Nonfunctional Requirements

  1. Performance Requirements


  1. Security Requirements

·     Client and Server-side validation

  • Authentication

·       User triggered password change

·       User password change process

·       Logon failure message

·       Successful login message


  1. Software Quality Attributes

·       Usability Requirements:

·       Reliability and Up-time Requirements:

·       Maintainability & Upgradability Requirements:

·       Language Requirements:





  1. Business Rules


ID BR Description



  1. Messages


ID Description (English) Description (Arabic)



Other Requirements “optional”

<Define any other requirements not covered elsewhere in the SRS. This might include database requirements, internationalization requirements, legal requirements, reuse objectives for the project, and so on. Add any new sections that are pertinent to the project.>























Analysis Models

<, include any pertinent analysis models, such as data flow diagrams, class diagrams, state-transition diagrams, or entity-relationship diagrams.>


SRS Template V.0.3_BA-Reviewed – Copy