®

Feature-based Systems and Software

Product Line Engineering: A Primer

Feature-based Product Line

Engineering lets you build
your product line portfolio as
a single production system
rather than a multitude of
individual products.
 Why Product Line Engineering?

INCOSE’s Product Line Engineering International Working Group is

spearheading the upcoming ISO standard 26580 on Feature-based Product
Line Engineering. This primer is intended to serve as an introductory
companion to that standard.
Product Line Engineering (PLE) has long been known for delivering significant
improvements in time to market, quality, and cost of systems.* Feature-based
Product Line Engineering is a proven, well-defined, repeatable, automation-
centric approach to PLE that is now delivering even greater improvements
throughout some of the most challenging engineering industries.

Virtually all systems and software engineering is performed in the

context of a product line. Hardly anyone builds just one edition, just
one flavor, of anything. Product lines are found in every industry,
including aerospace, defense, automotive, medical, consumer
electronics, computer systems, energy, telecommunications,
semiconductor fabrication, software applications, e-commerce, and
industrial automation. Product lines occur under every business model,
including retail, government contracting, OEM, business-to-business,
value-added reselling, and custom development.

As businesses everywhere strive to achieve competitive advantage

and greater profitability, the need for an efficient means to produce
systems and software product lines is universal.

There are constant pressures

to decrease cost and time to
market. The exponentially growing This primer provides a
complexity of product line portfolios starting point to learn
and how they are created and about this powerful
produced are pushing organizations approach. It offers a
to the edge of their capability. As brief introduction to PLE,
the mundane tasks of managing this
explains how it works,
complexity increasingly consume
engineering teams, they lose the and provides sources of
opportunity to create and fully information to learn more.
leverage new product innovations.

Even in the world of Aerospace and Defense, gone are the days when
government customers are satisfied with the traditional “clone and
own” reuse approaches where each product variant is custom fit to
a customer’s needs. This traditional reuse method does not give rise
to agile and faster deliveries. Customers are demanding frequent and
modular upgrades, lower development costs, and faster deliveries to
keep pace with their competition and changing operational contexts.
* Linden et al. Software Product Lines in Action: The Best Industrial Practice in Product Line
Engineering. 2010

“The Department [of Defense] is transitioning to a culture of performance

and affordability that operates at the speed of relevance… We will prioritize
speed of delivery, continuous adaptation, and frequent modular upgrades.”
— James Mattis, U.S. Secretary of Defense, April 2018
https://www.defense.gov/News/Article/Article/1503359/mattis-asks-house-committee-to-build-on-recent-dod-successes/
 The solution:
The Feature-based PLE Factory

FEATURE CATALOGUE BILL-OF-FEATURES PORTFOLIO

EntryControl
EntryControl

Indicator Lockout AutoLock

EntryControl
Indicator Lockout AutoLock
Physical LED Screen CenterConsole Speed Gear
Indicator Lockout AutoLock
EntryControl

Park Neutral Drive

Physical LED Screen CenterConsole Speed Gear Physical LED Screen CenterConsole Speed Gear
Indicator Lockout AutoLock

Park Neutral Drive

Physical LED Screen CenterConsole Speed Gear
Park Neutral Drive

Park Neutral Drive

PLE
FACTORY
CONFIGURATOR

SHARED ASSET SUPERSETS

PRODUCT ASSET INSTANCES

Organizations utilizing Feature-based PLE adopt • The PLE Factory Configurator is an automated
a factory approach to building their products. The software tool that applies a Bill-of-Features
figure above illustrates the important concepts to all of the shared assets. It evaluates each
of a Feature-based PLE Factory in operation, as variation point to determine if that variation
defined in the upcoming ISO standard. point’s content should be included or not.
• Shared assets are artifacts that support the • The PLE Factory produces as output Product
creation, design, implementation, deployment, Asset Instances, each one containing only
and operation of products. They can be the shared asset content suited for one of
represented digitally and configured, and are the products in the product line. Together,
shared across the product line. they constitute the artifact set for one of the
Each shared asset is a superset that contains products in the product line.
variation points, which are pieces of content that Engineers now work on the shared asset
should be included in or omitted from a product supersets, and the Feature Catalogue, and the
based on the features selected for that product. Bills-of-Features. Change and evolution are
• The Feature Catalogue captures the features handled systematically through well-defined
that are available for each product to select. A governance procedures.
feature is a distinguishing characteristic that
Once the PLE Factory is established, engineering
describes how the members of the product line
assets for products are instantiated rather than
differ from each other. This provides a common
manually created.
language and definition of the product line’s
scope of variation for everyone throughout the Feature-based PLE transforms the task of
organization. engineering a plethora of products into the much
• The features selected for each product in the more efficient task of producing a single system:
product line are specified in the Bill-of-Features The PLE Factory itself.
for that product.
 Shared assets:
