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

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).

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.

Updating Components

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 from Components