Bug Tracking System

Group Members

• Syed Mughees Mehdi

• Salman Khan
• Tahir Ejaz
• Zahid Naeem
Table of Contents
1. Introduction 3
1.1 Purpose 3
1.2 Scope 3
1.3 Definitions, Acronyms, and Abbreviations 3
1.4 References 3
1.5 Overview 4

2. Overall Description 4
2.1 Use-Case Model Survey 4
2.2 Assumptions and Dependencies 5
2.3 Overview of DTS 6

3. Specific Requirements 7
3.1 Use-Case Diagram 7
3.2 Use-Case Reports 9
3.2.1 Submit Defect 9
The system automatically generates e-mail to the developers and project manager of that particular
project. 9
3.2.2 Update Defect 10
 Bug Tracking System
1. Introduction
1.1 Purpose
The 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 Scope
The 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 Abbreviations

Following are some abbreviations needed to properly understand the SRS
document.

 DTS-Defect Tracker System.

 CRM-Customer Relationship Management.
 TBD- To Be Decided

1.4 References
Following 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 Overview
This 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 Client Form Designer

DTS Client Form Designer
Application Application
Application Application

DTS XML files Form

Client Designer
Database Database

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.
3. Specific Requirements
3.1 Use-Case Diagram

Submit Bug

tester

update Bug

clients

Close Bug

assign bug
developer

View Bug Status

project development
manager

generate report

QA manager
generate analysis
 Login

Developer
Logout

Process Search

Tester
Process Notify

Add Notes
QA manager

Send Alert

Project Dev.
Manager Customize layout

Process Help

Manager

View History
 3.2 Use-Case Reports
3.2.1 Submit Defect

3.2.1.1 Introduction
This 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 Inputs
When 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 Processing
The 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.

Email Notification

Tester Submit Bug

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 Introduction
Update 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 Processing
The 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.

Add Notes

Developer Update Bug

Update Priority

Update Status
3.2.3 Close Defect functional requirements

3.2.3.1 Introduction
Project 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 Inputs
Update status field.

3.2.3.3 Processing
When 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 Outputs
Notification sent to the concerned users.
3.2.4 View Defect functional requirements

3.2.4.1 Introduction
Every 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 Inputs
Request for view

3.2.4.3 Processing
System 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 Outputs
Generate 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 Processing
Execute 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 Introduction
Before 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 Processing
A table containing Defect history information is displayed.

3.2.7.4 Outputs
Defect history

3.2.8 Login functional requirements

3.2.8.1 Introduction
Every 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 Inputs
User Id and Password of the user.

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

3.2.8.4 Outputs
As a result, the user would enter the system.

3.2.9 Logout functional requirements

3.2.9.1 Introduction
Every 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 Inputs
Request to logout.

3.2.9.3 Processing
 Current session would expire.

3.2.9.4 Outputs
No 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 Introduction
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.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 Outputs
The 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.