Domain Model Document

Definition

The domain model document (DMD) is the requirements work product that formally documents the essential concepts of the application domain in terms of an object model.

Objectives

The typical objectives of a domain model document are to:

• Formally document the object model of the essential concepts of the application domain.
• Provide a more formal definition of the application terms used in the system requirements specification and the external API specification.

Benefits

The typical benefits of a domain model document are:

• Increase understanding of the essential domain terminology beyond that provided by the definitions in the glossary.
• Clarify the meaning of the essential terms used in the system requirements specification and the external API specification.

Contents

The typical contents of a domain model document are:

• Domain Object Model:
  • Essential Packages:
    • Essential Types
    • Essential Relationships
• Conclusion
• Appendices:
  • Major Issues
  • TBDs
  • Assumptions

Stakeholders

The typical stakeholders of a domain model document are:

• Producer: Requirements Team
• Evaluator: Requirements Inspection Team
• Approvers:
  • Technical Leader
  • Project Manager
  • Customer Representative
• Maintainer: Requirements Team
• Users:
  • Architecture Team, which uses the DMD as input to the information architecture and software architecture.
  • Software Development Team, which uses the DMD to identify classes of objects to design and code.

Phases

A domain model document is typically produced during the following phases:

• Business Strategy: Not Applicable
• Business Optimization: Not Applicable
• Initiation: Started
• Construction: Completed
• Delivery: Maintained
• Usage: Maintained
• Retirement: Destroyed or Archived

Preconditions

A domain model document typically can be started if the following preconditions hold:

• The requirements team is staffed and adequately trained in object modeling.
• Domain experts who know the application domain are available.
• The system requirements specification is started.
• The glossary is started.

Inputs

The typical inputs to a domain model document include:

• Work Products:
  • System Requirements Specification
  • Glossary
• Stakeholders:
  • Customer organization domain experts
  • Development organization domain experts

Guidelines

• This is a living document that is developed incrementally and iteratively in parallel with other work products.
• This document is more valuable, the more of the software that must be developed from scratch.

Conventions

A domain model document is constrained by the following conventions:

• Content and Format Standard
• MS Word Template
• XML DTD
• Inspection Checklist

Examples

• EAS Domain Model Document