Requirements and Product Lines: Example of The Use of Doors

You might also like

Download as pdf or txt
Download as pdf or txt
You are on page 1of 21

REQUIREMENTS AND PRODUCT LINES:

EXAMPLE OF THE USE OF DOORS

JFDP conference – October 21, 2011


Gauthier Fanmuy
Phone: +33 6 10 76 29 06
Email: gauthier.fanmuy@adn.fr
ADN in a few words
AUDIT CONSULTANCY

TR
S
ICE

AI N
Belgium
RV

Riverside Business Center

ING
Boulevard International 55
SE

1070 Bruxelles
Ph: +32 (0) 4 37 27 11 79

France
CO

Head office

L
CA
17 rue Louise Michel
MP

92300 Levallois Perret

ITI
Ph : +33 (0) 1 72 03 23 81
LE

CR
X

24 Rue Jean Baldassini


SYSTEMS 69007 Lyon
Ph : +33 (0) 4 37 27 11 79
ENGINEERING
Singapore
18 years of excellence (established in 1993) 10 Anson Road
#35-09 International Plaza
70 Permanent consultants 079903 Singapore
Ph : +65 6774 5800
Turnover : 6 million Euros in 2010 Fax : +65 6774 6800

A Multi-disciplinary structure organized in Centers


of Excellence

2
Our Core Activity
in Systems Engineering
Tools
DOORS, DOORS RMF, Rhapsody
Quality Center, Change Synergy,
Reqtify, Requirements Central,
Exportim, Requitim, Lexior
Requirements Quality Analyzer, …

Training
Methods and tools
Project Engineering Execution of
Management Verification/Validation tests
Risks
Definition and Management Verification/Validation
Needs derivation of definition and
elicitation requirements optimization

Change and
Re-use of generic Configuration
requirements System Modeling Management
(products lines) (SysML, ontologies)
They trust us

4
4
Introduction
The first goal of this presentation is to show that
“traditional” Requirements Management is not
efficient enough for products line specification
Specific modeling approach developed by ADN
contribute to master requirements related to
functional and physical variants
The second goal of this presentation is to show
how to reuse the in DOORS with the Requitim©
solution

© CORTIM

5
Products Line issues
Perimeter of the
current presentation Define a test
Elaborate generic
strategy for
requirements & rationale to
variants testing
specify the overall set of
optimization
variants with commonalities Elaborate generic
and specificities risks and
mitigations

Elaborate generic
Define the data Elaborate generic
tests for
structure of the architectures to define
integration,
core model & reusable assets with
verification &
projects generic interfaces
validation

Define instantiation rules


of core assets into the Develop and reuse core
projects assets in projects

6
Requirements issues in a Products Line
context
Statement: define a complete and consistent
set of requirements covering the different
product variants
Functional variants
Physical variants

7
Requirements issues in a products line
context : improving Requirements
Engineering process
In a product line approach, the number of variants can
be from several hundred possible combinations to
several billions.
Thus, in this context, “traditional” requirements
engineering approach is not sufficient enough:
The structure of the requirements documents can be complex
with several levels of paragraphs, making it difficult to read
It is difficult to have a clear vision of what the requirements
cover or not cover: no guarantee that all variants are specified
The use of requirements attributes to define applicable
variants is not manageable with a large number of variants
combination
Therefore, it necessary to adopt innovative
approaches
8
Case study
Develop a set of generic Requirements for an
innovative function to be instantiated in different
products
Inputs: ISO Standard, Partner specification, suppliers
RFP
Activities:
Elaborate a single specification from the 3 inputs
specifications
Functional Analysis
Group existing requirements according to the external
functions (DOORS)
Removal of redundant requirements, complete requirements
with missing information, add new requirements
Review and approve the set of generic requirements
Select and instantiate the generic requirements

9
4 Generic
requirements
Traditional approach instantiation
in projects

Functional Analysis
3
Approved set
ISO of generic
requirements

1
2

RFQ
Requirements
DOORS authoring

Synthesis and
review

Partner Technical
Specification
10
10
Traditional approach

Difficulty to have a
global view of what is
expected especially
with the different
possible variants

11
Modeling approach
Goal:
Ensure the completeness and consistency of the set of
requirements
Get a complete view of ‘what the system is expected to do’ by
taking into account different variants (functional or physical)
Activities
Elaborate a single specification from the 3 inputs specifications
Make a model of the specification by highlighting the common
and specific elements among the set of variants: Variant
Breakdown Structure
Complete or change the requirements according to the Variant
Breakdown Structure
Review and approve the set of generic requirements
Select and instantiate the generic requirements

12
Example: Automotive speed sign
recognition system Commonality

Option
Structure Patterns

Mix Physical & Functional


representation

13
14
4 Generic
requirements
Mixed approach instantiation
in projects

Functional Analysis
3
Approved set
ISO of generic
requirements

1
2b
2a
RFQ DOORS
Requirements authoring

Variant Synthesis and review


Breakdown
Structure
Partner Technical
Specification
15
15
Benefits of the approach
The Variant Breakdown Structure enables to give a clear
vision of ‘what the system is expected to do’ with ‘what
variant’
Big picture: clear vision of what is expected
Underline the concepts defined in requirements
Underline the functional and physical variability
Consistency: avoid duplication of requirements by defining
common & specific requirements
Completeness: coverage of functional & physical variants
The ‘Structure Patterns’ contribute to get a complete set of
requirements
Constraint: the Variant Breakdown Structure must be
maintained (change management)

16
Reuse of generic requirements:
Requitim
Requitim is a solution developed by CORTIM
to manage the life cycle of requirements and
reuse them into DOORS: http://www.requitim.com
Deployed since 2005 in industrial
environments.
Pre-requisite
Requirements identified and in DOORS
Change management process defined
Existence of Requirement Maturity

17
REQUITIM/ReqMan
Assists users in the management of the Requirements’ life
cycle : identification, approval, change, obsolescence…
Versioning is automatic based on the maturity
Changes are controlled by managing access rights

To be adapted to the
process of the
organization

18
REQUITIM/ProductLine
Create project modules from generic modules
(complete module or subpart of module – e.g.
selection of a variant)
Project requirements are automatically identified
and traced to applicable generic requirements
(e.g. approved)
Project Requirements
Reused Requirements
Specialized requirements
Specific Requirements

19
GENERIC

Reuse of generic
requirements in
projects 1: Reference to generic
Requirement

PROJECT

4: Specialized
Requirement
2: Automatic display of
generic requirement in
the project

3: Generic requirement: reused as is

20
Conclusion
Requirements are one of the main items to manage in a products
line context
Traditional requirements engineering is not efficient enough to
ensure consistency and completeness of variants coverage
Benefits of modeling approach of variability are:
Big picture: concepts are brought to light, analysis by business experts is
easier
Anti-silo effect: common vision across Business teams
Generic requirements:
No duplication of requirements: common requirements are defined once.
Requirements are deduced and classified according the variant breakdown
structure
Completeness is done by construction
Benefits of Requirements reuse
Guaranties the consistency of the reused database
Acceleration of requirements reviews
The projects focusses on the specificities

21

You might also like