tc management srs

SOFTWARE REQUIREMENT SPECIFICATIONS DOCUMENT TEMPLATE

SOFTWARE REQUIREMENT SPECIFICATIONS

DOCUMENT

TEST CASE MANAGEMENT APPLICATION

PREPARED FOR: BRICKRED TECHNOLOGIES

BY: BRICKRED TECHNOLOGIES

Software Requirement Specification document 4/9/2023 1 of 14

Software Requirement Specification Document For ABC

Document Information

Project Code:

Project Name:

Account:

Vertical:

Customer Name:

Technical Manager:

Project Manager:

Quality Co-ordinator:

Doc Info Details Date Remarks

Prepared By Sayantam Dey

Reviewed By

Approved By

Revision History

Version Date of Revision

Prepared/ Modified

by

Desc. of

Change

Reason for

Change

Affected Sections

Remarks

Distribution List

Name Role Action Remarks

Software Requirement specification document 4/9/2023 2 of 14


Table of Contents

1 INTRODUCTION.........................................................................4

1.1 Purpose..................................................................................................41.2 Overview................................................................................................41.3 Exclusions..............................................................................................41.4 Limitations.............................................................................................41.5 Assumptions..........................................................................................41.6 Dependencies........................................................................................41.7 Acceptance Criteria...............................................................................41.8 Traceability to Requirements................................................................41.9 Audience................................................................................................51.10 References........................................................................................51.11 Definition, Acronyms and Abbreviations.........................................5

2 GENERAL DESCRIPTION.............................................................6

2.1 User Characteristics...............................................................................6

3 APPLICATION ENVIRONMENT.....................................................7

3.1 Technology Environment......................................................................73.2 External Interfaces................................................................................7

3.2.1 Hardware Interface......................................................7

3.2.2 Communication Interface.............................................7

4 FUNCTIONAL REQUIREMENTS/USECASES....................................8

4.1 Installation/ Configuration of outlook integration.................................8

4.1.1 User integrates the client application with outlook........8

4.1.2 User configures the application with the Outlook..........84.2 Sync Outlook contacts to IDoc database..............................................9

4.2.1 User marks the Contacts for synchronization................9

4.2.2 User deselects/unmark the contacts...........................10

4.2.3 User maps the Outlook fields with IDoc fields..............11

4.2.4 User synchronizes the contacts..................................12

5 NON FUNCTIONAL/SPECIFIC REQUIREMENTS.............................14

5.1 Performance........................................................................................145.2 Usability...............................................................................................145.3 Security................................................................................................145.4 Audit Trail............................................................................................145.5 Availability/SLA....................................................................................145.6 Reliability.............................................................................................145.7 Data and Transaction Volume.............................................................145.8 Backup and Recovery..........................................................................145.9 Data Migration.....................................................................................145.10 Documentation...............................................................................14



1 INTRODUCTION

1.1 Purpose

The purpose of this Functional Specification Document is to define the scope, functional and the non functional requirements of a test case management application.

1.2 Overview

ABC application is a test case management application oriented towards capturing requirements, test cases against requirements and test execution logs and reports.

1.3 Exclusions

The support for defect tracking is out of scope for the Phase - I.

1.4 Limitations

1.5 Assumptions

Since the complexity of application can greatly vary depending upon the scope of the integration, it is assumed that only contacts need to be synchronized in the first release. We are also assuming that in Phase - I, the user will not specify mapping of fields.

1.6 Dependencies

Specify the dependencies that may exist wrt specific a requirement or the system as a whole.

1.7 Acceptance Criteria

Specify the conditions for acceptance at functional/sub system level or system as a whole.

1.8 Traceability to Requirements

List the traceability information to trace the requirements from RS doc to FS doc. The locations of functional specs should be mapped to the corresponding locations of the requirements in the RS.

Document Reference ID & Description (from which this doc is derived)

S. No.

Requirement doc Section or Feature ID/Name

Current doc Section ID/Name



1.9 Audience

Intended audiences of this document are: -

Xyz Inc.

LeverPoint Inc.

BrickRed Technologies

1.10References

1.11Definition, Acronyms and Abbreviations

ABBREVIATION DESCRIPTION



2 GENERAL DESCRIPTION

2.1 User Characteristics

Users and their roles and privileges are as described below in the table.

Type of User

User Characteristic

Abc User User has a valid account. User is allowed to synchronize the information between local and remote server.



3 APPLICATION ENVIRONMENT

3.1 Technology Environment

a. Hardware

Minimum Recommended Hardware:

