Bug Tracking System

Group Members

Syed Mughees Mehdi Salman Khan Tahir Ejaz Zahid Naeem

Table of Contents

1. Introduction 4

1.1 Purpose 41.2 Scope 41.3 Definitions, Acronyms, and Abbreviations 41.4 References 41.5 Overview 5

2. Overall Description 5

2.1 Use-Case Model Survey 52.2 Assumptions and Dependencies 62.3 Overview of DTS 7

3. Specific Requirements 8

3.1 Use-Case Reports 83.1.1 SUBMIT DEFECT 83.1.2 UPDATE DEFECT 93.1.3 CLOSE DEFECT 103.1.4 VIEW DEFECT STATUS 113.1.5 GENERATE REPORT 113.1.6 GENERATE ANALYSIS 113.1.7 DEFECT ASSIGNMENT 123.1.8 LOGIN 123.1.9 LOGOUT 133.1.11 ADD NOTES functional requirements 13

Bug Tracking System

1. Introduction

1.1 PurposeThe purpose of this document is to collect the requirement specification of the

Defect Tracking System. It takes a focused approach for identifying the explicit system requirements of the Defect tracking system.

The purpose of this SRS is to supply our customer (in this case the general Market) with an outline of a software product that will provide them with a reliable and in house Defect tracking system.

Individuals that is responsible for reviewing proposals of this system. This may include Q/A managers, testers, project managers, developers, clients of the company.

The database system is development on the basis of

1.2 ScopeThe document spans all principal requirement specification functions, which will

be embedded in the Defect Tracking System. All functional specifications, such as input and output to various modules, images handling will be defined/mentioned in this manuscript. It is also hoped that it helps us to create a clear picture of exactly what are the external requirements for the development of the software.

1.3 Definitions, Acronyms, and AbbreviationsFollowing are some abbreviations needed to properly understand the SRS

document.

DTS-Defect Tracker System. CRM-Customer Relationship Management. TBD- To Be Decided

1.4 ReferencesFollowing is a list of some references

http://www.seapine.com http://scarab.tigris.org/integration.html http://www.extraview.com http://www.trilobyte.net/barnsons/html/aboutthisguide.html www.netresultscorp.com/pthelp4/Admin/help_prior_install.html www.gara.com/solutions/srs.htm

1.5 OverviewThis document encompasses the descriptions and dependencies of the use cases. It

also describes the external requirements of the use cases. This document contains all the software requirements to a level of detail sufficient to enable designers to design a system to satisfy those requirements and testers to test that the system satisfies those requirements. When using use-case modeling, these requirements are captured in the use cases and the applicable supplementary specifications.

2. Overall Description

2.1 Use-Case Model Survey The main actors or the users of the system are:

Q/A manager Tester Project Development Manager Client Developer

Since this is in house software, all the users of the DTS are directly or indirectly related to the organization.The main tasks or functions that shall be developed in DTS are:

Login Logout Submit Defect Update Defect Close Defect Delete Defect Assign Defect View Defect Status Generate report Add notes Generate Analysis Search Defect Notify Defect

2.2 Assumptions and Dependencies

Software developers assume that the target client’s network support Microsoft.net platform application. available, or can be installed on the system under which it should function

DTS Client application depends upon the DTS administration software. DTS admin. is responsible for adding, deleting, updating projects, addition/deletion of development team members through sign up mechanism. DTS client is dependent upon the admin part because a project must first be opened through DTS admin before using it in the Client application.

In order to enable customizable form generation, it is required that the user provides his/her options for form design through the DTS Admin.

Software developers assume that hardware/software combination of the host System will be able to support the load associated with an e-commerce Application.

Software developers assume that there will be a System Administrator that will maintain this system.

2.3 Overview of DTS

DTS is a client application, designed for the Rebis/Trivor. The whole software consists of two major components, which are:

DTS Client application DTS Form designer

The two components would interact with each other through data exchange. This data exchange would take place using XML files. XML provides a standard approach for describing, capturing, processing and publishing information.

DTS would capture, manage and communicate the business and technical issues critical to the software development cycle, which empowers software enterprises to maintain superior product quality, perform management with ease, prioritize issues within a compressed development cycle, and link global development teams and service groups.

DTS is linked to the development processes in an organization. For customized reports to be generated, administrator component would collect information from user, and provide it to Defect tracking system through XML files.

DTS Client

Database

DTS Client

Database

Form DesignerApplicationForm Designer

Application

XML filesXML files

DTS ClientApplicationDTS Client

Application

Form DesignerDatabase

Form DesignerDatabase

3. Specific Requirements

3.1 Use-Case Diagram

Submit Bug

Close Bug

tester

update Bug

clients

View Bug Status

developer

assign bug

