Setting Up User Codes

Use the Defect Symptoms page (RQ_UD_DEF_SYMPTM) to define defect symptom codes to provide consistent problem symptom descriptions and to facilitate data entry.

Image: Defect Symptoms page

This example illustrates the fields and controls on the Defect Symptoms page.

Defect symptom codes describe common symptoms that your customers might experience. For example, when a faulty motherboard causes a computer to crash, the symptom is the crash.

Use the Defect Causes page (RQ_UD_DEF_SUSPEC) to define defect cause codes to provide consistent potential problem cause descriptions and to facilitate data entry.

Image: Defect Causes page

This example illustrates the fields and controls on the Defect Causes page.

Defect cause codes describe the actual cause of a problem. For example, when a loud squealing noise comes from the bottom of a refrigerator, the actual cause is a bad compressor bearing.

Use the Defect Status page (RQ_UD_ST_STATUS) to define defect status codes.

Image: Defect Status page

This example illustrates the fields and controls on the Defect Status page.

Defect status codes describe the defect's most fundamental status in the problem resolution (fix) cycle. The values OPEN and CLOS (closed) are delivered with the system. Add additional values as required; however, the delivered values should be adequate for most needs.

Use the Defect Status State page (RQ_UD_ST_REASON) to define status states to describe defect status more specifically.

Image: Defect Status State page

This example illustrates the fields and controls on the Defect Status State page.

Status states define the defect's status in the resolution process more specifically than status codes. For example, when you close an enhancement request, you may do so because you have completed the process or because you decided not to enhance the product as requested. Each status state is linked to a valid status and is available on the Defect page when the corresponding status is chosen.

Use the Defect Status State Reason page (RQ_UD_ST_ST_RSN) to define status-state reason codes to explain why a defect is in a particular status state.

Image: Defect Status State Reason page

This example illustrates the fields and controls on the Defect Status State Reason page.

Use the Reason field to describe why a defect resolution has a particular status and state. One status-state combination might have several reasons. For example, a defect may be set with a status state of Closed - Do Not Fix because the product is no longer supported or because you have determined that the defect complaint should really be an enhancement request. Each status-state reason is linked to a status and state combination and is available on the Defect page when a user chooses the corresponding status and state.

Use the Status Combinations page (RQ_UD_STAT_COMBO) to define status-state combinations to control permissible transitions.

Image: Status Combinations page

This example illustrates the fields and controls on the Status Combinations page.

As a defect or enhancement request moves thorough the resolution process, you want to change the status-state combination to reflect its progress. However, certain changes do not make sense. For example, if an enhancement request's status is Open - Deferred, you should not change it to Closed - Fixed without passing through the verify, fix, and test stages.

Use this page to control which transitions are permissible. Define combinations for all possible transitions, including reverse transitions. For example, if a software fix fails in testing, it must be returned to the developer. In this case, you need a valid status combination that allows the change to go from Open - Fixed back to Open - To Test in development.

Use the Defect Relationship Types page (RQ_RELATION_TYPE) to define defect relationship types to describe dependencies and relationships among defects.

Image: Defect Relationship Types page

This example illustrates the fields and controls on the Defect Relationship Types page.

Sometimes, two or more defect cases are related to one another, or the solution to a defect may be dependent on the solution to a previous defect. Defect relationship types describe these dependencies. All defect relationships fall into the general categories of hierarchical or equivalent.

An equivalent relationship is two or more defects having the same cause. One fix resolves multiple cases. A hierarchical relationship is an instance when one case cannot be resolved without first resolving another.