A key concept of Feature-based PLE

Shared assets are the “soft” artifacts associated with the engineering life
cycle of the products. A shared asset can be any artifact representable
digitally: requirements, design models, source code, test cases, BoMs, wiring
diagrams, documents, and more. They either compose a product or support
the engineering process to create a product.

A shared asset used in the product line takes the Models

form of a superset, meaning any asset content
used in any product is included. There is no When models are used in product development,
duplication or replication of asset content at all. they can be developed as supersets and
This elimination of duplication is where Feature- instrumented with variation points for the product
based PLE derives its savings by eliminating work line. For example, system design or architecture
across duplicated assets. models using SysML or UML can be instrumented
through variation points, which apply to structural
The shared asset supersets contain variation elements such as processes, objects, classes,
points, which are places in the asset that denote states, use-cases, packages, and others.
content that is configured according to the feature
choices of the product being built. A statement of Electrical and Mechanical Designs
the product’s distinguishing characteristics — its
Shared assets for Electronic Design Automation
features — is applied to “exercise” these variation
(EDA), and Mechanical Design Automation
points (that is, cause the content associated with
(MDA), and Computer-aided Design (CAD) for
each variation point to be configured to meet the
electronic, mechanical, mechatronic, and cyber-
needs of the product).
physical systems take the form of supersets of
Configuration options typically include selection parts, properties, and relationships in Bills of
or omission of the content; selection from among Materials (BoM), assemblies, subsystems, circuit
mutually exclusive content alternatives; generation boards, wiring harnesses and more in EDA, MDA,
of content from feature specifications; and and CAD models. Variation points instrument
feature-based transformation of content from one optional, mutually exclusive, and varying content
form into another. in the models.

Requirements Source Code

Perhaps one of the easiest shared assets to In software systems, shared assets can include
understand is requirements. A superset of the source code, the models used to generate the
requirements combines individual product source code, build files, and automated unit tests.
requirements to establish the product line Source code can be configured in several ways
requirements. Variation points achieve inclusion including individual blocks of code, files, or build
and omission, define mutual exclusion, and files. A modular software architecture may assist
transform requirement wording in the product greatly with the feature instrumentation but is
specification – all based on feature selections. not necessarily required. Features might align
Requirement transformation can replace closely with the system’s software, electrical,
constants, units, or other text with values that are and/or mechanical modularity, or they might
derived from the feature model. Requirements be cross-cutting where a feature affects several
that have no variation are part of every product. different modules.
Test Plans and Test Cases A Consistent Approach to Variation
For all types of systems there should be validation Imagine that a requirements engineering team
and verification artifacts that include test plans has embraced a variation management technique
and test cases. These may use automated or based on tagging requirements in a requirements
manual techniques, but in either case should be database with attributes that differentiate
supersets instrumented with variation points feature variations in requirements. Further, the
along with the other shared assets in the product design team has adopted a SysML tool and
line. Eliminating sources has embraced inheritance as the mechanism
of unnecessary testing for managing design
is often one of the variations.
first visible benefits of The software development
PLE. Furthermore, it is team is using an informal
possible to streamline or feature model drawn in
even eliminate redundant a graphical editor, plus
testing of common macro directives, build
capability across the flags, and configuration
product line. management branches to
manage implementation
Others variations. Finally, the
test team has adopted
There are many other clone-and-own of test
types of shared assets plan sections, stored in
that might serve in a appropriately named file
product line, such as system directories to
product budgets or cost manage their PLE test plan
models, schedules and variations.
work plans, user manuals
Now imagine what would
and installation guides,
be needed to create a
process documentation,
complete PLE life cycle
marketing brochures,
solution that integrates
wiring diagrams,
into a larger business
simulation models,
process model. How do
engineering drawings,
the requirements database
product descriptions, attributes and tagged
and contract proposals. requirements relate and
These assets in their trace to the subtypes and supertypes in the
simplest form may be documents, spreadsheets, design models? How do these attributes and
or presentations, but more complex or supertypes relate and trace to the macro flags, CM
customized systems may be used to formalize branches, and test case clone directories? Trying
them. In any case, these assets can be integrated to translate and synchronize among the different
into the PLE factory. representations and characterizations of features
and variations creates dissonance and chaos at
the boundaries between stages in the life cycle.

