The easy answer is “It depends!”

Just like any other diagram, the Class Diagram is just a tool at the disposal of the analyst. In the absence of a set process, it is at the analyst’s discretion to determine when to use a class diagram. Therefore, in which analysis artifact/document a class diagram should be included depends on its use.

But first, let’s determine what a Class Diagram can do for you by looking at some of its characteristics:

• A Class Diagram models “classes” also known as types. It shows what types of things can exist in the domain being analyzed. Remember: things = nouns!
• A Class Diagram can show the “attributes” of the classes, that is it shows what type of data can be used to describe a given thing.
• A Class Diagram illustrates how “classes” are related to each other. It depicts the relationships which can exist among the various things which exist in a given domain.
• A Class Diagram shows “multiplicity” also known as “cardinality”. This concept is used to further clarify the relationships between things by specifying how many things of one type can related to how many things of another type.

Therefore, if the analyst uses the Class Diagram to depict the key nouns found in the lingo of the business users (aka the business domain) and the relationships among those things, then this class diagram would represent a domain model and would probably belong in one of the earlier artifacts of the project such as the Business Requirements Document (BRD).

On the other hand, if the Class Diagram is used to explain what C# classes will be used to realize the functional requirements and the types of data attributes which describe those classes, then this diagram would be considered a design artifact and would probably belong in the System Specification/Technical Specification document.