21. Managing Variants

Polarion provides the capability to centrally manage specifications and other assets for a product line, generating product-specific variant specifications.

Introduction to Variant Management

Many companies today have highly diverse product lines. They offer different product models or configurations with different features sets, to address ever more granular market segments and differentiate their products from competitors. In any given product line there are commonalities and variations among the products that comprise the product line. A critical need in the development of a varied product line is the ability to effectively manage the commonalities and variations in the various specifications. Ideally, the specifications for requirements, tests, risk assessment, etc. should be maintained in a single master specification document for each artifact type that covers the entire product line. There should be an easy way to reuse different applicable subsets of these master specifications to create specifications fully covering each product in the product line. A dedicated variant management tool is needed for all but the most trivial product lines.

Polarion VARIANTS is an add-on to Polarion ALM application lifecycle management solutions. It leverages the already robust document-centric technology, adding a special dedicated back-end server component by Pure Systems plus project templates that enable an existing Polarion ALM installation to become a true variant management system.


In order to use Polarion VARIANTS features with an existing Polarion installation, the following prerequisites apply:

  • You must run Polarion version 2015 (or later).

  • A valid license for Polarion ALM, and/or Polarion REQUIREMENTS, and/or Polarion QA must be present on the Polarion server.

  • A valid license for the Polarion VARIANTS Add-on must be installed on the Polarion server.

  • The Polarion VARIANTS Add-on must be obtained from the Polarion ALM web site and installed according to the included instructions.

Variant management in Polarion is centered around Polarion LiveDocs ("Documents") and Work Items contained in Documents. It is recommended that you become thoroughly familiar with these features before you begin working with variant management. See the User Guide chapter Working With Documents.


The following terminology is used in the Polarion VARIANTS documentation.

Polarion VARIANTS Glossary


Components of a product, whether they are hardware, software, or other functionality needed. When capitalized in documentation, Work Items of type "Feature".

Feature Model

Describes every possible feature of a product line. It is where a company can model their product line by decomposing all products to see what they have in common and what parts differ. Then they assign functionality to features.

Master Specification

A Polarion Document containing all possible artifacts of one or more types for a Product Line. For example, all Requirements, or all Test Cases. Each artifact is linked to one or more Features in the Feature Model. A Variant Specification contains a subset of the artifacts from a Master Specification.

Master Specifications can be as granular as needed. For example, you can have Master Specifications for Functional, Non-functional, and System Requirements.

Product Line

Also called "product family", it is the collection of all products a company produces. The different products may have some common components that must be in every product, and some components that differ from product to product.


Links between Features that denote additional relationships depending on the "link type". For example:

  • requires: Feature1 requires another Feature to be selected, which is not already made sure of by the parent-child relationship. This is done by linking it (with special link type) to the required Feature.

  • conflicts: Feature1 requires another feature to be not selected.


A property of Work Items in a Master Specification, that sets certain restriction(s) or limits on the item's inclusion in Variants. Specified in pvSCL (the restriction language of the Pure Systems back end). For example: Feature1 AND Not(Feature2).


Checks by the Polarion VARIANTS back end to ensure that variants contain only valid assets and information. There are 2 types of Validation checks:

  • Feature Model validation: checks for errors in the construction of the Feature Model, such as inclusion of contradictory Features, or failure to include a Feature from a group from which at least one selection is required.

  • Restriction validation: checks the correctness of Restrictions set in Work Item properties linking the item to one or more Features.

Variation Type

A property of a Feature that describes the Feature's inclusion in product specifications. A feature can have one of four Variation Types:

  • Mandatory feature: A Feature that must be included in every product of the Product Line, or if a sub-feature, must be included if its parent Feature is included.

  • Optional feature: Independent Feature that can be, but does not have to be included in variants.

  • Alternative feature: Feature is one in a group, of which exactly one (and not more) must be included if the parent is included.

  • Or feature: Feature is one of a group, at least one of which must be included if the parent is included.


When capitalized, a Work Item type in Polarion VARIANTS that collects Features and assets from Master Specifications to fully describe a specific product in the Product Line.

When not capitalized, denotes one specific product in a Product Line, e.g. "Model ABC is a variant of the WeatherStation product line".

Variant Description Model (VDM)

Assets (e.g. Requirements, Test Cases, etc.) that are mapped to Features that collectively make up a Variant

Variant Specification

A specification Document generated from a Variant, and comprised of commonalities and variations from the Feature Model and Master Specification.

Process Overview

There are 4 basic activities in a variant management project with Polarion VARIANTS:

  1. Define the Feature Model.

  2. Define one or more Master Specification Documents.

  3. Define Variant type Work Items.

  4. Generate Variant Specification Documents.

Figure 21.1. Variant Workflow

Variant Workflow

The Feature Model is a Document containing Feature type Work Items structured with parent-child relationships to define features and sub-features. The Feature Model contains all the features of every product in the Product Line, and it must be completed before any Master Specifications can be completed, and before any Variant Specifications can be generated. Only one Feature Model is allowed per project.

A Master Specification is a Document containing one or more Work Item types that define various development artifacts: Requirements, Test Cases, Risks, etc. A typical approach is to have different Master Specification Documents for different artifact types: Requirements, for example. With this approach you can take advantage of Document Types, defining one for each type of artifact, thereby gaining the possibility of defining different workflows for different Document Types, which in turn provides the possibility of setting up different approval processes with different groups of stakeholders signing off. A Master Specification contains all the type-specific artifacts for the entire Product Line... all the requirements, or all the test cases, etc.

A Variant is a special type of Work Item that represents a specific product in the Product Line. It is a collection of Features linked to relevant artifacts in the Master Specification(s). It is subject to validation by the Polarion VARIANTS back end to ensure integrity of the Variant Specification generated from it.

A Variant Specification is the complete specification for one type of artifact (e.g. System Requirements, Acceptance Tests, etc.) for one product in the Product Line. It contains only the requirements, or test cases, or risks, etc. for the features of that specific product.

Variant Projects and Project Templates

Polarion VARIANTS comes with a project template and a demo project that have pre-defined support for variant management. The "Specification Project with Variant Management" template is specifically for creating variant management projects. The "Weather Station" demo project is based on this template and it includes data and examples.

Using the Variant Project Template

Creating a variant management project is no different from creating any other type of project. In the New Project wizard page where you select the project template, simply select one of the templates that supports variant management. The template description will indicate this.

If you need information about creating projects, see the User Guide topic Creating Projects.