Problem Tracking Tool

Software Requirements Specifications

Version 1.1

FEBRUARY,2011

Warning This is a hard copy of a document maintained on electronic media. It may not be the latest version. Kindly ascertain the latest version from the Document Master List available with the Project Leader.

<Name of the Project>

Software Requirements Specifications ver. <nn.rr>

DOCUMENT RELEASE NOTICE

Document Details: Name Software Requirements Specifications Revision Details Action taken (Add/Del/Change) Preceding Page No. New Page No. Revision Description Version No. 1.1 Description SRS document for Problem Tracking Tool

This document and any revised pages are subject to document control. Please keep them upto-date using the release notices from the distributor of the document. Approved by: Authorised by: Date: Date:

Internal Use Only

<Name of the Project>

Software Requirements Specifications ver. <nn.rr>

PREFACE
Purpose of this Document
This document describes the System Requirements Specifications of the Problem Tracking Tool. This document lays down the software requirements for the application that have been captured through a detailed study of the business workflow and functions.

Intended Audience
This document is intended for use by the designers of the system, and for those who may be required to maintain it. The document will enable them to understand all aspects of the system in detail. It will enable HP to know that TCS has captured all the requirements. The document will also be used by HP for carrying out the acceptance testing for which it will form the.

Related Documents / References

Not Applicable.

Acronyms and Abbreviations

Abbreviation/Acronym Description

Organization of this Document

This document consists of a single section that comprises of :Introduction Functional Requirements User Interface Specifications External Interface Specifications Other Requirements

Internal Use Only

ii

<Name of the Project>

Software Requirements Specifications ver. <nn.rr>

TABLE OF CONTENTS
1. INTRODUCTION..................................................................................................................4 1.1 BACKGROUND.......................................................................................................................4 1.2 SCOPE...............................................................................................................................4 3.1 OUT OF SCOPE....................................................................................................................4 3.2 BUSINESS JUSTIFICATION FOR INVESTMENT..................................................................................5 3.3 PRODUCT PERSPECTIVE..........................................................................................................5 3.4 KEY ASSUMPTIONS, DEPENDENCIES, CONSTRAINTS AND OVERRIDING PRIORITIES.................................5 3.5 USER CLASSES AND CHARACTERISTICS......................................................................................5 3.6 HARDWARE AND SOFTWARE PLATFORM......................................................................................6 3.7 SITE ADAPTATION.................................................................................................................6 3.8 APPLICATION SECURITY..........................................................................................................6 3.9 MIGRATION REQUIREMENTS....................................................................................................6 4. FUNCTIONAL REQUIREMENTS.........................................................................................7 5. USER INTERFACE SPECIFICATIONS................................................................................9 5.1 GUI SCREEN LAYOUTS........................................................................................................10 5.1.1 Navigation Chart.....................................................................................................10 5.1.2 Screen Layout : <Screen Title>.............................................................................10 5.1.3 Screen Description.................................................................................................10 5.2 GUI REPORT LAYOUTS........................................................................................................10 5.2.1 Report Layout.........................................................................................................10 5.2.2 Report Description..................................................................................................10 6. EXTERNAL INTERFACE SPECIFICATIONS....................................................................11 6.1 SYSTEM INTERFACES............................................................................................................11 6.2 INTERFACE DESCRIPTIONS.....................................................................................................11 6.2.1 Message/Interface Specifications...........................................................................11 7. OTHER REQUIREMENTS..................................................................................................13 7.1 GENERIC REQUIREMENTS......................................................................................................13 7.2 USER ACCESS CONTROL AND SECURITY..................................................................................13 7.3 ARCHIVING AND HOUSEKEEPING..............................................................................................13 7.4 PERFORMANCE REQUIREMENTS..............................................................................................14 Total Number of pages: 16

Internal Use Only

iii

<Name of the Project>

Software Requirements Specifications ver. <nn.rr>

1. Introduction
1.1 Background
This document outlines the software requirement specification for the Problem Tracking tool. It is the outcome of the Analysis Phase during which discussions were held with the users. The objective of this Analysis Phase was to: Define the scope for the Problem Tracking Tool. Serve as the baseline for the design of the <specify name of the system>.

Any changes to requirements after acceptance of this document will be through appropriate change Management procedure, as detailed in the contract. Both the user and designer should go through the document carefully in order to ensure that: All the user requirements which need to be supported by the system have been identified and detailed. The document is a clear and unambiguous statement of functionality required from the system for the design and development team. The document can be used as a basis for development of the System Test data. It is essential to identify the problems, if any, with the basic structure of the proposed system at this stage. If these are not taken care of at this stage, it may be difficult to incorporate the desired modifications to overcome the shortcomings at a later stage.

1.2 Scope
1. The system to be developed is a stand-alone one. It is not meant to be integrated with any other existing system operating at the clients site. The proposed system shall provide access to Customers, Support, Manager, Administrator and Developers. Responsibilities for each action are access based where actions here refer to create, modify, search and delete of case/CR/solution.

2.

3.

