CUSTOMER SUPPORT DEFECT TRACKING SYSTEM

SOFTWARE REQUIREMENT SPECIFICATIONS DOCUMENT

Submitted To: Mrs. Bijeta (Asst. Proff. in CSE)

Submitted By: Priyanka Dembla (CSE/08/141) Srishti Dhamija (CSE/08/159) Surabhi Gupta (CSE/08/163)

1. INTRODUCTIONWeb based Defect Tracking System serves wide span of Industries. This system helps organizations save Time, Money and Resources on projects. Defect Tracking System helps organizations to automate the process, of managing and tracking Issues throughout its life cycle till successful closure. It helps companies capture Issues and ensure time bound closure by complimenting with automated Reminders, and Alerts if required. The powerful reporting provides organizations realtime visibility into the quality and compliance system and provides critical information for reducing risk of non-compliance. A major component of a defect tracking system is a database that records facts about known defects. Facts may include the time a defect was reported, its severity, the erroneous program behavior, and details on how to remove the defect; as well as the identity of the person who reported it and any programmers who may be working on fixing it. Typical defect tracking systems support the concept of the life cycle for a defect which is tracked through status assigned to the defect. A defect tracking system should allow administrators to configure permissions based on status, move the defect to another status, or delete the defect. The system should also allow administrators to configure the defect statuses and to what status a defect in a particular status can be moved. Some systems will e-mail interested parties, such as the submitter and assigned programmers, when new records are added or the status changes. 1.1 Purpose (1)The purpose of this document is to collect the requirement specification of the Defect Tracking System. (2)It takes a focused approach for identifying the explicit system requirements of the Defect tracking system. (3)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. (4)Individuals that are responsible for reviewing proposals of this system may include Q/A managers, testers, project managers, developers, clients of the company. 1.2 Scope of the project The major scope areas include: (A)Create a defect tracking product for self organization.

(B)Enhance scope to meet more defect tracking requirements and make it available to customers. (C)Integrate with third party defect tracking systems. (i)Creating a defect tracking product is a large project (many man years) consistent with Perforce expanding into the general software engineering tools market. The project changes the way that Software is managed. (ii)Enhancing Scope is likely to meet the requirements of the real market for defect tracking -- engineering management -- and could also comprise the conceptual integrity of any software delivered to the end users. (iii)Integrating with third party systems is a relatively small but substantial project that would satisfy the demands made by most organisations, and requires major expansion in the Software. 1.3 Definitions, Acronyms and Abbreviations UsedFollowing are certain abbreviations which are necessary to understand the SRS CS-Customer Support DTS-Defect Tracking System

FC - Fully Compliant PC Partly Compliant NC- Non Compliant D - Dependency

1.4 Reference Following is a list of some references www.wikipedia.com www.w3schools.com www.extraview.com1.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 specification

2. OVERALL DESCRIPTION 2.1 Product Perspective Existing System:

The existing system cannot be customized as per the requirements of the users. Manual entries in excel file and generation of reports is not as per the requirements. Each time an entry has to be made manually in the excel file.

Proposed System:

The computerized software can be shared and used by all simultaneously in the given organisations and end users. Friendly usage of the system as its GUI based. Allocation of problems to the users can be assigned easily and report generation of fixed defects is easy. Efficient ways of testing through this project is easy and fixing of errors is fast.

Detailed Diagram of the Proposed System is as shown:

User

User Registration

Register User Validate Login Login Defect s

Administrator

View Defects View

Assign User Defects

Defe cts

Edit Defects Updation

Finish Bugs

UpdationDefect s

Reports

2.1.2 User Interface The System also requires an interactive user interface to manage the data. The interface must have the following features Login/Logout Record Insertion Record Searching Record Editing Record Deleting

Displaying various type summary 2.1.3 Hardware Interface Processor RAM Hard Disk Monitor Keyboard Mouse : : : : Pentium IV 512 MB 40 GB 14

2.1.4 Software Interface Software Requirements: JDK/JRE Apache Tomcat J2EE MySQL 2.1.5 Communication Interface (A) FRONT END: (a) J2EE Java 2 Enterprise Edition is a programming platform part of the Java Platform for developing and running multitier architecture Java applications, based largely on modular software components running on an application server. (b) TOMCATIts an application server which is mostly used in the web-applications. It implements the Servlet 2.5 &JSP 2.1 specifications. Its a cross-platform application Server. (c) JSP Java Server Pages(JSP) is a server side Java technology that allows software developers to create dynamically generated web pages, with HTML, XML or other document types. JSPs are compiled into Servlets by a JSP compiler. (d) SERVLET Servlets are Java programming language objects that dynamically process requests & construct responses. The Servlet APIs are contained in the javax.servlet & javax.servlet.http packages. Servlets can be generated automatically by Java server Pages(JSP) compiler.

