On the practice of using the IBM DOORS requirements management system at NAMI
Alexey Barinov, Head of Electronic Systems Integration Department, FSUE “NAMI”
Fig. 1. General view of the interface of the program IBM DOORS
About two years ago we started working with one of our European partners, with whom we chose a system for managing the requirements for electronics and electrical components of a car. The partner used IBM Rational technologies, in particular IBM DOORS, for requirements management and, given the positive experience, we also decided to try using this solution. The European partner maintained the base of requirements, and we, on our part, participated in their coordination and necessary adjustment. After this, the transfer of the base of requirements was successfully carried out, and all further management was carried out already on our side.
')
The quality of requirements depends not only on the tools, but also on how the requirements management process is built. The process definition was taken over by our European partner. We had access only to the part of the processes that concerned us. But the interaction processes, the structure of the project and the structure of requirements were determined by us together.
If we talk about the stagedness of the project, I must say that the process of harmonizing requirements within our cooperation took a little more time than we expected, since they affected the real responsibility of NAMI to the partner and partner to NAMI in terms of the quantity and quality of information provided and timing. But, as soon as we agreed on this part, we quickly started working with the tool. We didn’t need training as such - our partner provided advice where it was needed.
Fig. 2. Sample DXL script.
When there was a need to expand the capabilities of DOORS using DXL scripts (DOORS eXtension Language), we turned to IBM technical support for help. We were rather quickly given similar examples of using the language, and then our programmers independently adapted them to our requirements.
I would also like to note that in the US a mostly young team worked on the project, which was not constrained by the habits of doing everything on paper. Therefore, work with the requirements was originally conducted in the DOORS system.
Of course, we mainly use the requirements management system only in our direction for electricians and electronics. In working with other areas and partners, the official document is a scan in PDF format, so we still cannot get away from the documentary version of the requirements.
However, we must admit the fact that many of our partners, mostly Western, send requests in the DOORS format. This allows us to immediately load them into the database and start working with them. In the same way, Western partners get them from us. This approach saves a lot of time.
Besides saving time, the factor of error reduction is important. It is no secret that the volume of requirements on projects for creating complex systems is enormous. At the same time, part of the requirements are common to different subsystems, and the other part of the requirements are individual for a particular subsystem.
Making a mistake, working on paper with such a volume of requirements, is very easy. And the cost of a mistake can be quite high. For example, you are at the testing stage, and then suddenly there is an error in the requirements, which forces you to return to the very beginning and begin to redo many things again.
IBM DOORS capabilities enabled us to apply validation and verification requirements. We thereby avoided the presence of duplication of information and various inaccuracies, meeting the deadlines of the project.
Speaking about the prospects for the use of requirements management systems in NAMI, we can say that at the moment our direction of electronics is the most advanced, it is quite young in terms of the age of employees and is characterized by the speed of development. We were the first to start using such a systematic approach, and I very much hope that we will be able to solve the problem of scaling our experience to other areas of our organization. My colleagues see the advantages and nuances of each of the approaches and are thinking about how to still learn from our experience so that everyone can ultimately work with a single base of requirements and processes.
The State Scientific Center of the Russian Federation FGUP "NAMI" was founded on October 16, 1918 as the first research institute in the field of automotive theory and technology. “NAMI” is a modern research and experimental experimental center for the development of production for designing, designing and testing automobile platforms. SSC RF FSUE "NAMI" is also the representative of the Russian Federation in Technical Committee 22 "Road Transport" of the International Organization for Standardization.
Fig. 1. General view of the interface of the program IBM DOORS
About two years ago we started working with one of our European partners, with whom we chose a system for managing the requirements for electronics and electrical components of a car. The partner used IBM Rational technologies, in particular IBM DOORS, for requirements management and, given the positive experience, we also decided to try using this solution. The European partner maintained the base of requirements, and we, on our part, participated in their coordination and necessary adjustment. After this, the transfer of the base of requirements was successfully carried out, and all further management was carried out already on our side.
')
The quality of requirements depends not only on the tools, but also on how the requirements management process is built. The process definition was taken over by our European partner. We had access only to the part of the processes that concerned us. But the interaction processes, the structure of the project and the structure of requirements were determined by us together.
If we talk about the stagedness of the project, I must say that the process of harmonizing requirements within our cooperation took a little more time than we expected, since they affected the real responsibility of NAMI to the partner and partner to NAMI in terms of the quantity and quality of information provided and timing. But, as soon as we agreed on this part, we quickly started working with the tool. We didn’t need training as such - our partner provided advice where it was needed.
Fig. 2. Sample DXL script.
When there was a need to expand the capabilities of DOORS using DXL scripts (DOORS eXtension Language), we turned to IBM technical support for help. We were rather quickly given similar examples of using the language, and then our programmers independently adapted them to our requirements.
I would also like to note that in the US a mostly young team worked on the project, which was not constrained by the habits of doing everything on paper. Therefore, work with the requirements was originally conducted in the DOORS system.
Of course, we mainly use the requirements management system only in our direction for electricians and electronics. In working with other areas and partners, the official document is a scan in PDF format, so we still cannot get away from the documentary version of the requirements.
However, we must admit the fact that many of our partners, mostly Western, send requests in the DOORS format. This allows us to immediately load them into the database and start working with them. In the same way, Western partners get them from us. This approach saves a lot of time.
Besides saving time, the factor of error reduction is important. It is no secret that the volume of requirements on projects for creating complex systems is enormous. At the same time, part of the requirements are common to different subsystems, and the other part of the requirements are individual for a particular subsystem.
Making a mistake, working on paper with such a volume of requirements, is very easy. And the cost of a mistake can be quite high. For example, you are at the testing stage, and then suddenly there is an error in the requirements, which forces you to return to the very beginning and begin to redo many things again.
IBM DOORS capabilities enabled us to apply validation and verification requirements. We thereby avoided the presence of duplication of information and various inaccuracies, meeting the deadlines of the project.
Speaking about the prospects for the use of requirements management systems in NAMI, we can say that at the moment our direction of electronics is the most advanced, it is quite young in terms of the age of employees and is characterized by the speed of development. We were the first to start using such a systematic approach, and I very much hope that we will be able to solve the problem of scaling our experience to other areas of our organization. My colleagues see the advantages and nuances of each of the approaches and are thinking about how to still learn from our experience so that everyone can ultimately work with a single base of requirements and processes.
The State Scientific Center of the Russian Federation FGUP "NAMI" was founded on October 16, 1918 as the first research institute in the field of automotive theory and technology. “NAMI” is a modern research and experimental experimental center for the development of production for designing, designing and testing automobile platforms. SSC RF FSUE "NAMI" is also the representative of the Russian Federation in Technical Committee 22 "Road Transport" of the International Organization for Standardization.
Source: https://habr.com/ru/post/325252/
All Articles