Document Name

[Date]

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

3. User Classes and Characteristics. 6
4. Risks. 6
5. Operating Environment “Architect Role. 7
6. Design and Implementation Constraints Architect Role. 7
7. User Documentation KT team.. 7
8. 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

• Client and Server-side validation. 15

4.2         Authentication. 15

• Use of strong user passwords. 15
• Communication of username and password in clear text 15
• User triggered password change. 15
• User password change process. 15
• Logon failure message. 15
• Successful login message. 15
• Client and server side. 15

3. Software Quality Attributes. 15

• Usability Requirements: 15
• Reliability and Up-time Requirements: 15
• Maintainability & Upgradability Requirements: 15
• Load test: 15
• Language Requirements: 15

4. Business Rules. 17
5. Messages. 17

Other Requirements “optional”. 18

Appendix. 19

Analysis Models. 19

 

 

Document Information

 

Document Name	System Requirements Specification
Opportunity Number	–
Opportunity Name	–
Client
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>
IQVIA

 

 

Abbreviations & Definitions

Term / Acronym	Definition

 

 

 

 

 

 

Introduction

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

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

>>Example<<

 

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

4. Risks

 

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

7. User Documentation KT team

 

8. 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
D-001

Table 2: Dependencies

External Interface Requirements

1. User Interfaces UI Team

 

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

 

4. Communications Interfaces Architect Role

 

 

 

Functional Requirements

 

Category	Group	Permissions	Business Rules

 

 

 

 

 

3. Use Case

 

 

 

 

4. Tractability MATRIX

 

ID	UC Title	UC Desc.	Actors

Table 1: Use Case Inventory

 

Use Cases

 

Requirement ID	REQ-
Description
Primary Actor					Secondary actor	N/A
Pre-Condition
Triggers
Basic Flow
Actor Action			System Action
1-
			–
2-
3-			.
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

 

2. Security Requirements

·     Client and Server-side validation

• Authentication

·       User triggered password change

·       User password change process

·       Logon failure message

·       Successful login message

 

3. Software Quality Attributes

·       Usability Requirements:

·       Reliability and Up-time Requirements:

·       Maintainability & Upgradability Requirements:

·       Language Requirements:

 

 

 

 

4. Business Rules

 

ID	BR Description
BR-01

 

 

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Appendix

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