=Paper=
{{Paper
|id=Vol-2248/paper12
|storemode=property
|title=A Concrete Return of Investment due to the Requirements Management Process Implementation
|pdfUrl=https://ceur-ws.org/Vol-2248/paper12.pdf
|volume=Vol-2248
|authors=Claudia Agostinelli,Francesco Inglima,Rodolfo Mazzei,Sergio Di Ponzio,Salvatore Zazzaro
|dblpUrl=https://dblp.org/rec/conf/ciise/AgostinelliIMPZ18
}}
==A Concrete Return of Investment due to the Requirements Management Process Implementation==
https://ceur-ws.org/Vol-2248/paper12.pdf
A concrete Return of Investment due to the
Requirements Management Process Implementation
Claudia Agostinelli, Francesco Inglima, Salvatore Zazzaro
Rodolfo Mazzei, Sergio Di Ponzio
EC Systems Engineering System Engineering / Vehicle Systems Integration
ALTRAN S.p.A. HITACHI RAIL ITALY Naples, Italy
Rome, Italy
Copyright © held by the author
Abstract— The application of the Systems Engineering 1. Preliminary assessment to outline current scenario:
(SE) approach has become an increasingly necessary guide snapshot of the processes in use, definition of the
for an efficient design of modern complex systems. needs and implementation of an action plan;
However, experience has shown that without a sound 2. Formalization of the RM Process, developed
strategy and structure, shared at company level, the according to the “V” model, progressively
benefits promised by the SE approach can be reduced. The implemented within a specific RM tool (IBM Rational
work described in this document aims to highlight a Doors 9.x, fully customized thanks to a set of
tangible return of investment about how the definition and functionalities already developed by Altran);
the implementation of a Requirement Management 3. Process implementation on a pilot project: application
Process, developed by Altran S.p.A. and Hitachi Rail of the defined process within the developed
Italy, has allowed to fully exploiting the promised benefits. framework to a pilot project in order to validate them.
According to the users’ feedback, both the process
and the framework were enhanced and updated;
I. INTRODUCTION 4. Knowledge transfer: training and coaching of the
The work described in the present paper is the result of a Client’s key people about RM process and tool;
joint effort by Hitachi Rail Italy’s System Engineering team 5. RM environment release: this approach (process and
and Altran, aimed at the implementation of a Requirement tools) have been applied to next Hitachi Rail Italy’s
Management (RM) Process by means of a customized RM projects.
environment, based on IBM Rational Doors tool.
The RM Process aims to help users to better identify, A. Key Points of the Process
control, verify, share and track requirements and changes that
occur during entire project lifecycle according to INCOSE. Centralized Database for the Requirement
Management;
II. CONTEXT & OBJECTIVES Definition of Roles, Responsibilities and Activities;
The purpose of the defined process is to guarantee the Requirement Distribution (Allocation & Propagation);
management of project requirements that make up the
specification of a vehicle system and to realize a complete
traceability of all the project steps across the entire life-cycle
(from customer specifications down to system validation,
through system design and development).
To meet this goal, the process has been structured in steps
to ensure that a common understanding of the requirements is
established and maintained throughout the entire System life
cycle. At the same time, the traceability will allow to observe
the degree of coverage of the input requirements during the
progress of the project. Fig. 1. Requirement Distribution (Allocation & Propagation)
III. APPROACH & SOLUTION Automatic Impact Analysis: A top level change is
notified in real time to lower specification;
In order to meet the identified objectives, the activity was
divided in 5 progressive steps: Key Performance Indicators (KPI): project’s evolution
is monitored by dedicated metrics;
Management of the requirements verification and approach) took about 22 months to complete the overall
validation in order to track how the technical qualification test phase before starting the revenue service.
requirements are satisfied and verified.
This consistent reduction of qualification phase time was
mainly due to the lack of a consolidated system engineering
B. The Requirement Management Framework approach and a not structured requirement management
In order to allow all the users to benefit from an environment process (some critical requirement was better elicited with
able to support them during the development phases, the IBM vehicle already delivered, with experimental test campaigns
Doors tool has been strongly customized thanks to a series of which brought to significant retrofit activities).
functionalities (previously developed by ALTRAN) that have
been configured for the purpose. Compared with this reference project, the developed RM
approach allowed to save the qualification and integration test
The overall framework (IBM Doors 9.x + Altran libraries) fully time of more than 50%.
implemented the RM Process, allowing the users also to
automatize the manual, repetitive and boring operations, V. CONCLUSIONS
increasing the effectiveness and the efficiency.
The work described in the present paper has shown how the
This framework can rapidly adopted by all the Clients who are developed RM framework has been used in a coherent way
using or are intended to use IBM Doors. This framework is with the RM Process with consequent and evident benefits.
flexible, modular and easy-to-use and allow the efficient reuse
of requirements and specifications, a full traceability and Both the RM process and the framework are in continuous
navigability of information, allowing the users to extract evolution.
metrics and documents in automatic way. Currently, ALTRAN is supporting Hitachi Rail Italy to
enhance the requirements quality, easing the writing and the
IV. RESULTS & ADDED VALUE analysis of functional requirements according to the ISO29148.
The proposed approach and the related RM Process have been The Requirements Quality is assured on the basis of defined
developed and tuned on a specific HRI pilot project. rules, and patterns by means of the System Engineering Suite
(developed and marketed by The Reuse Company).
The developed process included the functional requirements
traceability starting from customer requirements (Compliance Moreover, ALTRAN and Hitachi started working on future
Matrix) through system requirements (SyRS) down to developments:
functional and performance test specifications (FTS & PTS). 1. Product Family and variants management: from a source
project it will be possible to instantiate one or more similar
new target projects containing a subset of modules and
requirements of the source one. It will be also possible to
keep traceability among the source and target(s) in order to
perform change impact analyses. Source project can be a
generic application to be further developed and customized
or a project to be cloned entirely.
2. Modelling and simulation of functional requirement: allow
system architects to simulate requirements and to detect
ambiguous, incorrect, missing, or conflicting requirements
Fig. 2. Traceability (from customer specificatio down to FTS) before the design begins in order to spend less time
redefining requirements and rewriting resulting in fewer
This approach allowed to correctly manage the requirements development iterations needed to achieve quality results.
verification and validation during the project development for
engineering point of view and for the customer acceptance. REFERENCES
The first pilot cars of this project was delivered on February
2017. The first cars (standard operational consist) started the [1] INCOSE, “Systems Engineering Handbook, A Guide For System Life
revenue service on November of the same year. Cycle Processes And Activities”, Fourth edition, INCOSE-TP-2003-
002-04, 2015.
The complete qualification test phase time was less than 9 [2] ISO/IEC/IEEE 29148 - Systems and software engineering — Life cycle
months (the test sessions ended 2 weeks before the revenue processes — Requirements engineering.
service start). A previous similar project of some year ago [3] ISO/IEC/IEEE 15288 - Systems and software engineering - System life
(taken as reference because not employed a robust SE cycle processes.