To resolve the quagmire brought about by different disciplines each using its
own approach to variation, a key aspect of Feature-based PLE is consistent
and traceable treatment of variation across all shared asset types. Feature
choices are the basis of a common language of variation across all disciplines
and at all levels of the organization.
 The economics of Feature-based PLE
Organizations that adopt PLE as a key business strategy consistently garner
significant competitive advantage in the form of more wins, more innovative and
higher quality systems and products, faster engineering and business velocity, and
higher revenue and profits.

Feature-based
Product Line
Engineering
eliminates
duplication in
artifacts and
replication of
work, resulting in
the leanest, most
efficient engineering
effort possible.

As an organization
carries out its daily
engineering work,
that work can be
characterized by
how many products
in the organization’s
portfolio each piece
of work affects.

Capturing a new requirement, repairing a defect In the figure above, each bar represents work that
in a piece of software source code, writing a more applies to a certain number of products. The blue
comprehensive test case, adding a new piece segment of each bar measures the engineering
of hardware to the Bill of Materials, altering a effort of a task. No matter how many products
design model: Each of these tasks, and more, can benefit from the task, the task is only done
be characterized by how many products in the once, consuming one “unit” of effort. The gold
portfolio it affects. segment of each bar measures the engineering
effort avoided through the automation of the
Suppose a task affects four products. In a
configurator. The small green segments represent
product-centric environment, each product’s team
the cost of applying Feature-based PLE: building
will apply that task. Under Feature-Based PLE, if
the Feature Catalogue, the shared assets with
the organization undertakes a task again affecting,
variation points, etc.
say, four products, that task is carried out once,
inside the factory. The task will involve changing The engineers carrying out the task in our example
or adding to the shared asset supersets, or the have done the work of a team four times their
Feature Catalogue, or the Bills-of-Features for the size under the old approach. They can claim with
products. Then, the configurator is used to apply
absolute justification that they are four times as
the work to each product that needs it.
productive as their pre-PLE-factory counterparts.
 Feature-based PLE for the enterprise:
PLE from the break room to the boardroom

PLE earned its wings, and its ongoing reputation To avoid these problems, alignment and
for substantial savings, in engineering. However, collaboration among many functions in the
Feature-based PLE should not be sequestered organization is crucial: from strategy functions to
in just the engineering sphere. Organizations customer-facing functions, program management
expend enormous amounts of time and effort functions, technical functions and industrial
dealing with product feature diversity to manage functions. In other words, all roles — marketing,
manufacturing and supply chains, certification and sales, bid teams, project management, systems
compliance documentation, product marketing engineering, product policy, domain and
and product portfolio planning, e-commerce web specialty engineering, as well as procurement,
system deployments, sales automation, training, manufacturing and installations — must agree
support, service, maintenance, disposal, and more. upon, share, promote, and comply to the same
Feature-based PLE, with its central paradigm of
vision of the product line scope. In all of these
feature selections driving variation realization,
areas, features can formalize the product line’s
works not only in organizations’ engineering arms,
domain of variability.
but in their operations arms as well.
To the extent it is adopted throughout an
In many companies, the marketing, capture
organization, Feature-based PLE provides
of opportunities, design, development, and
the opportunity to create that alignment and
delivery of products is the output of different
teams who work in silos and follow different collaboration. Its central concept of feature
processes. This often leads to a misalignment powers diversity management at all levels, from
between the benefits that are actually obtained the most minute and mundane to the most
and the business strategy of the company (which strategic and company-defining. Decision-makers
translates into lower profits), and between the can use features to make strategic decisions about
delivered product and the services the product is portfolio management, entering new markets,
supposed to provide (which usually translates into pricing, and more, and those feature decisions can
customer dissatisfaction). flow seamlessly down through product realization.