generate analysis

project development manager

generate report

QA manager

Login

Logout

Add Notes

Manager

View History

Project Dev. Manager

Process Help

Tester

Customize layout

Process Search

Send Alert

QA manager

Developer

Process Notify

3.2 Use-Case Reports

3.2.1 Submit Defect

3.2.1.1 IntroductionThis function is called when a Q/A tester encounters a Defect in any of the software that is in their testing phase.

3.2.1.2 InputsWhen a submitter selects the submit option, a submit form is displayed.The tester enters a brief description of the Defect, submission date, severity, status, in the required input fields. He might attach, modify, or delete notes and part of the code, where he encountered the Defect, may also be attached. Some keywords are also added to each Defect record in order to eliminate duplicate Defect record insertion.

3.2.1.3 ProcessingThe system takes the Defect description and the data entered by the submitter. In order to minimize duplicate Defect entries, the Defect info is checked against the keywords attached to the existing Defects in the database. If the Defect does not exist previously, it is added into the database, and a duplicate key alert is sent to the submitter if a match is found. Submitter then checks for the duplicate entry. He then declares it to be redundant or not looking at the current and previous entries. The submitter is then informed about submit success/failure.

Submit BugTester

Email Notification

Add To History

3.2.1.4 Outputs

A new record, containing Defect info, is added to the database

A confirmation message representing successful insertion of the Defect record, is displayed to the user, in the case of success.

The system automatically generates e-mail to the developers and project manager of that particular project.

3.2.2 Update Defect

3.2.2.1 IntroductionUpdate Defect info involves modifying the value of some fields in the database corresponding to a Defect e.g. changing the status of the Defect from pending to fixed, adding/modifying/deleting notes, changing the priority of a particular Defect, assigning the Defect to a different developer, modifying description etc. Every user (tester, developer, manager) has it’s own rights for the update Defect. These rights are defined in the DTS admin software.

3.2.2.2 Inputs Request to update database field. User selects update Defect option. An update Defect form is displayed. New values for the field to be changed, are entered.

3.2.2.3 ProcessingThe system checks the user rights to update that particular field, if he/she is not allowed then the system returns with appropriate failure notification, else the field is updated.

3.2.2.4 Outputs Notifies the user in case of failure. Notify the project manager, developer or any one else(members of interest

list) involved in tracking that Defect about the modification.For description of interest list, refer to the appendix.

Developer

Add Notes

Update Priority

Update Bug

Update Status

3.2.3 Close Defect functional requirements

3.2.3.1 IntroductionProject development manager and QA manager would have rights to close a Defect, that has been fixed by the developer. Close Defect would be done ,by changing the resolution field to close.

3.2.3.2 InputsUpdate status field.

3.2.3.3 ProcessingWhen the QA manager or project development manager are informed about the fixing of Defect, he/she can update the status of Defect by setting the resolution field to closed. The system marks the Defect closed.

When the Defect is closed, a row is added to the Defect history indicating who has closed the Defect, at what date and time.

3.2.3.4 OutputsNotification sent to the concerned users.

3.2.4 View Defect functional requirements

3.2.4.1 IntroductionEvery developer would be able to view the Defects present in his/her in-tray (Defects assigned to him/her). He may also explore different Defects, project-wise.

User would be allowed to customize the view (he may change sorting order, sorting criteria, background/foreground colors etc. according to his/her own choice.)

Different attributes associated with each Defect would be displayed along with the particular Defect info. These attributes include read/unread flag, assigned/not assigned etc. All the actors including developers, testers, and managers in order to keep track of project status and its progress etc would retrieve information regarding Defects. The user can also search a particular Defect by submitting search criteria in the search section. The full-text search can be performed on the keyword provided.

3.2.4.2 InputsRequest for view

3.2.4.3 ProcessingSystem checks the extent of user rights to view the Defect status. Some user e.g. project manager might have more privileges. For instance, he may view status of all the projects

3.2.4.4 OutputsGenerate status-customized view.Notification in case of failure.

3.2.5 Generate Defect Reports functional requirements

3.2.5.1 Introduction

Generically refers to a broad class of management data that can be collected, displayed and printed. Reports are divided into two main categories: graphical reports and tabular reports. Graphical reports give a pictorial view of the data, such as pie charts, bar charts, and line charts. Tabular reports show the data in its raw, numeric form.

3.2.5.2 Inputs

Request to run specific query

3.2.5.3 ProcessingExecute the query, which has been selected by the user.

3.2.5.4 Outputs

View graphical or tabular data of your last report request. To run a report, select it from the personal or shared folders in the project view or you can create a custom report.

3.2.6 Get Help functional requirements

3.2.6.1 Introduction

