Software Product Lines
Framework Home
Product Line Essential Activities
Product Line Practice Areas
Software Engineering
Practice Areas
Architecture Definition
Architecture Evaluation
Component Development
Mining Existing Assets
Requirements Engineering
Software System Integration
Understanding Relevant Domains
Using Externally Available Software
Technical Management
Practice Areas
Organizational Management
Practice Areas
Frequently Asked Questions

A Framework for Software Product Line Practice, Version 5.0

Next Section Table of Contents Previous Section

Understanding Relevant Domains

One of the constants we've observed in successful software product line organizations is that they have at their disposal extensive experience in the domains that are relevant to their software endeavors. This practice area is about achieving that understanding. Domains are areas of expertise that can be applied to the creation of a system or set of systems. Domain knowledge is characterized by a set of concepts and terminology understood by practitioners in that area of expertise. It also includes an understanding of recurring problems and known solutions within the domain. Knowledge from several domains is usually required to build a single product. For example, to build a distributed banking application, you would need knowledge of banking practices, commercial bank information systems, workflow management, database management systems, networking, and user interfaces, just to name a few. You would never attempt to build a distributed banking application (or any other nontrivial system) without first making sure you knew enough about the relevant business and technical areas to impart the expectation for success. "Knowing enough" to make good product decisions comes from understanding the relevant domains.

The practice of understanding the relevant domains involves

How does an organization achieve this understanding? Typically, it builds up its store of expertise with its prior experiences in delivering products. An organization can also hire outside experts who provide or augment the organic level of understanding. In addition, it can employ domain analysis methods to gather, organize, and communicate domain information in a form known as a domain model.

Understanding relevant domains is initiated by eliciting domain information from various sources. This elicitation includes the investigation of current products and interviews with domain experts and product marketers, developers, and users to identify the current and potential future capabilities for the product(s) being considered. The elicitation also captures the needs and expectations of the various stakeholders and helps in the assessment of the technical maturity and stability of the relevant domains. The extent of the elicitation activity depends on the availability of sources and the amount of domain knowledge already known in-house.

Domain understanding should include whatever key domain information can be used as the vehicle for analysis and reasoning. Domain information should capture different views of the product(s) from the perspectives of relevant stakeholders. In the absence of this information, your organization is vulnerable if experts leave. Further, documentation will refine and sharpen the understanding of the experts themselves; writing a thing down requires a deeper understanding of it than carrying it around in your head. And finally, recorded domain information can be reviewed and improved by stakeholders who can speak to their future needs.

The extent to which a formal domain analysis is performed to achieve domain understanding depends on these two factors:

  1. the depth of the organization's domain experience: Organizations that have deep domain expertise frequently opt not to invest in a full-blown "formal" domain analysis to model their understanding of the relevant domains. (For example, they may use a hybrid approach that combines requirements gathering with use case modeling and commonality and variability analysis.) Foregoing formal domain analysis allows them to move into design more quickly or to perform some initial design activities (e.g., the investigation of architectural patterns) in parallel with the analysis.

  2. the amount of resources that can be devoted to analysis: The time, money, and people allocated to the analysis will determine the duration and scope of the analysis activities. However that's not to suggest that more analysis is always better. In fact, "analysis paralysis" is a risk associated with this practice area.

Regardless of its formality or comprehensiveness, domain information should be documented to capture the expertise needed to serve as authoritative criteria for making product and design decisions. You need to have enough information to make sound business decisions without necessarily undertaking an extensive analysis of all the applicable domain knowledge. An organization has achieved a sufficient understanding of the domains relevant to a product or products when it can successfully apply that understanding towards

  1. reasoning about the technical and business implications of a proposed design
  2. making informed decisions about which features, capabilities, and technologies to offer in proposed products
  3. creating a set of artifacts that exploits the understanding of the relevant domains

Aspects Peculiar to Product Lines

Understanding the relevant domains is the first step to defining the commonality and variability that can be expected to occur among the products identified in the product line's scope. Domain understanding for a product line emphasizes the commonality and variations present among the products, whereas domain analysis for a single system focuses instead on the technical concepts inherent in a single system or how that system might evolve once fielded.

Domain information for a product line will help you determine

The last item is particularly important; the ability to reason about a product line can help management gain confidence in the soundness of the decision to adopt a product line approach. Put another way, domain understanding informs both the product line's scope and its associated business case. Domain understanding also grounds the design decisions in experience (even if the experience is not the organization's own), which reduces technical risk and also has a soothing effect on nervous managers. Even a rudimentary and informal domain analysis can help refine both the scope of the product line and the initial estimates for resource allocation. And it can show the organization and its management that they are not exploring uncharted territory.

