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 problems from previous projects affect the form and content of application engineering work products for the targeted project. The scope of a domain is a decision based on existing systems and ongoing projects within the organization. Domain Analysis specifies a standardized Application Engineering process and work product families to support Application Engineering and verifies that a corresponding Domain Implementation meets that specification.

Objectives

The objectives of Domain Analysis are to:

• Determine scope and viability of a domain based on existing systems, planned domain development and evolution, and needs of the targeted project
• Establish, manage, and evolve a set of work product families representing domain knowledge perceived relevant to the targeted project
• Describe an Application Engineering process and work product families appropriate to the domain and relevant to the targeted project

Required Information

Domain Analysis requires the following information:

• Domain Plan: Domain Objectives
• Domain Implementation

Required Knowledge and Experience

Domain Analysis requires domain and software knowledge and experience in:

• Past and ongoing projects in the organization
• 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 and related application engineering work products in a business area that form a domain. A Domain Definition characterizes how existing systems and systems being developed in ongoing projects 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 (in particular, the system being built by the targeted project).

Domain Specification

Purpose:

A Domain Specification (see Section DE.2.2) precisely characterizes work product families of the domain that are relevant to the targeted project and an Application Engineering process for constructing members of the respective work product families.

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 relative to the targeted project's needs (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 the work products for the system needed by the targeted project are similar and distinguishable from work products of 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 for the targeted project. If analysis of the Domain Definition fails a test of economic viability for the targeted project, reevaluate the scope of the domain in terms of domain objectives relative to the targeted project's needs.

Activity: Domain Specification

Action:

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

Input:

Domain Definition

Result:

Domain Specification

Heuristics:

• Identify and specify work product families appropriate for the domain and susceptible to reuse. You need to ensure that these families are useful when application engineers develop application engineering work products for the targeted project.
• Create a specification of standard support for Application Engineering in the domain. This support describes the process followed to identify work products that provide the focus of reuse efforts.
• Identify, for each work product family, the decisions that an application engineer must make to describe fully the variations in the different work product families. These decisions should 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 his needs.
• Create standardized designs for the work product families. The designs must satisfy both the common and variable aspects of the work product family as perceived relevant to the targeted project. A standardized design includes both design structures that define various views of the work product structure and components from which a work product is constructed that might satisfy the application engineer's needs for the targeted project.

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 supporting work products are inefficient or lead to less-than-ideal results for the targeted project.

Source:

Project Support Activity

Response:

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