Software Product Lines
Framework Home
Product Line Essential Activities
Product Line Practice Areas
Software Engineering
Practice Areas
Technical Management
Practice Areas
Configuration Management
Make/Buy/Mine/Commission Analysis
Measurement and Tracking
Process Discipline
Technical Planning
Technical Risk Management
Tool Support
Organizational Management
Practice Areas
Frequently Asked Questions

A Framework for Software Product Line Practice, Version 5.0

Next Section Table of Contents Previous Section


Scoping is an activity that bounds a system or set of systems by defining those behaviors or aspects that are "in" and those behaviors or aspects that are "out." All system development involves scoping; there is no system for which everything is "in." The Rational Unified Process (RUP) includes an inception phase to establish "the project's software scope and boundary conditions, including an operational concept, acceptance criteria, and descriptions of what is and is not intended to be in the product" [Kruchten 1998a]. Kruchten defines scoping as "capturing the context and the most important requirements and constraints so that you can derive acceptance criteria for the end product."

In conventional system development, scoping is usually done informally, perhaps as an unofficial prelude to the requirements engineering activity. In systems designed with ease of change in mind, the activity of scoping helps determine the set of modifications the design will accommodate and those it will not.

Aspects Peculiar to Product Lines

In product line development, scoping is a fundamental activity that will determine the long-term viability of the product line. Like scoping in general, product line scoping determines what's "in" and what's "out"–in this case, of the software product line. The result is a scope definition, which is a primary output of the Core Asset Development activity and becomes a product line core asset itself. The scope definition identifies those entities with which products in the product line will interact (that is, the product line context), and it also establishes the commonality and sets limits on the variability of the products in the product line.

The scope definition usually begins as a broad, general document that is refined as more knowledge is brought to the table and more analysis is performed. For example, for a product line of World Wide Web software, we would start by declaring that browsers would definitely be "in." Aircraft flight simulators would definitely be "out," and email handlers would . . . well, we wouldn't be sure until the scope was refined further. Hence, the product line scope may not come into sharp focus all at once and that's fine.

The goal of the scope definition is to draw the boundary between "in" and "out" in such a way that the product line satisfies it business and market goals. If the scope is too large, the core assets will have to accommodate so much variation that they will be too complex to be useful and cost-effective in any product. If the scope is too small, the product line may not have enough customers to recoup the investment in the core assets. And if the scope bounds the wrong products, the product line will not find a market. Getting the scope right is important.

The following things drive the scope definition:

Scoping identifies the commonality that members of the product line share and the ways in which they vary. Identifying commonalities and variabilities is a theme that pervades virtually every product line practice area; it is the essence of the product line concept and the essence of scoping. Because the scope describes the characteristics of a class of systems, and not specific systems, the scope will apply equally well to existing products and products that have not yet been built or defined completely. The descriptions of scope are essential for determining whether a planned system can be built within the product line and from product line core assets. In most cases, scoping activities must continue after the initial scope has been defined because new market opportunities may arise and new opportunities for the strategic reuse and merging of projects may be revealed.

Scoping may occur in a variety of contexts other than a start-from-scratch product line. For example, an organization may be building (or commissioning) several systems that are similar but not taking advantage of that similarity. The organization may wish to merge those efforts to gain economies of scope. In this case, the initial scope is defined by the list of products that are planned currently. In another case, the organization may aim to capture or penetrate a market segment by establishing a flexible, quick-response capability for launching new products in that market area. In this case, the set of systems may be defined on the basis of marketing projections obtained through "Market Analysis" practices.

In short, scoping answers the question "What products should be in my software product line?" This question is asked at the product line launch and as new product opportunities arise for an up-and-running product line. The candidate product may be a new one brought to the table by a customer or your marketers, or it may be an already existing system being maintained separately by your organization. In the latter case, you might be hoping to achieve economies by merging that system with your product line. By matching a candidate product against the scope definition, you can decide whether that product is "in" or "out" of your product line. If it is "out," you can judge by how much. At this point, you can decide (via business case practices) whether to expand the product line's scope to include the new product, develop the new product as a stand-alone system, or turn down the opportunity entirely.

The scope delivers a technical decision that business case factors might override. For example, you may agree to develop a product that is nominally outside the product line's scope if the customer who wants it is a very important one or it represents an entrée into a desirable new business area. Or, you may decline to build a product that is in the scope if the market for it is small or its opportunity cost is high.