FEATURE CATALOGUE BILL-OF-FEATURES PORTFOLIO

EntryControl
EntryControl

Indicator Lockout AutoLock

EntryControl
Indicator Lockout AutoLock
Physical LED Screen CenterConsole Speed Gear
Indicator Lockout AutoLock
EntryControl

Park Neutral Drive

Physical LED Screen CenterConsole Speed Gear Physical LED Screen CenterConsole Speed Gear
Indicator Lockout AutoLock

Park Neutral Drive

Physical LED Screen CenterConsole Speed Gear
Park Neutral Drive

Park Neutral Drive

PLE
FACTORY
CONFIGURATOR

SHARED ASSET SUPERSETS

PRODUCT ASSET INSTANCES
 Organizational PLE adoption
Effectively adopting Feature-based PLE involves much more than just installing
a tool to manage the Feature Catalogue and configure products. Leadership
commitment — not just tacit approval — is a critical ingredient for success.
Feature-based PLE involves a change in mindset, natural tendency to continue working as before
from product-centric thinking to product line must be overcome.
thinking, as well as an organizational change: to
As a result, tenets from the organizational change
create, staff, and operate the PLE Factory. While it
community* are appropriate and helpful in a PLE
in no way fundamentally changes the engineering
adoption. Among other things, that community
processes in an organization, it does extend them
teaches us that:
in specific ways.
• Strong, effective, and repeated communication
For example, requirements engineers will continue
throughout the organization of the importance
to work on requirements, as always — except now
and (especially) the urgency behind the
they will work with a superset and create variation
adoption of PLE is essential.
points. The same applies for software engineers,
test engineers, technical writers, analysts, • An incremental, purposeful, goal-oriented,
architects who build design models, and so on. step-by-step adoption plan is necessary, to
ensure that the organization’s transition to PLE
Governance is key. Change control boards happens in a gradual, manageable fashion.
continue to function as before, but changes now Each increment should include a short-term
involve shared asset supersets and the feature win, an improvement brought about by
catalogue — and they are reviewed and vetted PLE, that can be advertised and celebrated,
from the perspective of the entire product line. increasing the momentum of the adoption.
These and other changes must be introduced into * For example, see Kotter, J. P. Leading Change.
Boston: Harvard Business School Press, 1996.
the organization’s culture, and the organization’s

Tools are easy. People are hard. The hardest obstacle to overcome when
adopting Feature-based PLE is not technological, but cultural. Fortunately,
the high ROI on PLE makes the organizational change pill easier to swallow.
 Feature-based PLE in practice

Feature-based PLE is currently in use in Published case studies include:

organizations of all sizes and across a wide range 1. Wozniak, L., Paul Clements. “How Automotive
of industry sectors. Examples include: Engineering Is Taking Product Line Engineering to
the Extreme.” In Proceedings of the 19th International
• A global aerospace and security firm providing Conference on Software Product Lines, Nashville, 2015.
the US Navy with a critical strategic defense 327-336. New York: ACM.
system is saving tens of millions of dollars 2. Chalé Góngora, H.G. and Greugny, F. 2017. ”Where the
every year, equal to the cost of their entire Big Bucks (will) Come from — Implementing Product
engineering staff. Line Engineering for Railway Rolling Stock.” INCOSE
INSIGHT Practitioners Magazine 22, no. 2 (2019), 15-24.
• A leading aviation supplier is producing
3. Clements, P., Susan Gregg, Charles Krueger, Jeremy
certification packages for their safety-critical Lanman, Jorge Rivera, Rick Scharadin James Shepherd,
flight products eight times faster than before. Andrew Winkler. 2014. “Second Generation Product Line
Engineering Takes Hold in the DoD,” Crosstalk, The
• A major network storage company is enjoying Journal of Defense Software Engineering, Jan/Feb
300% to 500% improvements in scalability, time (2014). 12-18.
to market, and product quality.
4. Gregg, Susan P., Rick Scharadin, and Paul Clements.
• A global aerospace and defense company has 2015. ”The More You Do, the More You Save.” In
Proceedings of the 19th International Conference on
saved more than $800 million over a twelve-
Software Product Lines, Nashville, 2015. 303-310. New
year period, while increasing the productivity of York: ACM.
their engineers to 280% of previous levels.
5. Lanman, J., Brian Kemper, Jorge Rivera, Charles
• One of the world’s largest automotive Krueger. 2011. “Employing the Second Generation
manufacturers has calculated cost savings of Software Product-line for Live Training Transformation.”
tens to a hundred million dollars per year, from In Proceedings of Interservice/Industry Training,
Simulation, and Education Conference (I/ITSEC) 2011.
configuring just one type of shared asset.
accessed May 2, 2019, http://www.iitsecdocs.com.
Signs you’re not practicing Feature-based PLE

