Synthesis Leveraged Domain Engineering
PRODUCT DESCRIPTION
PROCESS DESCRIPTION
INTERACTIONS WITH OTHER ACTIVITIES
The Domain Specification Activity is an activity of Domain Analysis for
creating a Domain Specification. A Domain Specification is a
precise characterization of the product family denoted by a domain and of a
process for constructing members of that family.
The product family is characterized from two perspectives: how problems are
stated and how solutions are structured.
Problems are expressed in the form of a requirements specification.
Solutions are expressed in the form of a standardized design.
Both forms are adaptable to anticipated variations in problems and solutions.
The objectives of the Domain Specification Activity are to:
-
Create a precise specification of the problems and solutions supported by the
domain
-
Define an Application Engineering process that is suited to the needs of
building a product in the domain
The Domain Specification Activity requires the Domain Definition.
The Domain Specification Activity requires domain and software knowledge and
experience in:
-
The process that projects in the organization use to construct an
application engineering work project
-
How systems in the domain are constructed, including the issues that
application engineers must resolve to create a particular system
-
The concepts and structures that are convenient forms by which to communicate
about the distinguishing features of
systems
in the domain
-
The principles and use of appropriate software product development methods
-
- Name:
-
Domain Specification
- Purpose:
-
The Domain Specification is a specification for a product family
and an associated Application Engineering process for producing
members of the family.
- Content:
-
A Domain Specification consists of one of each of the following components:
-
Decision Model.
A Decision Model identifies
the application engineering requirements and engineering decisions that
determine how members of the
product family can vary (see
Section DE.2.2.1).
-
Product Requirements.
Product Requirements determine the behavior and operational characteristics of
problems solved by the product family (see
Section DE.2.2.2).
-
Process Requirements.
Process Requirements determine how Application Engineering is performed and
which work products are produced as a result (see
Section DE.2.2.3).
-
Product Design.
A Product Design determines
the structure and composition of solutions provided by members of the
product family (see
Section DE.2.2.4).
- Verification Criteria:
-
-
All aspects of the Domain Definition are accurately captured in the Domain
Specification.
-
Existing or envisioned systems can be described in terms of the Domain
Specification. No systems exhibit behavior not indicated in the Domain
Specification.
The Domain Specification Activity consists of the four
steps shown in
Figure DE.2.2-1 Domain Specification Process.
Follow these steps for the Domain Specification Activity.
Activity:
Decision Model
-
- Action:
- Define the set of requirements and engineering decisions that an
application engineer must resolve to select an instance from a designated
product family.
- Input:
- Domain Definition
- Result:
- Decision Model
- Heuristics:
-
-
Define the decisions that lead to expected differences among the members of the
family.
-
A Decision Model for a
product family should reflect the decisions that application engineers had to
make when creating such
products in previous projects.
-
The Decision Model for a
product family should reflect the variability assumptions from the Domain
Definition.
-
Ensure that supported decisions are sufficient to distinguish each existing
product from other members of the family.
-
Identify logical relationships among the decisions that characterize a
product family and use them to structure the Decision Model. Such relationships
can reduce the number and complexity of separate decisions that application
engineers have to make.
Activity:
Product Requirements
-
- Action:
-
Specify the behavior and operational characteristics of problems solved by the
product family.
- Input:
-
-
Domain Definition
-
Decision Model
- Result:
- Product Requirements
- Heuristics:
-
-
Create a software requirements specification for the product family.
-
To the degree that application engineering decisions change work product
content, describe how content varies with respect to those decisions. This
description will provide a partial basis for explaining the meaning of
decisions to application engineers.
Activity:
Process Requirements
-
- Action:
- Specify a standardized Application Engineering process.
- Input:
-
-
Domain Definition
-
Decision Model
- Result:
- Process Requirements
- Heuristics:
-
-
Define the work products, activities, and process of Application Engineering.
-
Develop the form and structure of the Decision Model as presented to the
application engineer.
Activity:
Product Design
-
- Action:
- Define the design (i.e., composition and structure) of the members of a
designated
product family.
- Input:
-
-
Decision Model
-
Product Requirements
-
Domain Definition: Legacy Products
- Result:
- Product Design
- Heuristics:
-
-
Create a design for the work product
family, including a design for each required work product.
An annotated outline is one model of a Product Design for a document work
product.
An information hiding structure and process structure from the Ada-based Design
for Real-Time Systems (
ADARTS
) (Software Productivity Consortium 1993) design method are models of a Product
Design for a software work product.
-
A key element of domain knowledge is how existing instances of the designated
product family are designed. When feasible, derive the initial Product Design
for a family by extracting the design essentials of existing instances. Ensure
that the composition and structure of existing instances are appropriately
reflected in the design.
-
To the degree that Application Engineering decisions change work product
composition and structure, describe how composition and structure vary with
respect to those decisions. This description will provide a further, but still
partial, basis for explaining the meaning of decisions to application
engineers.
-
- Risk:
-
The Domain Specification does not accommodate
a product family
that
meets
the needs
for building products in the domain.
- Implication:
- The domain will not provide sufficient opportunities for
building unforseen products.
- Mitigation:
- Compare previously developed
systems
that should be within
a product family
with expected needs of
the domain.
Check that likely differences are accommodated.
-
- Contingency:
- The Domain Definition is incomplete, ambiguous, or inconsistent.
- Source:
- Domain Definition Activity
- Response:
- Describe the inadequacies in the Domain Definition. Proceed with Domain
Specification, and document any assumptions made regarding the inadequate
portions of the Domain Definition.
- 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 Specification that satisfies the
Domain Plan as closely as possible.
- 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.
-
- 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 opportunities to Domain Management for future planning.
-
Reject the changes due to conflicts with the Domain Definition.
- Contingency:
- The Domain Specification fails to provide the capabilities required by the
Domain Plan.
- Source:
- Domain Management Activity
- Response:
- Evolve the Domain Specification to be consistent with the Domain Plan.
- Contingency:
- The Domain Specification
is incomplete, ambiguous, inconsistent, or incorrect.
- Source:
-
-
Domain Implementation Activity
-
Domain Verification Activity
- Response:
- Refine the Domain Specification to correct any 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 Application Engineering process to reflect
this project's experience or to be more flexible under the particular
conditions of concern."
- Contingency:
-
Supported
product
family (as represented by its constituent work product families) is
not useful for
a particular project.
- Source:
- Project Support Activity
- Response:
-
-
Determine that the nature of the problem and the consequent costs of upgrading
the
product
family
outweigh expected benefits to the
particular
project.
-
Evolve the domain engineering work product family to reflect this project's
experience or to be more flexible under the particular conditions of concern.