Dual processor Pentium IV, 2 GHz machines with 1GB of RAM for Web, application and database servers.

Single processor Pentium class machines with 32 MB of RAM for web browsers.

b. Software

Database Server – MS SQL Server 2005.

Frame Work- Microsoft .NET 2.0.

Others - Microsoft BizTalk Server

3.2 External Interfaces

3.2.1 Hardware Interface

3.2.2 Communication Interface



4 FUNCTIONAL REQUIREMENTS/USECASES

4.1 Installation/ Configuration of outlook integration

4.1.1 User integrates the client application with outlook

Description This use case represents the installation of client application for the outlook integration with the IDoc database.

Pre-Condition None

Assumptions Application would only sync the outlook contacts.

Emails, tasks etc would come in future release

Default Flow 1. User runs the exe

2. The wizard allows the user to install / integrate the application with outlook.

Post-Condition The application is successfully integrated with the outlook

A new tool bar would appear on the Microsoft

Alternate Flow 1. User cancels the installation process

2. The application is not installed

Exceptions/Errors

Actors IDoc user

4.1.2 User configures the application with the Outlook

Description This use case allows the user to configure the outlook client application with the IDocs database.

Pre-Condition User has valid IDoc User Id/ Password



Assumptions

Default Flow 1. User choose to configure the client application from the outlook

2. User Enters the IDoc User id/password

3. User saves the information.

4. The application is configured with the Outlook and IDoc database

Post-Condition

Alternate Flow

Exceptions/Errors If the account is not valid , user is prompted with the appropriate message and use case fails

Actors IDocs user

4.2 Sync Outlook contacts to IDoc database

4.2.1 User marks the Contacts for synchronization.

Description User can selects few or all the contacts that needs to be synchronized between outlook and IDocs database

Pre-Condition

Assumptions

Default Flow 1. User selects the contact/contacts

2. User marks the selected contacts for Synchronization

3. The marked contacts are visually differentiated from un-marked contacts

Post-Condition

Alternate Flow

Exceptions/Errors



Actors IDoc user

Sample Screen Shot

4.2.2 User deselects/unmark the contacts

Description User deselects/unmark the contacts that need to be synchronized

Pre-Condition Contacts are already marked for synchronization

Assumptions

Default Flow 1. User selects the contact/contacts

2. User unmark the selected contacts for Synchronization

3. The contacts are not marked for synchronization

Post-Condition

Alternate Flow

Exceptions/



Errors

Actors IDoc user

Sample Screen Shot

4.2.3 User maps the Outlook fields with IDoc fields

Description User Choose to map the Outlook contact fields with IDoc fields

Pre-Condition User is a valid IDoc user

Assumptions

Default Flow 1. User Choose to map the outlook fields with IDoc columns

2. System displays a Default mapping.

3. User changes the IDoc column name that is mapped with



outlook field

4. User saves the Mapping information

Post-Condition

Alternate Flow

Exceptions/Errors

Actors IDoc user

4.2.4 User synchronizes the contacts

Description This use case represents the Synchronization mechanism of Outlook contacts with the IDoc database

Pre-Condition Contacts are marked for synchronization

Assumptions

Default Flow 1. User choose to synchronize contacts

2. System validates the user account/password

3. Account is validated

4. System displays the list of IDOC contacts that would be imported from IDoc server to the Outlook

5. User selects all/few of the listed contacts

6. The contacts are copied into to the outlook.

7. System displays the list of outlook contacts that are marked for synchronization

8. User can deselect any of the contacts

9. System copies the outlook contacts to the IDoc database

Post-Condition The contacts are successfully Synchronized

Alternate Flow 1. User choose to synchronize contacts

2. System validates the user account/password

3. Account is not validated

4. System prompts the user for new account



settings( Follow use case 4.1.2]

Exceptions/Errors

1. If synchronization fails in-between, a proper log is created for the user to display all the users that were not synchronized.

Actors IDoc user

Other Points 1. Synchronization assures that the contact details are the same and latest on both the systems.

2. The deleted contacts would also be synchronized and deleted from both the systems [ Condition: the outlook contact was marked for synchronization before deletion]

Sample Screen Shot



5 NON FUNCTIONAL/SPECIFIC REQUIREMENTS

5.1 Performance

5.2 Usability

5.3 Security

5.4 Audit Trail

5.5 Availability/SLA

5.6 Reliability

5.7 Data and Transaction Volume

5.8 Backup and Recovery

5.9 Data Migration

5.10Documentation


tc management srs

Documents