Guidelines: Classifying Artifacts
Topics
Introduction
These classifications are used when you describe how to use each artifact (and reports) in the Development Case. You can extend or customize the classification scheme to reflect your organization’s individual culture. These values are complemented with a separate classifier to define the review procedures for the artifact. See Guidelines: Review Levels for details.
| Classification | Explanation |
|---|---|
| Must have | You must use this artifact. It is a key artifact and may cause problems later in development if it’s not produced. |
| Should have | You should have this artifact, if at all possible, but it is negotiable. If you do not produce this artifact, you should be able to justify why not. |
| Could have | Could have means that this artifact doesn’t have to be produced. It’s only produced if it adds value and if there’s enough time. |
| Won’t have | This means you won’t use this artifact. This may occur where a Rational Unified Process artifact is replaced by a local artifact. |
Impact of Classification
All artifacts 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 or projects that decide to produce these artifacts.
All artifacts 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.
Examplesof Usage
One way to think about the artifact classification scheme is that it enables the development case to set constraints on how the elements of the process are used.
For example, if you decide that the project could have an Analysis Model, then the process engineer would fine tune these values by deciding that the project:
- Must have an Analysis Model, or
- Won’t have an Analysis Model, or even
- Will leave things as they are; that is, could have an Analysis Model.
The classification scheme can even be used dynamically-allowing the status of the artifact to change depending upon which phase the project is in.
The following table shows different ways of treating the Analysis Model. The How to use column defines how the artifact is used in each of the phases.
| Artifact | How to use | Comment | |||
|---|---|---|---|---|---|
| Incep | Elab | Const | Trans | ||
| Analysis Model | Won’t | Won’t | Won’t | Won’t | No Analysis Model is developed |
| Analysis Model | Could | Could | Could | Could | Normal |
| Analysis Model | Could | Should | Won’t | Won’t | An evolutionary approach where the Analysis Model is replaced by the Design Model |
| Analysis Model | Must | Won’t | Won’t | Won’t | An evolutionary approach where the Analysis Model is mandatory during the Inception phase to help scope the project but is replaced by the Design Model during Elaboration |
| Analysis Model | Should | Must | Must | Must | A formal process where the Analysis Model is a mandatory, preserved artifact that is optional in the inception phase |
Another good example is to consider ways that the Business Use-Case Model is used within the Business Modeling discipline. It describes different possible artifact sets required to support different problem frames. The Concepts: Scope of Business Modeling discusses domain modeling versus business modeling versus business process re-engineering, each of which requires the production of a different set of artifacts.