Scoping, as described up to this point, is a way to help inform decision making: when a product opportunity arises, it helps an organization decide whether to bring that product into its product line family. Mature product line organizations often use their scopes to create new product opportunities for themselves. A scope defines an organization's product line area of expertise–the set of systems that it can build efficiently. Thus, scoping can let an organization take the initiative, by providing a basis for discovering products that may have an untapped market. These new products might be squarely within the defined scope, or they might be outside but "nearby." Clements and Northrop chronicle three other case studies that contain different flavors of product line companies that intentionally expanded their scope into new market areas, with excellent results [Clements 2002c]. For example, Cummins, Inc. expanded its scope of automotive diesel engine software to include industrial diesel engine software and quickly entered and dominated an underexplored market.

Application to Core Asset Development

The scope definition is a core asset for the product line, one that will be consulted extensively and revised as necessary as the product line grows and evolves. The scope definition informs the requirements engineering process, so the requirements-related core assets must be consistent with the scope. We have already shown that market analysis (another core asset) can influence the scope definition. The scope definition can influence the market analysis by identifying places where a new product variant can be produced very efficiently. The market for such a variant might not justify its construction from scratch; however, the market may be robust enough for a product line member to fill the niche nicely.

Application to Product Development

The scope definition is used during product development to gauge whether a product (that's in your legacy base, in development, or merely being considered) would make a viable member of the product line. That is, the scope lets you decide whether it would be economically advantageous to develop that product using the product line's core assets. Sometimes a product will be clearly in scope, and sometimes it will be clearly out of scope. The interesting situation, of course, is when the product is on the cusp. In that case, a revised market analysis may help to determine whether the organization should produce the product, and then the scope can be adjusted appropriately. If many on-the-cusp products crop up, it may be an indication that the scope should be expanded slightly to include them, assuming that the concomitant expense of fortifying the core assets to accommodate them is deemed (via a business case) to be economically sound.

Specific Practices

Applying the What to Build pattern: Applying the What to Build pattern [Clements 2002c, Section 7.6] is an effective way to establish and understand the scope of a product line. The pattern situates the "Scoping" practice area in the broader context of its interactions with other closely related practice areas: "Understanding Relevant Domains," "Building a Business Case," "Market Analysis," and "Technology Forecasting." Information from these practice areas contributes to the definition and evolution of the product line scope by refining the envisioned product set in light of business, marketing, and feasibility considerations. The pattern is applied by iterating through its practice areas until the desired understanding of the scope is achieved. You can apply the pattern quickly to a candidate list of product lines to select the one(s) with the most promise or apply it more deliberately to a selected candidate to probe the soundness of the choice.

Examining existing products: Conducting a thorough study of existing products helps identify commonality across a potential product line and identifies the types of differences that are likely to occur. A survey of each group that is developing these products will likely identify future plans, market strategies, and context. In many cases, existing products will contain potential product line core assets that can be mined and used in the future. The steps in this process include

  1. Identify existing products similar to those that will be part of the product line.
  2. Gather any available documentation and conduct product demonstrations.
  3. Conduct oral or written surveys of product experts and the current product developers, users, and maintainers.
  4. Identify the products' capabilities, structure, and evolution and any other relevant factors about them.
  5. Determine which elements of these products should be considered part of the product line.

Conducting a workshop to understand product line goals and products: It is important to gather the potential product line stakeholders together in order to set the direction for the product line. The stakeholders include management, marketing, developers, users, testers, tool developers, technology researchers, and domain experts. Like the market analysis and business case, scoping explores the goals of the product line; the difference with the scoping process is that it examines the product line more from the user's perspective than the organization's. The workshop should work to identify the following:

The workshop should also establish a coarse-grained schedule that aligns product line development with marketing or overall business strategies.

Context diagramming: A context diagram places the product line in the context of product users and other systems and depicts the important entities that affect the product line or are affected by the product line (for example, people, the physical environment, and other systems). The diagram is a generalization across the product line; not every system in the product may connect with all systems or types of users shown in the diagram. Similarly, the context diagram may not show all the interactions of all the potential systems. And even if some product line systems have interactions that are unique to one system, they should still be included in the product line. In addition to highlighting the common context, the context diagram and accompanying documentation should describe possible options and variations. A rationale for the selection of options or variants should also be included. The following figure illustrates a context diagram for the software in a personal sound system.

Context Diagram of a Personal Sound System

Context Diagram of a Personal Sound System

Developing an attribute/product matrix: An attribute/product matrix sorts, in order of priority, the important attributes by which products in the product line differ. Typically, the attributes that drive the market are listed vertically down the left side of the matrix, and the different products are listed horizontally across the top of the matrix. For example, in the following table, attributes include Radio Tuner, Displays, and Audio Control; products include Low-Cost Model, Mid-Priced Model, and High-End Model. The value for the attribute of each product (analog, for example) is listed where the attribute column (radio tuner) and product row (low-cost model) intersect.

Attribute/Product Matrix for Personal Sound System

Low-Cost Model

Mid-Priced Model

High-End Model

Radio Tuner


digital presets

digital presets




frequency, graphical equalizer

Audio Control



full-spectrum equalizer

In practice, of course, software attributes are often less tangible. The matrix is used in scoping to define the variability of the product line. By sorting in order of attribute priority, the cluster of the most important attributes that are common across the product can be identified readily.

Developing product line scenarios: Product line scenarios are key to defining a product line's scope. They describe user or system interactions with products in the product line. They identify interactions that are common to all products in the product line, as well as those that are unique to a subset of products in the product line. The purpose is to test the context for the scope of the product line. Do entities exist that affect the systems but are not included in the context diagram? If so, must new domains be identified? Along with creating the scenarios, it is important to conduct scenario walkthroughs. These walkthroughs help us understand the support that will be needed to realize the scenarios in product line products.

PuLSE-Eco: A method specifically for determining the scope of a product line is called PuLSE-Eco [DeBaud 1999a, Schmid 2001a, John 2006a]. First, product candidates are mapped out, based on input about the system domain and stakeholders. Candidates include existing, planned, and potential systems. The result is a list of potential characteristics for products in the product line. Products and characteristics are combined into a product map–a kind of product/attribute matrix as described above. In parallel, evaluation functions are created, using stakeholder and business goals as input. These evaluation functions will enable you to predict the costs and benefits of imbuing a particular product with a particular characteristic (such as a feature). Next, potential products are characterized, using product maps and the evaluation functions. Finally, benefit analysis gathers the characteristic and evaluation information and determines the scope of the product line.

Practice Risks

The major risk associated with product line scoping is that the wrong set of products will be targeted. In particular

Further Reading

[Cohen 1998a]
Cohen and Northrop discuss product line scoping in the context of object technology. The use of object-oriented approaches such as scenarios, use cases, and frameworks can contribute to our understanding of a product line and the development of a scope for that product line. Their paper also offers an example product line scope, context diagram, and use cases.

[DeBaud 1999a]
DeBaud and Schmid describe PuLSE-Eco–perhaps the most comprehensively documented method for scoping a software product line.

[Fritsch 2004a]
Fritsch and Hahn describe Product Line Potential Analysis, a workshop-based technique developed by Robert Bosch GmbH to help organizations quickly decide whether a product line approach should be adopted for a given set of products and their related target market.

[Jandourek 1996a]
Jandourek describes an approach for platform (or product line) development that was used at Hewlett-Packard. The first step in the approach is product portfolio planning to establish a product lineage chart that defines the organization's product needs and scopes the platform in terms of the products it must support.

[Robertson 1998a]
Robertson discusses platform planning as a method of achieving software product lines. The planning process uses concepts that are used in product line scoping: (1) identifying the concepts, variants, and options to be embodied in products, (2) determining elements in the products that are common and unique, and (3) listing attributes that will differentiate products.

[Schmid 2000a]
Schmid provides an introduction to the problem of scoping a software product line and describes the close connection between scoping and domain engineering. He further categorizes the then-existing approaches to scoping and discusses the optimization of scoping as it's applied to product portfolio, domain, and core asset scoping.

[Withey 1996a]
Withey's investment analysis technique assesses the worthiness of investing in software core assets. An initial step is scoping the product line that will use the assets. The author suggests methods for developing and analyzing the financial effectiveness of scoping decisions.

Next Section Table of Contents Previous Section