March 30, 2017 at 11:29On the practice of using the IBM DOORS requirements management system at NAMI
Alexei Barinov, head of the department of electronic systems integration FSUE "NAMI"
Fig. 1. General view of the IBM DOORS program interface
Two years ago, we started working with one of our European partners, with whom we selected a system for managing the requirements for the electronics and electrical components of a car. The partner used IBM Rational technologies, in particular IBM DOORS, to manage requirements and, taking into account the positive experience, we also decided to try using this solution. The European partner maintained a database of requirements, and we, for our part, participated in their coordination and necessary adjustment. After that, the transfer of the requirements base was successfully carried out, and all further management was already on our side.
The quality of requirements depends not only on the tools, but also on how the requirements management process is structured. The process definition was undertaken by our European partner. We had access only to that part of the processes that concerned us. But the interaction processes, project structure and requirements structure were determined by us together.
If we talk about the stages of the project, it must be said that the process of harmonizing requirements within the framework of our interaction took a little longer than we expected, since they affected the real responsibility of US to the partner and partner to US in terms of the quantity and quality of information provided and timing. But, as soon as we agreed on this part, we quickly enough began to work with the tool. We did not need training as such - our partner provided consultations where necessary.
Fig. 2. An example script in DXL.
When it became necessary to expand the capabilities of DOORS using DXL scripts (DOORS eXtension Language), we turned to IBM technical support for help. We were promptly provided with similar examples of the use of the language, and then our programmers independently adapted them to our requirements.
I would also like to note that in US, the project worked mainly on a young team that was not constrained by the habits of doing everything on paper. Therefore, work with requirements was initially carried out in the DOORS system.
Of course, we mainly use the requirements management system so far only in our area of electricians and electronics. In working with other areas and partners, the official document is a scan in PDF format, so we can’t get away from the documentary version of the requirements yet.
However, we must admit the fact that many of our partners, mostly Western, send requirements in the DOORS format. This allows us to immediately upload them to the database and start working with them. In the same way, Western partners receive them from us. Such an approach can significantly save time.
In addition to saving time, the factor of reducing errors is important. It is no secret that the volume of requirements for projects to create complex systems is huge. At the same time, part of the requirements are common for different subsystems, and the other part of the requirements are individual for a particular subsystem.
It is very easy to make a mistake when working on paper with such a volume of requirements. And the price of the error can be quite high. For example, you are at the stage of testing, and then suddenly a mistake in the requirements is found, which forces you to return to the very beginning and begin to redo many things again.
The capabilities of IBM DOORS enabled us to apply validation and verification methods for requirements. We thereby avoided duplication of information and various inaccuracies by meeting the project deadlines.
Speaking about the prospects for the application of requirements management systems in the US, we can say that at the moment our area of electronics is the most advanced, it is also quite young in terms of the age of employees and is characterized by the speed of development. We were the first to use this systematic approach, and I really hope that we can solve the problem of scaling our experience to other areas of our organization. My colleagues see the advantages and nuances of each approach and think about how to nevertheless adopt our experience, so that everyone will eventually work with a single database of requirements and processes.
The State Scientific Center of the Russian Federation FSUE NAMI was founded on October 16, 1918 as the first research institute in the field of automobile theory and technology. NAMI is a modern research and development experimental center for the development of production for the design, construction and testing of automotive platforms. SSC RF FSUE “NAMI” is also a representative of the Russian Federation in the Technical Committee 22 “Road Transport” of the International Organization for Standardization.
Fig. 1. General view of the IBM DOORS program interface
Two years ago, we started working with one of our European partners, with whom we selected a system for managing the requirements for the electronics and electrical components of a car. The partner used IBM Rational technologies, in particular IBM DOORS, to manage requirements and, taking into account the positive experience, we also decided to try using this solution. The European partner maintained a database of requirements, and we, for our part, participated in their coordination and necessary adjustment. After that, the transfer of the requirements base was successfully carried out, and all further management was already on our side.
The quality of requirements depends not only on the tools, but also on how the requirements management process is structured. The process definition was undertaken by our European partner. We had access only to that part of the processes that concerned us. But the interaction processes, project structure and requirements structure were determined by us together.
If we talk about the stages of the project, it must be said that the process of harmonizing requirements within the framework of our interaction took a little longer than we expected, since they affected the real responsibility of US to the partner and partner to US in terms of the quantity and quality of information provided and timing. But, as soon as we agreed on this part, we quickly enough began to work with the tool. We did not need training as such - our partner provided consultations where necessary.
Fig. 2. An example script in DXL.
When it became necessary to expand the capabilities of DOORS using DXL scripts (DOORS eXtension Language), we turned to IBM technical support for help. We were promptly provided with similar examples of the use of the language, and then our programmers independently adapted them to our requirements.
I would also like to note that in US, the project worked mainly on a young team that was not constrained by the habits of doing everything on paper. Therefore, work with requirements was initially carried out in the DOORS system.
Of course, we mainly use the requirements management system so far only in our area of electricians and electronics. In working with other areas and partners, the official document is a scan in PDF format, so we can’t get away from the documentary version of the requirements yet.
However, we must admit the fact that many of our partners, mostly Western, send requirements in the DOORS format. This allows us to immediately upload them to the database and start working with them. In the same way, Western partners receive them from us. Such an approach can significantly save time.
In addition to saving time, the factor of reducing errors is important. It is no secret that the volume of requirements for projects to create complex systems is huge. At the same time, part of the requirements are common for different subsystems, and the other part of the requirements are individual for a particular subsystem.
It is very easy to make a mistake when working on paper with such a volume of requirements. And the price of the error can be quite high. For example, you are at the stage of testing, and then suddenly a mistake in the requirements is found, which forces you to return to the very beginning and begin to redo many things again.
The capabilities of IBM DOORS enabled us to apply validation and verification methods for requirements. We thereby avoided duplication of information and various inaccuracies by meeting the project deadlines.
Speaking about the prospects for the application of requirements management systems in the US, we can say that at the moment our area of electronics is the most advanced, it is also quite young in terms of the age of employees and is characterized by the speed of development. We were the first to use this systematic approach, and I really hope that we can solve the problem of scaling our experience to other areas of our organization. My colleagues see the advantages and nuances of each approach and think about how to nevertheless adopt our experience, so that everyone will eventually work with a single database of requirements and processes.
The State Scientific Center of the Russian Federation FSUE NAMI was founded on October 16, 1918 as the first research institute in the field of automobile theory and technology. NAMI is a modern research and development experimental center for the development of production for the design, construction and testing of automotive platforms. SSC RF FSUE “NAMI” is also a representative of the Russian Federation in the Technical Committee 22 “Road Transport” of the International Organization for Standardization.