It is very likely that you start development projects that are similar to what you were already doing before.
We estimate that 80% of our customers manage multiple product models, versions, variants, etc. Managing commonalities between those projects saves a lot of effort, but also highly enhances the quality of the products. Unfortunately managing product variants adds multiple levels of complexity to the process. Everything you do, you need to understand in the context of multiple variants. It’s a painful process that requires tools and also human resources investment on the customer side.
There are multiple levels for how much you need or want to control variants, ranging from...
- separate projects with limited connectivity
- managing just one shared set of requirements, designs, verification procedures and generating variant-specific documentation from the shared asset.
Let’s speak more about option B: how we can share the requirements (or better, let’s say specifications) to include also Test Specification documents so we can easily reuse the content when we start new products, and/or control how the changes are shared and applied to all the variants.
Let’s begin with a little theory. The basis for demonstrating the concept is to understand following data structure (which we will later extend):
- Common Specification - the specification document that contains the shared requirements for the variants.
- Variant Specification - a requirements (or test) specification document that is released into development.
The Live-Branch concept was added into our product features in 2013 make it possible to create a branch of a common specification document, and any time the common specification is modified the change is instantly* propagated into any branched documents, which contain variant-specific specifications.
* This is why we call the feature “live”. But of course you can configure the branching so it doesn’t share the changes instantly, but on demand.
So how is a Variant defined? Typically a Variant is defined as a selection of features you want to include in your product variant.
This is what we are going to describe now, and what will be released as a separate feature set called Polarion® VARIANTS™.
A Variant is a selection of features.
To be more specific, you define a feature model of your product: what features exist, what is their relationship (e.g. you have to select if the car model has halogen or xenon lights), and the Variant object defines what features will be selected.
This makes it easy for you to compare your product models and check what features are being used in what variants.
Now you can do more than just describe the common requirements; you can actually define a so-called “150% specification” that contains all the requirements for all your product models, and provide additional requirement constraints that a given requirement is applicable only if some particular features are selected.
It would not be enough to just link requirements with features as a dependency. Constraints are more complex and the ability to specify the restriction in a special Constraint Editor makes it really possible to gather the applicable variant requirements into a single specification document.
Once you have your 150% specification and Variant defined, you can generate the 100% specification automatically. It contains only the requirements that are related to the variant feature selection.
As with most anything with Polarion, it is up to you if you would like to follow this approach purely, or if the generated 100% specification is just a skeleton that you would still be able to adjust, with the changes to 150% specification applied later.
The new Polarion VARIANTS will be licensed as an Add-on. You will need to obtain your license and assign the Polarion VARIANTS add-on to the users who need to define the variants, generate specifications and define requirements constraints.
The add-on is powered by pure::variants technology and requires a server-side component (no additional cost) on your server.