(e)NetBeans NetBeans is the most comprehensive J2EE IDE() for the open Source netbeans platform.It incorporates most innovative open standard technologies to provide a development environment for J2EE WEB,XML,UML & database & a wide array of application server connectors to streamline development ,deployment, testing & portability.Its a cross-platform. (B) Back END: Structure Query Language(SQL) A query language for RDBMS based on. Non procedure approach to retrieve record from RDBMS. SQL was proposed by IBM and got its standardization by ANSI and adopted by different corporation with bit modification. 2.1.6 Memory Constraints 512 MB RAM and 40 GB hard disk required 2.1.7 Operations

2.1.8 User Characteristics Our primary users will be end users and organization employees. It is likely they have had some previous computer experience. It can also be assumed they have experience with whatever language the document is in.

2.1.9 DATA FLOW DIAGRAM AND ER Diagram

DataFlow Diagram : (Level-0) :

Admin INTERFACE

Employee INTERFACE

CSDTS Customer INTERFACE

Database

Fig 1. Level 0 DFD

Level 1 & 2 DFD :Employee & customer

Admin

1 CSDTS IMS

create

Employee/customer

Add projectstatus

Assign

2 CSDTS IMS login

Project /defect

View/work

3 CSDTSIMS

update

profile

Complain/statu supdate

4 CSDTSIMS

profile

E-R DIAGRAM ID name unam e

add ID admin

project pwd name addEmployee/customer

assign Id date revert na me

login

Project/defect

Project/defect

proid

Com_dat e

Defect complain

view

Defect_n o

date Proid

status

2.2 Product Functions (1)Planning and Estimation

In defect tracking, a tool would help the management control which defects will be resolved and when. It would also help understand which resources are required, and measure the costs involved. Specifically, a system usually allows changes to be planned which will resolve defects or implement enhancement requests. The changes are usually related to a release, and often scheduled for a particular time frame or milestone. Note that the changes are often not the same entities as the record of the defect or enhancement request: more than one change may be required at different times, or on different branches, to satisfy the customer.

(2.) Tracking In defect tracking, this is about monitoring the progress of changes, and intervening when necessary to keep things on schedule. Often re-planning is required, requiring the plan be flexible and cheap to modify. In addition, when controlling a large group, the manager has to be able to get a measurement of overall progress, such as the proportion of changes behind schedule or the total estimated effort behind schedule. (3) Control In defect tracking, the main resource is the effort of the engineers. The defect tracker must allow the manager to assign work to engineers, or even delegate areas of work to subordinate managers. The engineers need to know what work has been assigned to them, and feed back information about the progress of that work to the management for tracking purposes. Since each defect or enhancement request goes through many stages on its way to being resolved, there are usually a number of different tasks which might be assigned, with different criteria for completion. (4) Process Implementation and Change The process is the program for the organization -- the way that the organization does things. Process evolution is how the organization modifies its process over time in order to improve its methods or deal with changing circumstances. Often, most of the engineering department's process is implemented by the defect tracking system, especially if enhancement requests are processed like defect reports. A well developed process for a medium sized engineering organization would be like this: Defect report or enhancement request received.

2.3 General Characteristics All components will be developed using Java Technologies with Net beans 6.9 IDE.

The My SQL 5.0 Server shall be used for RDBMS. The Apache Server 2.2.11 shall be used Application compatibility for all the application package with following environment: Windows XP (32 bit and 64 bit) Linux All visible parts (GUI) are based on JSP/HTML Forms. Architecture (Components, namespaces, interfaces, etc.) will be taken into account. All the passwords shall be stored into the database. 2.4 Life Cycle ModelThe waterfall model is a sequential design process, often used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design, Construction, Testing, Production/Implementation and Maintenance.The unmodified "waterfall model". Progress flows from the top to the bottom, like a waterfall.

The waterfall development model originates in the manufacturing and construction industries: highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development.[citation needed] The first known presentation describing use of similar phases in software engineering was held by Herbert D. Benington at Symposium on advanced programming methods for digital computers on 29 June 1956.[1]

This presentation was about the development of software for SAGE. In 1983 the paper was

republished[2] with a foreword by Benington pointing out that the process was not in fact performed in strict top-down, but depended on a prototype. The first formal description of the waterfall model is often cited as a 1970 article by Winston W. Royce,[3]