The users may take help. DTS provides a complete help system.Help system includes indexing, alphabetical listing of contents, and search capabilities. i.e help topics may also be searched by entering a search criteria.

. 3.2.6.2 Inputs

Get help option is selected. How to take help also selected.(content listing, indexing, search ) The search criteria provided to search.

3.2.6.3 Processing

A list of Interactive help topics are displayed The user selects one, in order to get a detailed picture.

3.2.6.4 Outputs

Help files generated

3.2.7 View History functional requirements

3.2.7.1 IntroductionBefore start working on a Defect fixing, a user may be interested in viewing Defect history. Defect history encapsulates all the Defect related information representing name, date, time, of action and action itself as well.

3.2.7.2 Inputs Option to view Defect is selected.

3.2.7.3 ProcessingA table containing Defect history information is displayed.

3.2.7.4 Outputs Defect history

3.2.8 Login functional requirements

3.2.8.1 IntroductionEvery user will have to login to the system. This function makes the system more secure and avoid any interruption from unrelated user. The login mechanism would also help in distinguishing different users, their roles, and the privileges that they possess for using the system.

3.2.8.2 InputsUser Id and Password of the user.

3.2.8.3 ProcessingChecks, for the validity of user name and password, in the database.

3.2.8.4 OutputsAs a result, the user would enter the system.

3.2.9 Logout functional requirements

3.2.9.1 IntroductionEvery user who has logged in may choose to logout, when he is done with using the system. If the user closes the system without logging out, there would be a timeout mechanism according to which, his session would expire after some pre-specified time.

3.2.9.2 InputsRequest to logout.

3.2.9.3 ProcessingCurrent session would expire.

3.2.9.4 OutputsNo specific output.

3.2.10 Search Defect functional requirements

3.2.10.1 Introduction

Search process in the DTS environment is used to improve performance, to avoid redundancy, to let the managers manage the Defect tracking process more efficiently and to give user a feeling of instant gratification.

Users may search different Defects besides project-wise browsing and manually finding the Defect. The user will carry out search on the basis of search criteria entered. This function would allow fast and direct access to the desired Defect.

3.1.10.2 Inputs

The user selects the search criteria. User will enter the keyword to search.

3.1.10.3 Processing

The system scans the database to find a match.If a match is found, the whole tuple or record or row is saved in attempt space.The system moves forward to find the next match and the process continues till the whole database has been scanned.The system then checks the user settings, to provide him with a customized view.The system then picks the entire row from the temp space and based on the user setting or display options, displays the retrieved rows. Search keyword will be compared to the description field of Defect info or to the keywords associated with a Defect in the database.

3.1.10.4 Outputs

The search operation would result in the retrieval of the submitter, project, Defect or any other field that was searched upon. The search can also result in a failure message if either the requested entity could not be found or the user did not have the rights to the specific data.Complete Defect info would be displayed if a match occurs. User would be notified with a failure message, if there were no match.

This is also possible that more then one entry match the search criteria; in such case, a complete list of matched Defects would be displayed in the order of relevance.

3.1.11 Add Notes functional requirements

3.1.11.1 Introduction

Whenever a developer, tester or the manager finds something useful and relevant to a Defect, he may enter Defect notes. Defect notes would help the developer in fixing it.Members of the interest list for a project may also add notes. An interest list would be maintained for every project. Developers or testers, which are not directly elated to the project, may also add them in the interest list. So they will be notified any updates in the project.

Notes are submitted along with the title, which helps user to view the information they want as quickly as possible.The notes are any additional information corresponding to the Defect that can be placed in any specific field of the database or is too vague or general to be defined in any specific jargon. But nonetheless is important in the Defect tracking and Defect resolution cycle.

Any one with in the interest list of the Defect can generally view notes belonging to a Defect. It is like a notice board with relevant information about the Defect.

3.1.11.2 Inputs

Notes title or subject. The subject and title defines the type of note e.g. project notes, Q/A notes.

The description of the note.

3.1.11.3 Processing

The system automatically enters the date of submission, time of submission, the author of the note.

All the information about the note automatically added to the history. The notes along with all the information is saved in the database. It is visible to all he users as long as its author or the administrator does

not delete the note.

3.1.11.4 Outputs

Notes become visible to all the authorized user of DTS who can access the Defect.

3.1.12 Delete Notes functional requirements

The notes are any additional information corresponding to the Defect that can be placed in any specific field of the database or is too vague or general to be defined in any specific jargon. But nonetheless is important in the Defect tracking and Defect resolution cycle.

Any one with in the interest list of the Defect can generally view notes belonging to a Defect. It is like a notice board with relevant information about the Defect.Developers notes

