- The application of the Systems Engineering (SE) approach has become an increasingly necessary guide for an efficient design of modern complex systems. However, experience has shown that without a sound strategy and structure, shared at company level, the benefits promised by the SE approach can be reduced. The work described in this document aims to highlight a tangible return of investment about how the definition and the implementation of a Requirement Management Process, developed by Altran S.p.A. and Hitachi Rail Italy, has allowed to fully exploiting the promised benefits.
I. INTRODUCTION
The work described in the present paper is the result of a joint effort by Hitachi Rail Italy’s System Engineering team and Altran, aimed at the implementation of a Requirement Management (RM) Process by means of a customized RM environment, based on IBM Rational Doors tool.
The RM Process aims to help users to better identify, control, verify, share and track requirements and changes that occur during entire project lifecycle according to INCOSE.
II. CONTEXT & OBJECTIVES
The purpose of the defined process is to guarantee the 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.
1. Preliminary assessment to outline current scenario: snapshot of the processes in use, definition of the needs and implementation of an action plan; 2. Formalization of the RM Process, developed according to the “V” model, progressively implemented within a specific RM tool (IBM Rational Doors 9.x, fully customized thanks to a set of functionalities already developed by Altran); 3. Process implementation on a pilot project: application of the defined process within the developed 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; 4. Knowledge transfer: training and coaching of the
Client’s key people about RM process and tool; 5. RM environment release: this approach (process and tools) have been applied to next Hitachi Rail Italy’s projects. for the
Requirement
Automatic Impact Analysis: A top level change is notified in real time to lower specification; Key Performance Indicators (KPI): project’s evolution is monitored by dedicated metrics;
Management of the requirements verification and validation in order to track how the technical requirements are satisfied and verified.
B. The Requirement Management Framework In order to allow all the users to benefit from an environment able to support them during the development phases, the IBM Doors tool has been strongly customized thanks to a series of functionalities (previously developed by ALTRAN) that have been configured for the purpose.
The overall framework (IBM Doors 9.x + Altran libraries) fully implemented the RM Process, allowing the users also to automatize the manual, repetitive and boring operations, increasing the effectiveness and the efficiency.
This framework can rapidly adopted by all the Clients who are using or are intended to use IBM Doors. This framework is flexible, modular and easy-to-use and allow the efficient reuse of requirements and specifications, a full traceability and navigability of information, allowing the users to extract metrics and documents in automatic way.
The proposed approach and the related RM Process have been developed and tuned on a specific HRI pilot project. The developed process included the functional requirements traceability starting from customer requirements (Compliance Matrix) through system requirements (SyRS) down to functional and performance test specifications (FTS & PTS). This approach allowed to correctly manage the requirements verification and validation during the project development for engineering point of view and for the customer acceptance. The first pilot cars of this project was delivered on February 2017. The first cars (standard operational consist) started the revenue service on November of the same year.
The complete qualification test phase time was less than 9 months (the test sessions ended 2 weeks before the revenue service start). A previous similar project of some year ago (taken as reference because not employed a robust SE approach) took about 22 months to complete the overall qualification test phase before starting the revenue service. This consistent reduction of qualification phase time was mainly due to the lack of a consolidated system engineering approach and a not structured requirement management process (some critical requirement was better elicited with vehicle already delivered, with experimental test campaigns which brought to significant retrofit activities).
Compared with this reference project, the developed RM approach allowed to save the qualification and integration test time of more than 50%.
The work described in the present paper has shown how the developed RM framework has been used in a coherent way with the RM Process with consequent and evident benefits.
Both the RM process and the framework are in continuous evolution.
Currently, ALTRAN is supporting Hitachi Rail Italy to enhance the requirements quality, easing the writing and the analysis of functional requirements according to the ISO29148. The Requirements Quality is assured on the basis of defined rules, and patterns by means of the System Engineering Suite (developed and marketed by The Reuse Company).
Moreover, ALTRAN and Hitachi started working on future developments: 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 before the design begins in order to spend less time redefining requirements and rewriting resulting in fewer development iterations needed to achieve quality results.