You’re not practicing Feature-based PLE if:

• You don’t have a Feature Catalogue, explicitly • Products in your product line have their own
owned and managed, and under revision development teams. The PLE Factory and
control. Different functions and factions in your product development teams are fighting for
organization have diverging opinions on what funding.
the product line is and is not.
• Your product roadmaps and investment plans
• You aren’t using a feature-based configurator are hampered by technical decisions taken
tool that configures your engineering artifacts. unilaterally by customer project teams.
You’re creating asset instances by hand, or by
building and maintaining ad hoc scripts. • Engineers are applying manual changes to
multiple copies, not supersets.
• You aren’t using a consistent variation
management approach, based on features, • You have no PLE-based governance structures
across your engineering artifacts. in place.

• Products are not defined in terms of features. • Your customers are dictating changes to
products that bypass the PLE change control
• You are permitting, either explicitly or through authority and governance structures.
casual process enforcement, clone-and-own
practices, increasing your technical debt and • Your development teams hesitate to perform
burdening the organization with repetitive modifications because they are tangled up in a
work. branching misery of product versions.
 Additional resources:
1. Beuche, D. 2008. “Modeling and building
software product lines with pure::variants.” In
Proceedings of the 15th International Software
Product Line Conference, Limerick, Ireland,
Sept 08–12, 2008, 358-367. New York: ACM.

2. Gregg, S., et al. 2016. “The Best of Both

Worlds: Agile Development Meets Product
Line Engineering at Lockheed Martin,” INCOSE
International Symposium, 26, no. 1 (2016); 951-965.

3. Gregg, S., et al. 2014. “Lessons from AEGIS:

Organizational and Governance Aspects
of a Major Product Line in a Multi-Program
Environment.” In Proceedings of the 18th
International Software Product Line Conference,
Florence, Italy, 2014, 264-273. New York: ACM.

4. Krueger, C., et al. 2017. “An Enterprise Feature

Ontology for Feature-Based Product Line
Engineering,” INCOSE International Symposium,
27, no. 1 (2017); 951-965.

5. Flores, R., et al. 2017. “Product Line Engineering

Meets Model Based Engineering in the Defense
and Automotive Industries.” In Proceedings of the
21st Software Product Line Conference, Seville,
September 25-29, 2017, 175-179, New York: ACM.

INCOSE-TP-2019-002-03-0404

This International Council on Systems Engineering

(INCOSE) Technical Product was prepared by the PLE
International Working Group and is approved by the
INCOSE Technical Operations Leadership.

Copyright (c) 2019 by INCOSE, subject to the

following restrictions:

Permission to reproduce and use this document or

parts thereof by members of INCOSE and to prepare
derivative works for INCOSE use is granted, provided
this copyright notice is included. This document may
not be shared or distributed to any non-INCOSE
third party. Any electronic version is to be used for
personal, professional use only and is not to be placed
on a non-INCOSE sponsored server for general use.
Additional use of these materials must have written
approval from INCOSE.

Requests for permission to reproduce this document

in whole or part, or to prepare derivative works,
should be addressed to [email protected] or to
INCOSE, 7670 Opportunity Rd, Suite 220, San Diego,
CA, 92111-2222, USA.