Artifacts > Environment Artifact Set > Development Case > Guidelines > Classifying Artifacts
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 havethese 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.
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 dynamicallyallowing 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.
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.
Rational Unified Process