The level of detail and degree of formality of the documented domain information for a product line depend both on the depth and distribution of an organization's domain knowledge and on the kind of reasoning about the product line that the organization wishes to support by modeling. Some organizations have such a thorough understanding of their domains and their reuse potential that they can move very quickly from identifying a business opportunity to creating core assets. Organizations less experienced in exploiting reuse need to approach the problem more deliberately, analyzing commonality and variability to understand the technical implications for assets and products and the business implications for the product line as a whole. Additionally, they may have to hire domain experts if the requisite domain expertise is missing or immature. Whatever the degree of understanding, each organization has some model of the product line that evolves as the development effort progresses. It may be an informal shared understanding of the product line with minimal documentation, or it may be a more formal domain model–that is, an abstract characterization of the product line, complete with its own representation schemes and automated support. If the purpose of the analysis is to obtain insights into the technical feasibility and potential scope of the product line quickly, the analysis does not need to model the commonality and variability exhaustively.

In summary, understanding relevant domains is about systematically capturing and using knowledge about systems similar to the ones that you are about to build. This knowledge provides you with an informed world view from which you can then make specific decisions about your product line, especially regarding its scope, shared and unique requirements, and architecture.

Application to Core Asset Development

An understanding of the relevant domains is applied to core asset development in order to identify and model the opportunities for large-grained reuse across a product line early in its life cycle. This knowledge informs the articulation of common product constraints, as described in Core Asset Development. It has a profound influence on the architecture for the product line, which is the definitive design statement about the commonalities and variabilities that will be supported across the product line. It also supports the business case for the product line and feeds the "Scoping" and "Requirements Engineering" practice areas.

Application to Product Development

An understanding of the relevant domains supports the assessment of customer-specific requests for new product line capabilities. This assessment, in turn, may broaden your understanding of the relevant domain knowledge. In fact, such decision-making opportunities represent one form of feedback between core asset consumers and core asset producers, and they have the potential to expand the scope of the product line by challenging previously held assumptions about commonality and variability. Any such feedback from products to core assets should be documented so that it can be evaluated and, if necessary, incorporated into any models of the relevant domains.

Similarly, an understanding of the relevant domains can also be used as the basis for analyzing the effects of a proposed change in the product line's requirements and for recommending a course of action. For example, a business decision to switch to a different operating system can be checked against the operating system capabilities assumed for the product line. At a minimum, there could be a checklist of features whose presence or absence in the new operating system will either shorten or lengthen the product development schedule. A more detailed model of assumed operating system capabilities would provide a greater ability to quantify the effects of the proposed change on the product development process.

Example Practices

Have domain experts available: The best way to achieve domain understanding is by having the right people in the product line organization–those with extensive experience in the relevant domains. (This was a recurring theme at the one of the SEI product line practice workshops [Bass 1998a].)

Scope, commonality, and variability (SCV) analysis: The SCV approach, from Lucent Technologies, gives software engineers a systematic way of thinking about the product family they are creating. It identifies, formalizes, and documents commonalities and variabilities. SCV is the commonality analysis portion of the Family-Oriented Abstraction, Specification, and Translation (FAST) approach, also from Lucent Technologies. The FAST method includes the dual life cycles of domain engineering and application engineering. It uses the results of a commonality analysis to create a language for both specifying domain members and generating them from the specification [Coplien 1998a, Weiss 1999a].

Domain analysis and design process (DADP): DADP is a process model for domain analysis and design created by the Defense Information Systems Agency (DISA). It is based on an object-oriented approach to analysis and design. The domain analysis process focuses on identifying commonalities and determining common object adaptation requirements (the differences among domain common objects are not described in terms of variability, but rather in terms of tailoring the information to particular needs) [DISA 1993a].

Feature-oriented domain analysis (FODA): The FODA method defines the process and products of a domain analysis, with an emphasis on the commonality and variability of the features that users commonly expect in domain applications. The analysis process creates models of the domain that describe its relationship to other domains, its common and variant features, and the behavior of the applications in it [Kang 1990a, Cohen 1991a]. The feature-oriented reuse method (FORM) is an extension to FODA that addresses the design and implementation phases [Kang 1998a].

