Development Case: Artifact Classification
Topics
Background 
The artifact classification scheme defines the values used to qualify the use of the artifacts, and reports, in the process configuration. The classifiers appear in the "How to use" columns of the individual discipline artifact and report tables (see Development Case: Discipline Configuration for details of the tables used).
[The classification scheme can be extended/customized to reflect the individual culture of your organization. This example uses a set of intuitive classifications, derived from the widely used MoSCoW rules, to qualify the usage of the artifacts.]
These values are complemented with a separate classifier to define the review procedures for the artifact (see Development Case: Review Procedures for details).
The classification scheme used here is the one recommended by the Rational Unified Process. See the RUP Guidelines: Classifying Artifacts for further details and examples.
[Note: although the standard artifact classification scheme is used here it is worth including a full definition of the scheme as part of the development case itself (rather than just referencing the RUP Guidelines) as the guidelines may change in later versions of the process.]
For details of the artifacts defined by the Rational Unified Process see RUP Overview: Artifacts and for details of the reports defined by the Rational Unified Process see RUP Overview: Reports.
Artifact Classification
|
Classification |
Source |
Explanation |
| RUP | Must use this artifact. It is a key artifact and may cause problems later in development if it is not produced. | |
| RUP | Should have this artifact if at all possible, but it is negotiable. If this artifact is not produced then the justification for this decision must be documented in the Software Development Plan. | |
| RUP | Could have means that it doesn't have to be produced. It should only be produced if it adds value, and there is enough time. | |
| RUP | Won't use this artifact. This may occur where you have a RUP artifact which has been replaced by a local artifact |
[All artifacts that are classified as 'Must Have' or 'Should Have' must have their review procedures, tools, templates and configuration management practices defined. The specification of these procedures is optional for artifacts classified as 'Could Have' - these decisions could be left to the developers / projects that decide to produce these artifacts..
All artifacts that are classified as 'Won't Have' must have their omission justified.
The major benefit of adopting this classification scheme is that it allows
the development case to clearly denote how the process has been specialized
and where there are options for negotiation and local decision making.]
The Origin of the MoSCoW Rules
The MoSCoW rules are a method for prioritizing requirements used quite widely in the United Kingdom especially by followers of the Dynamic System Development Method (DSDM).
In The Dynamic System Development Method [STA97] Jennifer Stapleton introduces the MoSCoW rules thus:
"You will not find the MoSCoW rules in the DSDM Manual, but they have been adopted by many organizations using DSDM as an excellent way of managing the relative priorities of requirements in a RAD project. They are the brainchild of Dai Clegg of Oracle UK, who was one of the early participants in the DSDM Consortium."
When prioritizing requirements the mnemonic has the following meaning:
M - Must have
S - Should have
C - Could have
W - Want to have but will not have this time round
Most practitioners actually take the W to stand for "Won't have".
