DE.2.1. Domain Definition

A Domain Definition establishes the scope of a domain and a justification of its economic viability. It provides a basis for determining, informally, whether a system is properly within that scope.

The Domain Definition does not answer detailed questions of scope, but clearly includes and excludes broad classes of systems. Assumptions of commonality and exclusion identify the common features of systems in the domain, thereby establishing a family. Assumptions of variability identify how systems in the family are distinguished from one another. Justification provides a basis for judging technical and economic feasibility and market potential of the domain to evaluate whether there is sufficient confidence in the viability of developing the business area as a domain.

A Domain Definition consists of the following components:

Domain Synopsis. An informal statement of the scope of the domain.
Domain Glossary. Definitions of significant terminology used by experts in discussing needs and solutions in the domain.
Domain Assumptions. A description of what is common, variable, and excluded among systems in the domain.
Domain Status. An assessment of the current maturity and viability of the domain relative to its planned evolution.
Legacy Products. A representative collection of work products from existing systems in the product line which may be a suitable source of information and raw material for developing the domain.

Every Domain Assumption must be endorsed for every customer type in the customer base identified in a Domain Status.
The needs of all customer types in the customer base must be fully met by the Domain Synopsis and Domain Assumptions.

Domain Synopsis

The Domain Synopsis is an informal statement of the scope of the domain. It characterizes systems included in the domain.

A Domain Synopsis includes an informal characterization of the systems that make up the domain.

A Domain Synopsis is a simple narrative using terms defined in the Domain Glossary. Example DE.2.1-1. Fragment of TLC Domain Synopsis illustrates a fragment of a Domain Synopsis for the TLC domain. This fragment depicts typical information contained in a Domain Synopsis and the use of terms from the Domain Glossary.

The Domain Synopsis must give an intuitive feel for the definitive characteristics of systems in the domain. It should, in itself, adequately describe any existing or potential system.
A term that could have different meanings to different readers may be used in the Domain Synopsis only if it is defined in the Domain Glossary.

Domain Glossary

The Domain Glossary is a compendium of precise definitions for all significant terminology used by experts for discussing problems (customer needs) and solutions (systems) in a domain. This domain terminology is organized into a taxonomy of terms.

A Domain Glossary has two parts:

A set of standard terms and their definitions
A list of references to external sources which define and elaborate on relevant topics and terminology

A reference to an external source is written using an accepted documentation style for a reference (e.g., author-date). Standard terms are defined in alphabetical order using the following forms:

Term 1:: definition (source)
Term 2:: (1) first definition (source); (2) second definition (source)

The source of the term's definition (source) is listed after the definition. Example DE.2.1-2. Fragment of TLC Domain Glossary illustrates a fragment of a Domain Glossary for the TLC domain. This fragment depicts typical terminology needed to discuss systems, problems, and solutions in the TLC domain.

The Domain Glossary must contain precise definitions of all significant terminology used by domain experts for discussing the requirements or engineering of systems in the domain.
Any term used in a definition that could have different meanings to different readers must also be defined.
All independently-used terms that are generalizations, specializations, or components of defined terms must also be explicitly defined.
Terms defined in the Domain Glossary must be sufficient for a domain expert to give an accurate description of any existing or potential system.

Domain Assumptions

Domain Assumptions describe what is common to all systems in the domain and in what significant ways those systems vary and can be distinguished. These assumptions determine, informally, whether a system is within the scope of the domain.

There are three types of assumptions:

Commonality Assumptions. A set of assumptions about the characteristics that are common to all systems in the domain (commonalities).
Variability Assumptions. A set of assumptions about the characteristics that distinguish systems in the domain (variabilities).
Exclusionary Assumptions. A set of assumptions about the characteristics of systems that are outside the scope of the domain (exclusions).

Every assumption is composed of a description and justification.

Assumptions may also be elaborated with associated, subordinate assumptions. For example, a commonality assumption may have specific variabilities associated with it. Similarly, a particular resolution of a variability assumption can be thought of as characterizing a subfamily of the product family. The subfamily then may have additional, more specific commonalities and variabilities that further distinguish the members of the subfamily.

