Software Requirement Specification Doc

8/8/2019 Software Requirement Specification Doc

1/14

SOFTWARE REQUIRE

MENT SPECIFICATIONS TEMPLATE DOCUMENT

ABC PROJECT

PREPARED FOR: XYZ CUSTOMER

BY: EFGH IJKL

Software Requirement Specification document 12/20/2010 1 of 14


2/14

Document Information

Project Code:

Project Name:

Account:

Vertical:

Customer Name:

Technical Manager:

Project Manager:

Quality Co-ordinator:

Doc Info Details Date Remarks

Prepared By

Reviewed By

Approved By

Revision History

Version Date of Revision

Prepared/Modified

by

Desc.of

Change

Reasonfor

Change

AffectedSections

Remarks

Distribution List

Name Role Action Remarks

Software Requirement specification document 12/20/2010 2 of 14


3/14

Table of Contents

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

1.1 Purpose........................................................................................4

1.2 Overview......................................................................................4

1.3 Exclusions.....................................................................................41.4 Limitations....................................................................................4

1.5 Assumptions.................................................................................41.6 Dependencies................................................................................4

1.7 Acceptance Criteria........................................................................4

1.8 Traceability to Requirements...........................................................4

1.9 Audience.......................................................................................51.10 References..................................................................................5

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

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

5.3 Security......................................................................................14

5.4 Audit Trail...................................................................................14

5.5 Availability/SLA............................................................................14

5.6 Reliability....................................................................................14

5.7 Data and Transaction Volume........................................................145.8 Backup and Recovery...................................................................14

5.9 Data Migration.............................................................................145.10 Documentation..........................................................................14



4/14

1 INTRODUCTION

1.1 Purpose

The purpose of this Functional Specification Document is to define thescope, functional and the non functional specifications of the ABCapplication.

1.2 Overview

ABC application is a document management application orientedtowards compliance. Documents in an enterprise may be related tocustomers, employees, projects and other entities. Hence theapplication consists of various modules for managing documents

related to various entities.

1.3 Exclusions

The support for remote health monitoring of the application is out ofscope for the Phase - I.

1.4 Limitations

1.5 Assumptions

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

1.6 Dependencies

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

1.7 Acceptance Criteria

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

1.8 Traceability to Requirements

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

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

S.

No.

Requirement doc

Section or FeatureID/Name

Current doc Section

ID/Name



5/14

1.9 Audience

Intended audiences of this document are: -

Xyz Inc.

LeverPoint Inc.

BrickRed Technologies

1.10 References

1.11Definition, Acronyms and Abbreviations

ABBREVIATION DESCRIPTION



6/14

2 GENERAL DESCRIPTION

2.1 User Characteristics

Users and their roles and privileges are as described below in thetable.

Type ofUser

User Characteristic

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



7/14

3 APPLICATION ENVIRONMENT

3.1 Technology Environment

a. Hardware

Minimum Recommended Hardware:

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

Single processor Pentium class machines with 32 MB of RAM forweb 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



8/14

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 theinstallation of client application forthe outlook integration with the IDocdatabase.

Pre-Condition None

Assumptions Application would only sync theoutlook contacts.

Emails, tasks etc would come infuture release

Default Flow 1. User runs the exe

2. The wizard allows the user toinstall / integrate theapplication with outlook.

Post-Condition The application is successfullyintegrated with the outlook

A new tool bar would appear on theMicrosoft

Alternate Flow 1. User cancels the installationprocess

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 toconfigure the outlook clientapplication with the IDocs database.

Pre-Condition User has valid IDoc User Id/ Password



9/14

Assumptions

Default Flow 1. User choose to configure theclient application from theoutlook

2. User Enters the IDoc Userid/password

3. User saves the information.

4. The application is configuredwith the Outlook and IDocdatabase

Post-Condition

Alternate Flow

Exceptions/Errors If the account is not valid , user isprompted with the appropriatemessage 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 besynchronized between outlook and IDocs database

Pre-Condition

Assumptions

Default Flow 1. User selects the contact/contacts

2. User marks the selected contacts forSynchronization

3. The marked contacts are visually differentiatedfrom un-marked contacts

Post-Condition

Alternate Flow

Exceptions/Errors



10/14

Actors IDoc user

Sample ScreenShot

4.2.2 User deselects/unmark the contacts

Description User deselects/unmark the contacts that need to besynchronized

Pre-Condition Contacts are already marked for synchronization

Assumptions

Default Flow 1. User selects the contact/contacts

2. User unmark the selected contacts forSynchronization

3. The contacts are not marked for synchronization

Post-Condition

Alternate FlowExceptions/Error



11/14

s

Actors IDoc user

Sample ScreenShot

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 theoutlook fields with IDoccolumns

2. System displays a Defaultmapping.

3. User changes the IDoc columnname that is mapped with



12/14

outlook field

4. User saves the Mappinginformation

Post-Condition

Alternate Flow

Exceptions/Errors

Actors IDoc user

4.2.4 User synchronizes the contacts

Description This use case represents the Synchronization mechanismof 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 thatwould be imported from IDoc server to theOutlook

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 thatare marked for synchronization

8. User can deselect any of the contacts

9. System copies the outlook contacts to the IDocdatabase

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 validated4. System prompts the user for new account



13/14

settings( Follow use case 4.1.2]

Exceptions/Errors

1. If synchronization fails in-between, a proper log iscreated for the user to display all the users thatwere not synchronized.

Actors IDoc user

Other Points 1. Synchronization assures that the contact detailsare 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 forsynchronization before deletion]

Sample ScreenShot



14/14

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