The following attributes are carried with each issue:
|
Class |
should be custom configured, e.g. {System, Software, Hardware, User Documentation, Electrical Installation, Roof, etc.}. The available classes are project dependent. |
|
State |
as described in the previous chapter |
|
Priority |
can be any of {immediate, occasionally, soon} and describes how fast a solution is needed |
|
Severity |
can be any of {non-critical, serious, critical} and describes how seriously the user of a system is effected as long as the issue isn't being completed |
|
List |
describes the type of list, for example Problem Report, Action Item, Feature Request, Risk, Work Package etc.. |
|
Originator |
the $ORIGINATOR of the issue or his representative as described previously in the role definitions |
|
Manager |
the $MANAGER of the issue; can be the $PM, or the person responsible for the subsystem, or the person responsible for the issue |
|
Responsible |
the person currently responsible for the issue ($RESPONSIBLE), as described previously in the role definitions |
|
Create Date |
when the issue arrived |
|
Last Modified |
when the issue was last modified. State change modifications dates are recorded separately, however. The modification itself is not being traced, only its date, what attributes were effected and who carried it out. |
|
Created by |
who created the issue |
|
Project |
The project to whom this issue belongs. A single issue has to belong to exactly one project. |
|
Subsystem |
The subsystem within a project to whom this issue belongs. A single issue has to belong to exactly one subsystem. |
|
Release |
The release of a project to whom this issue belongs. A single issue has to belong to exactly one release. If for instance a problem report covers more than one release it has to be copied to the several releases. This facilitates release independent bug fixing (e.g. a bug is fixed in a later release but remains in a previous release) |
|
Build |
Some string with up to 25 characters representing a build number. |