Browse Prior Art Database

System for prioritizing defect and feature requests based on integrated view of dynamic business priorities

IP.com Disclosure Number: IPCOM000195567D
Publication Date: 2010-May-05
Document File: 3 page(s) / 29K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a system for prioritizing defect and feature requests based on an integrated view of dynamic business priorities

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 3

System for prioritizing defect and feature requests based on integrated view of dynamic business priorities

Some prior art for defect/feature tracking allows a user to input multiple static attributes for a defect, such as "Does this issue affect usability of the product" or "Did the server crash as a result of this issue?" However, those systems do not consider continuously changing business

priorities when determining which defect/features are most important. Those business priorities

must be considered in order to prioritize defects/features in a way that has optimal business impact.

When a customer submits a defect or feature, how does the support team prioritize the defect/feature? Customer may provide a priority or severity of the defect (1 being high, 4 being low, for instance), but this may not accurately reflect the priority of the defect. This scenario exists in both support teams that have external customers as well as development teams that receive defects/feature requests from internal test teams. How does the support or development team determine which defects/features are highest priority? Currently, defects would be

prioritized based on the severity assigned by the customer, or possibly the severity of the

defect/feature after it has been reviewed by a support team:

The following description provides a method that addresses the issue of

feature requests.

A series of data sources are provided to an algorithm that calculates defect/feature priority. These data sources may include:

A set of questions that rate various static attributes of the defect, such as:

Did this defect result in an outage of the server? (Yes/

No)

Does this issue make you doubt the integrity of the data provided by the product (

Somewhat=2, Yes=3)

Does this issue result in integration conflicts with other products? (

Does this issue cause slow performance in the user interface? (

A database of the current customers that have critical situations (crit sit's) open. This data is continuously changing. The data can include the length of time of the customers' crit sits, and the

products involved. Conversely, if a customer has no remaining vested interests,

customer-unique defects become less important. Priorities change over time, as customer relationships change. The prioritization algorithm can run continuously providing continuously updated prioritized list of defects and features.

A database of dynamic sales information. This could include information such as what customers currently have sales pending.

Data showing the priorities of the development organization responsible for servicing the defects/features. For instance, an organization may dec...