An assumption description and justification are informal text. Assumptions which elaborate another assumption should be presented in adjacent, indented text. Examples DE.2.1-3. Fragment of TLC Commonality Assumptions and DE.2.1-4. Fragment of TLC Variability Assumptions illustrate fragments of some commonality and variability assumptions for the TLC domain. The justification provides rationale on why the domain engineers believe the assumption to be valid.

Commonality and variability assumptions must capture all important aspects that are common to all systems in the domain and the significant ways in which these systems can vary. Exclusionary assumptions must not exclude needed capabilities.
Systems must only vary as implied by the variability assumptions.
Every commonality assumption must apply equally well, without qualification, to any system in the domain. Systems must not violate a stated commonality, either by excluding an included feature in the commonality assumptions or by including an excluded feature in the exclusionary assumptions.
All reviewers must agree that domain experts will consider Domain Assumptions to be consistent and unambiguous, relative to the definitions in the Domain Glossary. A term that could have different meanings to different readers may be used in a Domain Assumption only if it is defined in the Domain Glossary.

Domain Status

Purpose:

Domain Status describes the current technical maturity of the domain that the organization has achieved relative to planned evolution, and assesses the viability of evolution. Of particular concern are unsupported variability assumptions (i.e., default commonalities).

The Domain Status describes evaluations that establish whether the domain, as defined, will be economically and technologically viable. Qualitative and quantitative criteria assess whether current development and future evolution of the domain will support the organization's business objectives.

Content:

The Domain Status is an informal characterization of the degree to which Domain Objectives are satisfied by past development. It includes the effects of further planned development.

At a minimum, the Domain Status must include:

An endorsement that the Domain Synopsis and Domain Assumptions define an economically viable domain.
A concise statement that characterizes the confidence (or risk) associated with this endorsement. If possible, this should include a justification of the endorsement and a list of major unresolved issues or risks that may jeopardize the domain's viability.

Depending on the size of the potential business area and the attendant commitment to the domain, however, you may need a more detailed Domain Status consisting of some or all of the following:

The target customer base. This is a profile of each type of customer and/or contract that comprises this area of business. Each profile on the list consists of:
- The name of the customer (or contract) type.
- A short description.
- A list of attributes that characterize this type of customer. These attributes fall into two categories: technical expectations and administrative expectations. Technical expectations are features of the delivered products or the process for developing, testing, maintaining, or delivering and installing the products. Administrative expectations are gross cost, profit, and schedule aspects of a contract.
- A list of specific (potential or current) contracts and/or customers that fall under this type.
A grouping of the different alternatives of variability assumptions into priority subsets. Minimally, there are two subsets: "must have" and "nice to have." A system of numerical weighting may be desirable.
A statement of the potential value of the domain. You may need to analyze alternative scopes of the domain separately. The following factors express the potential value of a particular scope:
- The size of the potential market (consisting of the target customer base)
- The planned share of that market
- The projected income from that share
- The expected cost of supporting that market
- An expected profit margin to justify the risk of entering the market
- A pricing structure for systems to be produced that supports the cost/profit expectations

Form and Structure:

The maturity of a domain can be expressed as limitations in satisfying variability assumptions. Characterize the technical expectations of the target customer base as the subset of possible alternatives of variability assumptions that are supported. Risks can be mitigated by imposing limits on variability assumptions.

Verification Criteria:

Every alternative of every domain variability assumption must have an explicit (or overall group) economic justification from the potential value analysis and/or an endorsement from the customer base.

The price/capability of systems offered (as supported by the domain value analysis for a particular domain alternative) must compare sufficiently well against the perceived capabilities of the competition in this business area to justify the anticipated profit and market share.

Legacy Products

Legacy Products provide access to work products from existing systems that may be useful sources of information and raw material for developing the domain.

Legacy Products consists of a representative collection of work products (or portions thereof) from existing systems in the product line to be supported by the domain.

