Composite Working-Sets

Introduction

A composite Working-Set is created by combining existing Working-Sets into a new Working-Set. Similar to tracker other Working-Sets can be included or shared into the composite Working-Set. Today the only way to re-use a tracker in multiple Working-Sets is to declare it shared, but this kind of sharing is constrained to share the tracker with the parent Working-Set. Composite working-Sets will remove this limitation.

Use Cases

Reusing Components or Platforms

A reusable component is used in different products or product variants. When reusing components the requirements defined for the product are allocated to system requirements defined for the component (or other artifacts defined on component-level).

Frequently the artifact being re-used is not just a simple component but a complete platform which most likely is more complex, but principally works the same way.

In the following example product A, C and C are derived from a common product. The product requirements can be linked by system requirements of the component (as indicated by the dotted arrow). There two components with two version each used in different combinations by the products.

When reusing a component in a product:

• It must be possible to link from system requirements to the product requirements of the specific product.
• Links that exist to product requirements of the common product must be duplicated to point to the corresponding requirement of the specific product.
• The trackers reused in the product must be easily accessible within the context of the product Working-Set.

Basically that matches sharing on level of Working-Sets instead of sharing on level of trackers.

Due to the ability to reuse multiple Working-Sets it is possible to create combinations of component versions / branches that can't be achieved by sharing trackers from the parent Working-Set.

The illustration below is of course a oversimplification as a component generally will not consist of a single requirement specification, but it consist of multipel specifications on different levels containing connected artifacts.

Updating Components or Platforms

This use case consist of two parts:

1. identify products that could use the new component.
2. Replace the used component.

Identifying potential candidates for updates could be done by the user by checking which Working-Sets are using the previous component version. This means the ability to find reusing Working-Sets must be available in the UI.

Replacing a re-used Working-Set requires rewriting the reference configuration and references.

Sharing Stakeholder Requirements

The main difference between sharing stakeholder requirements and components is that components are usually considered a downstream artifact while stakeholder requirements are considered an upstream artifact.

That means the direction of the reuse is to the upstream,

Building a System of Systems by Combining Working-Sets

Create Sub-system Working-Set from component Working-Sets.

Create System Working-Set from sub-system Working-Set.

Create System of System Working-Set from System Working-Set.

Advanced Variant Management Based on Composite Working-Sets

Include Working-Sets based on Feature Model?

Filtering and parameterization of artifacts based on Working-Set context.

Maybe better to describe separately?

Baselining Composite Working-Sets

Baseline must span all included Working-Sets recursively.

Merge must be able to span composite Working-Set (Pre-requisite: Working-Set merge)