Professional Documents
Culture Documents
Requirements and Product Lines: Example of The Use of Doors
Requirements and Product Lines: Example of The Use of Doors
Requirements and Product Lines: Example of The Use of Doors
TR
S
ICE
AI N
Belgium
RV
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
ITI
Ph : +33 (0) 1 72 03 23 81
LE
CR
X
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
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
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
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
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