Due to any kind of miss representation or wrong submission of the information a developer can delete the notes he submitted without too much of hassle. Only the developer who summated the notes can delete or modify them. Since the developer or the owner of the Defect is the one who directly confronts the Defect therefore his submitted notes can be very critical in beg management process.Project notes

Project notes submitted by the project manager can also be deleted if they either: do not relate to the Defect in any way are not accurate can be misleading

Project manager notes apart from the project notes a project manger can add further notes informing ever one with in the interest list about change of status of project.General submitted by users from interest list can also be modified. But only the notes submitter can as a rule delete or modify his notes no one else can do that. Anyone else can only add notes.

3.1.12.2 Inputs

The user selects a note.The user selects the delete option.

3.1.12.3 Processing

The system verifies the user rights to delete the note. If the user is verified the user is prompted by the system to confirm his

action. On user confirmation selected note is deleted from the database.

It is removed from the Defect information, but would remain in the Defect history.

3.1.12.4 Outputs

The note is no more available and accessible.

3.1.13 Modify Notes functional requirements

3.1.13.1 IntroductionThe notes are any additional information corresponding to the Defect that

can be placed in any specific field of the database or is too vague or general to be defined in any specific jargon. But nonetheless is important in the Defect tracking and Defect resolution cycle.

Any one with in the interest list of the Defect can generally view notes belonging to a Defect. It is like a notice board with relevant information about the Defect.

3.1.13.2 Inputs

The user selects a note.The user selects the delete option.

3.1.13.3 Processing

The system verifies the user rights to delete the note. If the user is verified the user is promoted by the system to confirm his

action. On user confirmation selected note is deleted from the database. It is removed from the Defect information, but would remain in the Defect

history.

3.1.13.4 OutputsThe note is visible in its new form, only the history of its modification is saved but the contents are overwritten.

3.1.14 Edit Style Sheets functional requirements

3.1.14.1 Introduction

The style sheets are used to allow users of the DTS to acquire a view they are comfortable with or are interested in. When a user first time logs in to DTS he is provided with a standard style sheet view. From the tools menu he can select the option of edit style sheet. The user can make visible, invisible, position a number of fields. The choices available to him are dictated by the DTS administration part. The user can also save the style sheet setting if he wants the changes to be permanently visible to him.

3.1.14.2 Inputs

The user selects a field. The user changes the setting of the field.

3.1.14.3 Processing

The user selects Style Sheet from the Options drop-down list.

The Project Style Sheet dialog box appears.

The user can change a number of fields in the display and hence customize his display. The user can:

Select the type of style sheet to use from the Type drop-down list: Personal, Project, or System. Personal style sheets you create and save. Project style sheets are created and defined at the project level and shared publicly. System style sheets are the standard style sheets shipped with Tracker.

User can select the number of fields appearing on his page i.e. id title, open date, close date and so on.

The user can even select the representation of information, i.e. whether what should be the size of each field and how does it appear, i.e. the position and placing of each attributes

The user can hide some attributes if he thinks that are not related to him.

After selecting the fields the user needs to confirm his selection by clicking OK.

The systems save the user defined setting and whenever next time the user logs in the users custom page appears.

3.1.14.4 Outputs

The user main page appears as designed by him.

3.1.15 Send Alerts functional requirements

3.1.15.1 Introduction

Alerts are system generated simplified version of e-mails. Some alerts are default that have to be sent under any condition but there are some actions for which the user of DTS can select whether he wants to send an alert or not. In that case he selects the enable/disable option from the user option menu.

3.1.15.2 Inputs

No input in case of default alerts. The user changes any an accessible and modifiable field corresponding to the Defect.

3.1.15.3 Processing

The system checks the user’s rights to modify the particular field. If the user has been confirmed to be modifying a perfectly legitimate field,

the system performs the appropriate changes in the database. The system composes e-mail with information about the changed field. The system retrieves all the e-mail addresses of all the members in the

interest list. The system sends instant alerts to the interest list members.

3.1.15.4 Outputs

All the members of the interest list are notified.

3.1.16 Notify Defect functional requirements

3.1.16.1 Introduction

The notify Defect use case is used when the Q/A tester detects a Defect in any of the projects that are in the testing phase. The tester adds the new Defect in the Defect list corresponding to the project.

3.1.16.2 Inputs

Defect title. Defect description The O/S of the project in which the Defect was found. The functional area in which the Defect was detected.

How it was found.

3.1.16.3 Processing

The system enters the current date and time as the Defect opening time. The Defect status is open but it has no owner, as yet i.e. it is unassigned. The system enters anew Defect in the project Defect list. Alerts are sent to the appropriate people. The project manager is informed about the new Defect, so that he can

assign it to some one as soon as possible. An interest list for the Defect is created.

3.1.16.4 Outputs

Number if Defects with in the project increases.