though Royce did not use the term "waterfall" in this article. Royce presented this model as an example of

a flawed, non-working model (Royce 1970). This, in fact, is how the term is generally used in writing about software developmentto describe a critical view of a commonly used software practice.[4]

3. SPECIFIC REQUIREMENTS The Bug Tracking System is not so complex but it requires a well defined database system to manage and provide the retrieval of data like products, version details, users, bug details, work in progress and so on.

The System has to manage the product bugs life cycle i.e submission of bugs, assignment of bugs, and resolution of bugs and so on. In order to keep track of all these data and activities , the system has the following requirements

3.1 Functional Requirements(A)Submit Defect FR (a)Introduction: This function is called when a Q/A tester encounters a defect in any of the software that is in the testing phase. (b) 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. (c) 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

(B) Update Defect (a) 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 its own rights for the update Defect. These rights are defined in the DTS admin software. (b) 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.

(c) 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. (d)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.Add Notes Update Priority Update Bug Update Status (C) Close Defect functional requirements

(a) 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. (b) Inputs Update status field.

(c) 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. (d) Outputs Notification sent to the concerned users.

(D)View Defect functional requirements (a)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.) (b) Inputs Request for view

(c) 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

(d) Outputs Generate status-customized view. Notification in case of failure. (E) Generate Defect Reports functional requirements (a)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. (b) Inputs Request to run specific query (c)Processing Execute the query, which has been selected by the user.

(d)OutputsView 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. (F) Login functional requirements (a) 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. (b) Inputs User Id and Password of the user. (c) Processing Checks, for the validity of user name and password, in the database. (d) Outputs As a result, the user would enter the system. (G) Notify Defect functional requirements

(a) 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. (b)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. (c) 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.2 Logical Database Requirements Following are the required details that should be managed by the system Product Details Product Version Details Bug Details User/Developer Details Bug Assignment Details Bug Resolution Details Bug History Details 3.3.1 Standard Compliance This section lists for all functionality requested, whether it is in scope, e.g. FC, (PC), NC, and D. Functionality Compliancy (FC = Fully Compliant, PC = Partly Compliant, NC= Non Compliant) and D = Dependency if any Functionality Descriptions

The general pages/link that has to be integrated with the project are: Home page with Project Details Home page information contains Header with logo. Menu Links(Home, About us, Contact us and Login) Body content contains : Project Details which is static About Us Static Information about the projects C) Contact Us 1) static information about the students who is make the project d) Login 1) Login Employee, customer and admin. Admin login is fixing and admin is providing login information to employee and customer. CSDTS(Admin) Add New Employee List /Update/Remove Employee Add New Customer List/Update/Remove Customer Add New Project List/Update/Remove Project Assign Project for Employee List of Assign Project with status List of Defects with status Assign Defects to Employee CSDTS(Employee) Login to Application Update our Profile Change Password View Assign project Add Assigning project status View Defects Handle Defects and give region Logout CSDTS(Employee) Login to Application Update Our profile

FC

FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC

Change Password Submit Defects to admin View Defect Status Logout

FC FC FC FC

3.4 Organizing Specific Requirements DTS are often required to integrate with other information systems, such as customer databases, contact information, requirements management packages, or project planning systems, especially when the software engineering organization is part of a larger project. DTS are usually required to implement security measures, such as only allowing access to information for certain groups, and only allowing modification by those authorized to make take the next step in the process.

3.5 Additional Comments Engineering organizations are often under contractual conditions which require them to keep information about defects and enhancements secret between clients. And with the system being critical to the management of the engineering organization, managers must be certain that the information in the system cannot be tampered with or sabotaged. DTS are also seen as sources of knowledge about the product being developed. Management seeks to extract knowledge from the system for the use of their support organization, which is sometimes outsourced. They also want to measure overall trends or gather information about the product, such as which subsystems are the most defective or costly to maintain.

(4) SCOPE FOR FUTURE This project will be made in such a way that it can be easily modified in a more advanced form if there will be such need. The database of this software maintains the records of the details employee, customer, and projects of the defects tracking system. Thus, this record will have a lot of use in future related to any defects. The defects are also revealed in this project Hence, this project covers all-important details regarding the Customer support defect tracking system therefore in future it will help to gather such information about the management of the projects. The main scopes are as follows-

Any field can be added & deleted to & from the database. Storing large amount of data for future point of view. Reducing manual efforts for maintaining the system. Reducing the lead-time. It gives correct information about the defect tracking system which has to be further interpreted. Thus, over all, this entire project has wide application in the future. .

.