Guidelines: Classifying Artifacts

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.

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.

Examples of 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:

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
Artifact	Incep	Elab	Const	Trans	Comment
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.