PRODUCT DESCRIPTION
PROCESS DESCRIPTION
INTERACTIONS WITH OTHER ACTIVITIES

DE.2. Domain Analysis

Getting Started

Domain Analysis is an activity of Domain Engineering for studying and formalizing a business area as a domain. The purpose of formalizing a domain is to standardize and leverage knowledge of how recurring and varying customer requirements affect the form and content of a product. The scope of a domain is a business decision based on evaluations of available expertise and potential business opportunities. Domain Analysis specifies a standardized Application Engineering process and product family and verifies that a corresponding Domain Implementation meets that specification.

Objectives

The objectives of Domain Analysis are to:

• Determine scope and to evaluate the economic viability of a domain
• Establish, manage, and evolve a repository of domain knowledge
• Specify an Application Engineering process and product family appropriate to the domain

Required Information

Domain Analysis requires the following information:

• Business area knowledge
• Domain Plan: Domain Objectives
• Domain Implementation

Required Knowledge and Experience

Domain Analysis requires domain and software knowledge and experience in:

• The needs that motivate systems in the domain
• The environments in which these systems operate
• How these systems are built

PRODUCT DESCRIPTION

Domain Analysis creates two work products: Domain Definition and Domain Specification.

Domain Definition

Purpose:

A Domain Definition (see Section DE.2.1) is an informal description of the systems in a business area that form a domain. A Domain Definition characterizes how existing systems, systems being developed in ongoing projects in the domain, and potential future systems are similar and how they differ.

Verification Criteria:

The Domain Definition captures sufficient information to allow domain engineers to describe accurately any existing or potential system.

Domain Specification

Purpose:

A Domain Specification (see Section DE.2.2) precisely characterizes a product family for the domain and an Application Engineering process for constructing members of that family.

Verification Criteria:

The Domain Specification precisely expresses the domain as captured in the Domain Definition.

PROCESS DESCRIPTION

The Domain Analysis Activity consists of the three steps shown in Figure DE.2-1 Domain Analysis Process.

Procedure

Follow these steps for the Domain Analysis Activity.

Activity: Domain Definition

Action:

Characterize the domain to satisfy domain objectives (see Section DE.2.1).

Input:

Domain Plan

Result:

Domain Definition

Heuristics:

• Characterize the domain by defining its scope (i.e., classes of systems, characteristics, or functions included and excluded from the domain) and how included systems are distinguished from one another. These definitions are a basis for judging the qualitative and economic characteristics of the domain to determine whether the domain as defined will be economically viable.
• Consider how a product for a system is similar and distinguishable from a product for existing systems.
• Use this definition as a basis for judging the qualitative and economic characteristics of the domain to determine whether the domain, as defined, will be economically viable. If analysis of the Domain Definition fails a test of economic viability, reevaluate the scope of the domain in terms of domain objectives.

Activity: Domain Specification

Action:

Specify Application Engineering Process Support (see Section DE.2.2).

Input:

Domain Definition

Result:

Domain Specification

Heuristics:

• Create a standard Application Engineering process for the domain. Ensure that all needs of projects are flexibly supported.
• Design an Application Modeling Notation for communication of system requirements and constraints among customers and application engineers. Identify the decisions that an application engineer must make to describe fully the variations in a system. This notation must accommodate aspects appropriate for the work product family (such as functional [e.g., behavioral] and nonfunctional aspects [e.g., size, timing, fault tolerance, hardware architecture, hardware/software configuration]) so that the application engineer can adequately express customer requirements. This notation should be based on existing (formal or informal) notations used by domain experts.
• Ensure that the Application Modeling Notation is precise enough to be used as a source for mapping into exact system solutions. Create standardized requirements for the domain. This description must establish both the common and variable aspects of the behavior and constraints of product family members. An unambiguous specification of requirements is needed so that domain implementors can determine what impact a decision has on a system. This also provides a basis for explaining the notation to application engineers.
• Create a standardized design for the product family. The design must satisfy both the common and variable aspects of the product family. A standardized design includes both design structures that define various views of the product structure and components from which a product is constructed to satisfy customer requirements.

Activity: Domain Verification

Action:

Verify the correctness, consistency, and completeness of domain engineering work products (see Section DE.2.3 for motivation).

Input:

• Domain Definition
• Domain Specification
• Domain Implementation

Result:

None

Heuristics:

• Verify the consistency and completeness of the Domain Definition.
• Verify that the representation of the Application Engineering process in the Domain Specification is consistent and complete with respect to its representation in the Domain Definition.
• Verify that the representation of the application engineering product in the Domain Specification is consistent and complete with respect to its representation in the Domain Definition.
• Verify that the Product Implementation is consistent and complete with respect to the Domain Specification.
• Verify that the representation of the Application Engineering process in the Process Support is consistent and complete with respect to its representation in the Domain Specification.

Risk Management

Risk:

The cost of an increment of Domain Analysis is projected to exceed the budget.

Implication:

Insufficient resources exist to complete a planned iteration of Domain Engineering.

Mitigation:

• Reduce the current scope.
• Seek a change in domain objectives or an increase in the budget for the increment from Domain Management.

INTERACTIONS WITH OTHER ACTIVITIES

Feedback to Information Sources

Contingency:

The Domain Plan cannot be satisfied with available technical capabilities.

Source:

Domain Management Activity

Response:

Propose (alternative) revisions to the Domain Plan that better match available capabilities. Complete a Domain Definition and a Domain Specification that satisfy the Domain Plan as closely as possible.

Contingency:

The Domain Implementation does not satisfy the Domain Specification.

Source:

Domain Implementation Activity

Response:

Clarify the intent of the Domain Specification.

Contingency:

The practices and procedures specified in the Domain Plan are either ineffective or inefficient.

Source:

Domain Management Activity

Response:

Describe the ways in which the practices and procedures are either ineffective or inefficient. Propose revisions to the practices and procedures to make them more effective.

Feedback From Product Consumers

Contingency:

Suggestions are made for Domain Specification changes to exploit unforeseen opportunities. For example, a situation where substantial software is made available for use in the Domain Implementation that was not available when the Domain Specification was completed.

Source:

Domain Implementation Activity

Response:

• Revise the Domain Specification.
• Refer to Domain Management for future planning.
• Reject the changes due to conflicts with the Domain Definition.

Contingency:

The Domain Definition and/or Domain Specification fails to provide the capabilities required by the Domain Plan.

Source:

Domain Management Activity

Response:

Evolve the Domain Definition and the Domain Specification to be consistent with the Domain Plan.

Contingency:

The Domain Specification is incomplete, ambiguous, or inconsistent.

Source:

Domain Implementation Activity

Response:

Revise the Domain Specification to correct the inadequacies.

Contingency:

The standardized Application Engineering process is inefficient or leads to less-than-ideal results for a particular project.

Source:

Project Support Activity

Response:

• Determine that the benefits of process standardization outweigh the interests of the particular project.
• Evolve the definition of the Application Engineering process to reflect the project's experience or to be adapted to the particular conditions of concern.