Work products may be physically stored, on paper or in electronic media, or may only be identified by reference when sufficiently accessible in this way (e.g., in an organization's local library or in an accessible repository set up for another, existing domain).
Work products are kept in Legacy Products in the form in which they were produced. Other, consuming activities of Domain Engineering will copy and excerpt or adapt these work products, as needed, in order to create reusable assets.
The work products comprising the Legacy Products are organized in a suitable manner to provide access by other Domain Engineering activities to a particular system's work products or to individual work products of a particular type.

Step: Define Domain Informally

Each work product in Legacy Products must come from an existing system that was determined to be in the domain.

PROCESS DESCRIPTION

The Domain Definition Activity consists of the five steps shown in Figure DE.2.1-1. Domain Definition Process.

Procedure

Follow these steps for the Domain Definition Activity.

Create a description of the domain, characterizing key technical objectives of included systems.

Domain Plan: Domain Objectives

Domain Definition: Domain Synopsis

Step: Establish Standard Terminology

Start with a one-sentence description of the family of systems that constitutes the domain.
Refine the Domain Synopsis to two pages, at most, of intuitive and not overly-restrictive text. Impart, concisely, an informal but complete sense of the domain in the first paragraph. Try to focus on the essential nature, scope, and variety of systems in the domain.
Characterize the type of problem that systems in the domain solve, and the external environment (i.e., devices, systems, and users) with which systems interact. Describe the observable behavior that systems exhibit in solving the problem. You might also establish significant constraints concerning how the systems operate in terms of performance, reliability, or distribution concerns.
Cover the primary functions performed by every system in the domain and any important functions performed by only some systems. Maintain a black-box perspective when describing functional aspects of the system.
Use terms defined in the Domain Glossary to keep the Domain Synopsis short.
If the domain (e.g., process control systems) is based on formal theories that provide experts with a common language of communication about problems, refer to those theories in the Domain Synopsis.

Action:: Create definitions of all significant terms used by domain experts in discussing the requirements or engineering of systems in the domain.
Input:: Domain Definition: Domain Synopsis
Result:: Domain Definition: Domain Glossary
Heuristics:: Maintain term definitions in alphabetical order for ease of reference. Provide cross-references to related terms.
Use definitions from standard glossaries where possible. Make note of such sources in each definition for future traceability.
Make definitions as precise as possible.
Make sure that all terminology used in the Domain Synopsis is defined in the Glossary.
Create a structure that shows term specializations and relationships among similar concepts. This action will reveal missing terms that represent generalizations or specializations of known terms.
Create a structure that shows the composition of terms and the interrelationship of independent concepts in the formation of logical structures. This will reveal missing terms that are necessary to complete the definition of other terms or terms that tie other terms together into more complex concepts.

Step: Establish Domain Assumptions

Create lists of the assumptions that allow you to think of the envisioned set of systems as a family and the assumptions that allow you then to distinguish among them.

Domain Definition: Domain Synopsis
Domain Definition: Domain Glossary

Domain Definition: Domain Assumptions

Step: Assess Domain Status

State only those assumptions that affect the system software and associated delivered products (e.g., documentation, test support).
To create a preliminary set of assumptions:
- Create a commonality assumption for each characteristic specified in the Domain Synopsis that is shared by all systems in the domain.
- Create a variability assumption for each characteristic specified in the Domain Synopsis that is not shared by all systems in the domain.
- For each term in the Domain Glossary, determine whether the term indicates a commonality or a variability among systems in the domain. Create an assumption accordingly.
Make variability assumptions precise by indicating the type of decision the application engineer must make to resolve the variability. It is not sufficient to note only that some characteristic varies. You must establish how much flexibility the application engineer needs to characterize different systems adequately.
Elaborate commonality assumptions to uncover specific variabilities assumptions associated with them. This will more precisely characterize a subset of the product family.
Elaborate variability assumptions to find more specific commonality and subsequent variability assumptions that further distinguish members of the subfamily.
Compare the characteristics of existing systems to facilitate the identification of common features and variations.
Consider characteristics anticipated for future systems to identify additional variability assumptions.
Look at the maintenance history of existing systems for an indication of how systems in the domain change over their life cycles. The histories of these systems indicate likely variabilities that characterize the evolution of individual systems.
Use information on technological advancements that could impact the development of future systems in the domain to identify potential variations.
Distinguish between system-generation-time and run-time variations when developing assumptions about variable aspects of the domain. Treat a run-time variation that is characteristic of all systems in the domain as a commonality.
Use exclusionary assumptions to clarify a domain's boundary. Do not enumerate every type of system or function that is outside the domain. Rather, exclude explicitly those functions or characteristics that a domain expert might incorrectly assume to be part of a system when reading the Domain Synopsis. Thus, you can answer the question of whether a particular system belongs within the domain more directly by checking the exclusions. Exclusions often result from a viability analysis of the domain.
Uncertainties that arise from analysis of customer requirements are often a good source of needed variability. These uncertainties are questions that customers, in the end, must resolve, but must be asked or be given additional information to be able to do so.

Evaluate the technical maturity of the domain in terms of Domain Objectives and plans for domain development and evolution.

Domain Plan
Domain Definition: Domain Assumptions

Domain Definition: Domain Status

Determine Marketability

Domain Status must result in an endorsement of and commitment to a specific domain scope (set of assumptions). This endorsement may come directly from the intuitions of experienced personnel, or it may derive from a more extensive, quantitative analysis. Even in the latter case, however, all estimates and interpretations will rely on the best judgment of senior people. Many of the following heuristics are couched in qualitative terms to capture the essence of the decision being made, but you can always augment that decision by the suggested, optional quantitative analyses.

Are systems of this sort marketable? Look at the Domain Synopsis. The Domain Synopsis imparts an intuitive feel that it encompasses systems that the profiled customers will buy. If not, identify what is missing and add the missing elements to the Domain Synopsis.

Do the commonality assumptions correspond to the essential needs of the target customers? Are they really interested in systems that do everything implied by these assumptions, or may the scope be reduced? Conversely, are features they always require (possibly in variant forms) missing? Change the assumptions accordingly.

Do the variability assumptions represent the real issues that determine whether a system addresses the individual needs of the target customers? Are there inconsequential variations (to the target customers) that you can constrain without losing business? Are there important differences in the needs of target customers that are not captured in the variabilities? Change the assumptions accordingly.

Do expectations of target customers include not only those of the system end-user, but also the expectations of analysts and decision makers who influence awarding of contracts? In particular, the administrative expectations should include items such as allowable contract costs.

Determine Implementability and Risk

A straightforward way to reduce the number of variations supported is first to decide what customers (or customer types) must be retained for viability of the business. Then determine must-have and nice-to-have variability alternatives for each of these customers. The aggregation of the must-have alternatives determines the minimal scope of your domain. Now you can consider all other proposed variability alternatives with regard to their incremental value added.
Determine whether your organization has a good understanding of the problems such systems are intended to solve, compared with your competition, and whether your organization has authoritative expertise that will be committed to developing this domain.
Determine whether your organization can build such systems. Consider whether it has built such systems in the past. Consider the success of such prior experience with particular regard to demonstrated mastery of the relevant software technology.
If particularly difficult technical issues arise, determine which Domain Assumptions are affected. If you can reduce a high technical risk at the cost of removing or constraining an assumption, consider how much domain value is lost by this reduction in scope and risk.
Calculate a range for estimated system cost, potential market, anticipated income, and the like, representing your best- and worse-case expectations, since good estimates are typically hard to come by and are speculative in nature.

Step: Identify Legacy Products

Identify existing systems in the product line that are considered representative of the domain and whose work products may prove useful as sources of information and raw materials in developing the domain.

Domain Synopsis
Domain Assumptions

Domain Definition: Legacy Products

Use the Domain Synopsis as a guide to select existing systems that are within the domain (or subsystems that would be parts of such systems).
Based on Domain Assumptions, identify work products (or fragments, if appropriate) from these systems that reasonably satisfy some or all of the Domain Assumptions.
Create a brief description of the selected systems and work products as a guide to their use as a source of information and raw materials by other Domain Engineering activities.

Risk Management

There is a lack of critical expertise.

The Domain Definition cannot be completed or there is unacceptably low confidence in the results.

Commit time and resources to acquiring the expertise.
Restrict Domain Assumptions sufficiently to reduce the need for expertise.

The scope of the domain may be too narrow, precluding useful variations.

Opportunities for additional projects are lost.
Application engineering projects miss opportunities for reuse.

Review the Domain Definition with management, experienced engineers, and potential customers to identify additional variations.

The scope of the domain may be too broad.

Resources are misapplied to solve an unnecessarily general problem.

Review the Domain Definition with management and experienced engineers to identify under-constrained Commonalities.

Domain Assumptions are too precise or too vague.

Flexibility is reduced unnecessarily, or key decisions are left to the discretion of domain engineers.