The following entities will be a part of the Problem Tracking Tool: Requesters are used to interact with the customer and send requests for creation, deletion, modification and searching. Servers are used for creation, deletion, modification and searching of details pertaining to problems in the database. An authentication module will be implemented to validate users and entities like Case_Id etc. A problem is reported by the customer to the support people who interacts with the system to log a new case. Analysis of a case by a developer or support is treated as a Solution. The design, code and test information for a fix provided by a developer is treated as a Change Request (CR).

3.1 Out of Scope

The system will not provide report generation facilities. Functionality of wild card is not present.
Internal Use Only 4

<Name of the Project>

Software Requirements Specifications ver. <nn.rr>

3.2 Business Justification for Investment

This system is responsible in enhancing the bug reporting and resolving them at a much faster rate due to following issues: The previous system was unable to properly resolve the bugs properly New system will be more helpful and fast in bug reporting. Reliable and specific solutions will help in much faster bug recovery. Bugs will be resolved at much faster rate.

3.3 Product Perspective

The problem tracking tool is a stand-alone, self contained product. It is used to keep a track of all the bugs reported, solutions designed and the change request generated for a particular product.

3.4 Key Assumptions, Dependencies, Constraints and Overriding Priorities

The successful execution of the assignment will depend on the following factors: 1. The system will facilitate easy and quick retrieval of all related information. 2. Only Manager can allocate a specific problem to a developer. 3. Allocation of solutions of cases to Developers is the responsibility of the manager.

4. Developers, managers and customers cannot log a new case.

5. Customers can only view cases and its solutions. 6. Customer doesnt specify GUI requirement. 7. Problem statement can be of maximum 250 characters. 8. 9. 10. 11. 12. 13. 14. There is many-to-one relation between product and developer. Modification will be done based on the Case Id, Solution Id or CR Id. Modifying after closed status of any entity is not permitted. Developer, Administrator and Manager can change the status of Solution and CR. Case title can be of maximum 80 characters. Developer can delete and modify the solutions and CR of which he is the owner. Support person knows all the existing solutions and their respective IDs.

Dependencies The availability of "pathway environment" to facilitate proper "requester-server" interaction. Constraints The system is not portable on non-Tandem systems.

3.5 User Classes and Characteristics

The system is intended for 4 types of users, each having role based access and the type of case:

Internal Use Only

<Name of the Project>

Software Requirements Specifications ver. <nn.rr>

Customers - Has complete access to view cases and solutions of the problems and however he cannot view CR. Support People- Can log and edit Cases ,solutions and view cases, CR, solutions and search fixes. Developers- Can create, edit, and delete solutions and CRs of which he is the owner. Manager - Can search for a record, update status of problem and create an entity linked to a developer. Can also edit all other information and assign solutions to developers. Developers can only assign CRs to themselves. Administrator- Can View, Create, Modify, Delete Cases, CRs, Solutions provided it does not violating referential Integrity. This is taken care by the application through an error message.

3.6 Hardware and Software Platform Hardware Requirement

TNS-E System

Software Requirement
TNS/E RVU Version: H06.22.180 Testware: TACL/ Macros Debugger: Visual Inspect C programming on requester side. TAL programming on server side. SQL Database

Functions
The output screen supported by System is capable of displaying only 24 rows at a time, each row having a maximum of 80 characters .

3.7 Site Adaptation

This new system will be fully operational and the users will be much more compatible in operating it. The bug can be easily reported by a new user also.

3.8 Application Security

The system is fully secured in its own as only the customer can view his/her cases or bugs reported. If the bug reported presently is available then specified solution is provided to him after the bug reporting is done by him. All the users have a distinct user Id and password.

3.9 Migration Requirements

< Detail the Migration strategy for data that needs to be migrated from the existing system to the proposed system >

Internal Use Only

<Name of the Project>

Software Requirements Specifications ver. <nn.rr>

4.Functional Requirements
Login Module:
Shall authenticate each user of the system and accordingly provide him associated functionality. The fields of Login will be o UserId. o Password.

Create(Case, CR, Solution) Module:

i. ii. Shall allow authenticated/appropriate users(e.g. support) to insert new Problem cases. The fields of this module are mentioned above under entities. The case id will be generated by the system and the status by default will be unresolved. Shall allow authenticated/appropriate users(e.g. manager and developer) to insert new solution corresponding to a case. The fields of this module are mentioned above under entities. The solution id will be generated by the system and the status by default will be incoming. Shall allow authenticated/appropriate users (e.g developer and manager) to insert new CR. The fields of this module are mentioned above under entities. The CR id will be generated by the system and the status by default will be unreleased.

iii.

Delete Module:

Delete permissions on specific entities are given to those people who have the right to create those entities. e.g. Administrator can delete Case, Solution and CR. Manager can delete Case and Solution. Developer can delete CR and Solution. Support can delete Case.

Shall allow Administrator, Managers and Developers to modify all fields(except IDs and date) of Case Solution CR Example: developer and manager can modify description of case. Support people can modify Case.

Modify Module:

Search Module:

