manageware.co.il

Purpose

How to manage requirements of a set of products, using commonalities and variability and specialties among the products

Benefits

- Reuse of common requirements

- Central control of commonalities

- Shorter Time-To-Market

- Central Updates for requirements changes between product lines.

Concept

- Splitting the requirements base into infrastructure and products

- Managing commonalities, variability, and product specific requirements

- Tractability between instances of same requirements in different product lines (rather than just “clone and own”)

- Terminology: Product, Product-line, Common, Variant, Specialty

Possible Solutions in DOORS

1. Common and Variant in a single module using Filters.

2. Central module for Common requirements and a separate module for for variant requirements

3. Base infrastructure module for common requirements and a module per product line with copy of common requirements and additional variant requirements

Solution 1: “One Module” – concept

- One module contains both common and Variant requirements

- Use Objects hierarchy to structure module

- Use Object Attributes to differentiate variants

- Use Filters and Views to display required variant requirements

- Use Views to switch between complete list and a product line

Solution 1: “One Module”- Pros.

- Complete view of all requirements for all product lines

- Simplicity – basic DOORS operations (filters, etc…)

Solution 1: “One Module” – Cons.

- Large modules

1. Lower performance

2. Navigation in the module is less convenient

- No real separation between product lines – error prone.

- Document Structure (i.e. Headings) must remain the same.

- Baselines are for the entire module – not per product line

- Requires multi users work on the same module

Solution 2: “Variant Modules” – concept

- Central module for common requirements

- Separate module for each product-line that contains only the variant requirements (Delta)

- No duplication of Common requirements in different modules

- The “big picture” is represented by a set of modules

- Links represent “Derived From” relationship

Solution 2: “Variant Modules” – Pros.

- Smaller modules

1. Better performance

2. Easier to navigate in the module

- Simplicity – basic DOORS operations

- Central view a of an original requirements and all it variants.

Solution 2: “Variant Modules” – Cons.

- No complete view with “out-of-the-box” functionality

- No dynamic updates between product lines

Solution 3: “Base and Variant” – concept

- One “Base module” which holds the a product “reference” requirements

- Each Product Line module is a copied module of the “Base module” (or only relevant sections are copied)

- Links between each copied requirement in the Variant module to its source in the Base module

- In the Variant modules requirements can modified and specific requirements added

- Base module manager is responsible to check for modification in the variant modules (‘Suspect Links’) and update the Base and other Variants

Solution 3: “Base and Variant” – Pros.

- Complete view of all requirements per product line

- Dynamic updates between different product lines

- Efficient reuse of requirements between different product lines

Solution 3: “Base and Variant”- Cons.

- Relatively complex setup and management

- Requires management of Base module

Telelogic-Publishing-Engine-overview

IBM-Telelogic-Doors-Web-Access-Overview

What is new in DOORS 9 and Web Access

Share on Facebook