![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Tracing Source Code to Requirements Topic Summary: Can it be done? Is it worth the effort? Created On: 26-May-2005 02:59 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
I've been thinking about ways to trace our source code up to our SRS requirements. I have an idea of how it might be done, using some (or probably "a whole bunch of") DXL and an extra module. I was just curious if anyone else has tried to accomplish this, and whether or not the effort drove them into a mad, foaming stupor. The idea I have would make the process fairly automated, so our programmers wouldn't have to manually sprinkle comments around in the source code. This is all preliminary, though, and I'd like your guys' take on it before I pour too much more effort into the research and design (actually, I'm just lazy).
Any thoughts on tracing code up to requirements? Thanks, Brant |
|
![]() |
|
![]() |
|
Brant,
Tracing code to SRS requirements could be a rather daunting task much in part because code is always changing. What I would reccomend is using a tool such as Rational Rose to create class diagrams for your code and then by using Telelogics tool (http://www.telelogic.com/products/doorsers/doors/roselink.cfm) you can link your class diagrams to your SRS documents. And anytime you update your class diagram you have the option of updating the DOORs module with the new changes. If you are looking for lower level traceabilty let me know, I have some ideas for this as well - I would type more but the caffine hasn't started working yet. Hope this helps. -Adam Edited: 16-Jun-2005 at 16:53 by Adam Ninnemann |
|
![]() |
|
![]() |
|
Telelogic's Tau product will allow you to trace diagrams, classes, almost anything, back to your requirements. But that's for low-level requirements or design tracing.
For source code traceability, we simply have a formal Source Code module whereby each object represents a single source code file, using the name of the file for the Object Text. That's the level to which we trace. Same thing for Test Procedures. Good luck to you if you need finer trace resolution for your code, and don't hesitate to post your solution back here! |
|
![]() |
|
![]() |
|
Thanks for the responses. In the spirit of getting started, we had decided to take Greg's approach....to a slightly more detailed level. Each object is a code function, and filenames are object headers. We had thought about purchasing Tau, but we blew all our money on DOORS, Change/Synergy and CM/Synergy.
![]() My grand plan was to somehow extend Greg's method to use triggers to synchornize the actual source code with the "source code" module. So, at some point in modifying the code or requirements, DOORS would inspect the code and compare it to the "source code module". The plan was to have a DXL script (several, probably....) modify the source code by embedding XML-like comments in function headers noting the object IDs of the requirements the code meets. For example, if I created a link between the "getVoltage()" function object in the "source code" module and some SRS requirement, a script would trigger and that script would go find the "getVoltage" function in the actual source code, and add something like: quote: to the function header. The tagging would also make it easier for DOORS to find and modify existing "links", such that if SRS-1234 was deleted, the script could find it in the source code and remove it. I really don't have a clue if something like this is even remotely feasible, but thought I'd look into it. ![]() |
|
![]() |
|
![]() |
|
AT Raytheon, because we were an CMM Level 3 and working on safety critical code, we had to trace from SRS to Design, and thence from Design to Code.
This included Top Level Design (or Class Diagrams in the uML world). Since the devil is in the detail, this is critically important and some bugs can be prevented this way. However, I would suggest that you trace DOWNWARD from the SRS to the Design and thence down to code. Much easier and less 'creative' or involving activities that might involve fantasy. |
|
![]() |
|
![]() |
|
Since this was posted awhile ago, I'd be interested in what you did.
I'm just importing the SDDS (Software Detailed Design Specs) into DOORS and tracing FROM the SRS down to the SDDS. Since the SDDS is nicely partitioned with the Class Diagram name as the first part of the paragraph, it's relatively simple so long as you remember that it's a many to many trace. |
|
![]() |
|
![]() |
|
Adam I would be interested in getting your thoughts on traces to lower level requirements. For MILSTAR, we had to insert into the header of our source code, all the SRS requirements that traced to that code.
It really wasn't very difficult since we were already tracing from the SRS to the SDS |
|
![]() |
|
![]() |
|
Tracing Source Code to Requirements is helpful for our work.
I think it would be very simple if DOORS could provide the interface to Eclipse,one of the most popular develop environment. Then we can import the code in Eclipse to DOORS just like from word to DOORS. And now most of my work is to generate traceability bewteen requirement document and design document/code document. So In my mind, DOORS is just a text management tool. |
|
![]() |
|
![]() |
|
There is already (at least) one Eclipse-DOORS integration, look DoorKeeper at
http://www.embeddedplus.com/Em...sDoorKeeperEclipse.php ------------------------- Pekka.Makinen@softqa.fi SoftQA Oy -http://www.softqa.fi/ |
|
![]() |
|
![]() |
|
Another proven way, is to use a code-generative UML modelling tool like Telelogic Rhapsody with its requirements' Gateway add-on. That way, all development artefacts are driven from (and therefore traceable from) requirements. See:
http://modeling.telelogic.com/...ody/add-on/gateway.cfm |
|
![]() |
Telelogic DOORS
» General Discussion
»
Tracing Source Code to Requirements
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.