Allows each user to search information pertaining to Problems on the basis of Case Id Solution Id CR Id (except Customer). The search will have two options:1. Search all the related entities for a given Case_Id, Solution_Id and CR_Id. 2. Search for a specific Case_Id, Solution_Id and CR_Id.

Internal Use Only

<Name of the Project>

Software Requirements Specifications ver. <nn.rr>

Determine Software Requirements for

Applicabil ity to CDR (yes/no) Completion status (red, yellow , green or percentage)

Determine Software Requirements for

Requirements and Additional Comments

Internal Use Only

<Name of the Project>

Software Requirements Specifications ver. <nn.rr>

5.User Interface Specifications

User Login: 1. User ID 2. Password Customer UI: 1. Search Support UI: 1. Create case 2. Create solution 3. Search 4. View Change Request 5. Delete Case Manager UI 1. Create solution 2. Create Change Request 3. Modify Case 4. Modify Solution 5. Modify Change Request 6. Delete Case 7. Delete Solution Developer UI: 1. Create Change Request 2. Create Solution 3. Modify Case 4. Modify Solution 5. Modify Change Request 6. Delete Change Request 7. Delete Solution Administrator UI: 1. Create Case 2. Create Change Request 3. Create Solution 4. Modify Case 5. Modify Solution 6. Modify Change Request 7. Delete Case 8. Delete Solution 9. Delete Change Request

Internal Use Only

<Name of the Project>

Software Requirements Specifications ver. <nn.rr>

5.1 GUI Screen Layouts

Not Applicable

5.1.1 Navigation Chart

<A navigation chart showing the access routes to the screens should be included. A highlevel chart can be produced and decomposed to the number of detail levels required.>

5.1.2 Screen Layout : <Screen Title>

Not applicable

5.1.3 Screen Description

<Each screen layout should have an accompanying narrative. a. <Details of the screen may be given in the following format:> Attribute Name Description Remarks

5.2 GUI Report Layouts

<Give a brief description of the sub-section>

5.2.1 Report Layout

<The Report layout should be included in this section.>

5.2.2 Report Description

<Each report should be briefly described. A sample format is given below:> Title: Purpose: Intended Users: Frequency: Report Sequence: Business Logic: Title of the report Business purpose for the report Intended distribution Frequency of generation Description of the required sequence Description of any specific processing logic

Internal Use Only

10

<Name of the Project>

Software Requirements Specifications ver. <nn.rr>

6.External Interface Specifications

<Give a brief description of the section>

6.1 System Interfaces

<Describe in high level terms the requirements for integrating with other systems. Briefly define the messages/interfaces that need to be processed between the systems. Describe in high level terms the requirements for electronic trading with third parties, such as customers, statutory authorities and suppliers, using different communication modes including EDI, internet, fax and email.>

6.2 Interface Descriptions

<The following sections will be repeated for each interface required.>

6.2.1 Message/Interface Specifications

<Detail the definition of the requirement. A small description of messages may be given. A sample format is included below.> T i t l e : D e s c r i p t i o n : B u s i n e s s P u r p o s e : < Message title >

< Description/Content of the message >

<The context and rationale for each message >

Internal Use Only

11

<Name of the Project>

Software Requirements Specifications ver. <nn.rr>

Internal Use Only

12

<Name of the Project>

Software Requirements Specifications ver. <nn.rr>

7.Other Requirements
<Give a brief description of the section>

7.1 Generic Requirements

<Requirements which do not belong within a process flow, should be described within a separate section (a process model would not be required). An example of this would be multiple-language functionality.>

7.2 User Access Control and Security

<Describe the business requirements in the area of user access control and security. These requirements by and large will be addressed within the framework established for the generic service environment.> <Security provisions may be made at the following levels: Operating System Level Each user may be given separate log-in Id and password. They may be divided into three groups. Application User may have access to Application software only. These users may not have any access to the Operating System commands outside of Application Menus Operating System User may have access to user level Operating System commands in addition to the Application software and certain RDBMS tools Super User may have access to all the commands, including super user commands, at Operating System level apart from the above two. Besides above each user will be assigned a user code at the time of implementation of the system. It will be possible to set or change the password interactively. Each user or group of users will have access to certain screens/functions of the system relevant to his area of operation. The access rights for each user code will be recorded within the system. Each user will have to log-on to the system using the correct user code and password. In case of an invalid combination of these two codes, the system will display an error message and prevent further processing.>

7.3 Archiving and Housekeeping

Database Administrator (DBA) may own the database. These users may create, update and drop database objects, namely, table-spaces, tables and indexes etc.. The maintenance of the access rights may be done by them. Only they may have access to the security / access maintenance screens. Any modifications to the access rights may be made only with proper authorization. They may be responsible for overall maintenance and management of the RDBMS. System Administrator (SYSADMIN) may own the application. It may create, update and drop users, user groups for the application and provide required access to them.

Internal Use Only

13

<Name of the Project>

Software Requirements Specifications ver. <nn.rr>

7.4 Performance Requirements

<Describe the system availability requirements and the system performance requirements (e.g. response times and capacity) in critical areas of the system, and the envisaged system workload patterns and peak activity

Internal Use Only

14