Synthesis process of the reuse-driven software processes (RSP) approach: Synthesis is a methodology for creating software systems as instances of a family of similar systems. It was developed by the Software Productivity Consortium in recognition of a need to produce improvements in software productivity, product quality, manageability, and customer responsiveness. A Synthesis process consists of two subprocesses: domain engineering and application engineering. The domain engineering process includes an explicit domain analysis process that captures commonality and variability for a product family [SPC 1993b].

Domain analysis process of organizational domain modeling (ODM): ODM is a highly tailorable and configurable domain engineering process model. It's organized hierarchically as a tree of processes, and while it doesn't use the term domain analysis, all the elements of a domain analysis process are present at various levels within its process tree. In particular, the model contains subtrees of processes for domain identification and scoping, domain modeling, and model refinement [STARS 1996a].

There are documented cases of organizations that have employed and adapted these methods successfully. Several books contain chapters that summarize and compare the characteristics of these and other domain analysis methods [Arango 1994a, Wartik 1992a]. There are also cases where organizations have employed domain analysis practices successfully in the creation of product lines, even though they did not use a documented domain analysis method [Bass 1998a].

The elicitation, representation, and validation of relevant domain information and the techniques employed (e.g., object-oriented technology, use case modeling, state-transition diagrams) vary across the different domain analysis methods and are not described using the same vocabulary. In a product line context, organizations perform these practices to varying degrees of completeness and rigor. In particular, organizations with deep domain knowledge and considerable expertise in applying it to developing products often opt for an abbreviated form of analysis that proceeds very quickly to design.

Product Line Software Engineering Customizable Domain Analysis (PuLSE-CDA): This method is one of the elements of the PuLSE product line engineering framework. PuLSE-CDA creates a domain model that can be customized to specific projects based on variation points called customization decisions. It also creates a decision model (based on that of Synthesis [SPC 1993b]) that provides instantiation support for specifying the products in a product line. There is a tool called Domain and Variant Engineering Supporting Technology/CDA (DIVERSITY/CDA) to support the method. PuLSE was developed by the Fraunhofer Institute for Experimental Software Engineering (IESE) [Bayer 2000a].

Domain-Specific Modeling (DSM): DSM creates a language based on high-level domain concepts and supports the automatic generation of programs specified in that language. Tolvanen identifies over 20 industrial cases in which this approach has been successfully applied to target languages such as C, C++, Java 2 Platform, Enterprise Edition (J2EE), and Extensible Markup Language (XML) [Tolvanen 2005a]. The domains of these industries include telecom services, insurance, medical device configuration, handheld devices, machine control, and business processes.

Practice Risks

Inadequate domain understanding in the organization will jeopardize the product line effort. Without a detailed (not just basic) understanding of the precise commonalities and variabilities that need to be accounted for, the architect's hands are tied, the business case will be weak, and the scope definition will be unrealistic. The result will be a set of products that do not adequately address the needs and market demands they were intended to meet. Inadequate domain understanding can result from

Further Reading

[Arango 1994a, Ch. 2]
Arango provides a comparative survey of published domain analysis methods that also maps each method onto a common domain analysis process.

[Ardis 2000a]
Ardis and colleagues describe an effort in understanding relevant domains at Lucent Technologies in 1994.

[Bayer 2000a]
Bayer and colleagues describe CDA, a domain analysis method that is part of the PuLSE product line engineering framework created by the Fraunhofer Institute for Experimental Software Engineering.

[Geppert 2003a]
Geppert and Weiss describe Avaya Labs' method for the quantitative assessment of potential product line domains and, using an example application of this method, define measures for a candidate domain's potential corporate impact and likelihood of success when implemented as a product line.

[Kang 1990a]
Kang and colleagues provide a comprehensive description of FODA.

[Kang 1998a]
This paper presents FORM, an extension of FODA used to develop domain architectures and components for reuse.

[Lee 2000a]
Lee and colleagues describe their experience with domain analysis for their software product line.

[SPC 1993b]
This guidebook describes the Software Productivity Consortium's Synthesis methodology, which incorporates domain analysis into the construction of families of systems having similar descriptions.

[STARS 1996a]
This STARS report describes ODM.

[Tolvanen 2005a]
Tolvanen and Kelly describe industrial cases where domain-specific modeling has been used successfully.

[Weiss 1999a]
Weiss and Lai describe the commonality and variability analysis, which is an important part of Weiss and Lai's FAST process for product lines.

Next Section Table of Contents Previous Section