Search the Elsmar Cove!
**Search ALL of Elsmar.com** with DuckDuckGo including content not in the forum - Search results with No ads.

Tabular Traceability by Software Item ID - IEC 62304

B

brenhale

#1
62304 has an underlying theme of 'software items'. Most of the content refers to "software item" and the traceability between design phases refers to software items as well.

so my question, Has anyone used a tabular approach (by software item #) to showing status of activities per software item, and the traceability to relevent docs. And if so, does it work very well?

ie, a table organised by a unique software item id, showing links to relevant design files, acceptance criteria, testing reports etc. As a project manager one could see any missing/outstanding tasks or ascertain other progress metrics.

There would need to be some referencing to/from the software requirements as well.

Thanks.
 

yodon

Staff member
Super Moderator
#2
We've always taken a top-down approach; i.e., tag requirements and then trace through lower level of design and test objectives and then, if necessary, down to software. Note: we typically don't trace down all the way to software units (code files). Doing so by hand would be a monumental effort once the software reaches a non-trivial level. Unless the software is rather trivial, we use a tool to manage the tracing.

What would you consider a software item? Individual code file; e.g., .c or .cc file? How would you handle the other components; e.g., .h file, data files? Feature? It can get rather complex in a hurry. What will you do when a 'module' is re-designed and/or functionality re-allocated across the architecture? I'm not suggesting that your approach wouldn't work, though. Nor am I saying what we do is best. Just suggesting that you think it through thoroughly and not make it so complex that it becomes a project in and of itself.

If your focus is more on project management, something to consider might be tracking via function points. I've seen function points used well to track the project status. I've also seen it used quite poorly (the old story of a tool being only as good as the person who wields it).
 
B

brenhale

#3
Note: we typically don't trace down all the way to software units (code files).
Is this not required by the standard? At least for class C? ie, 5.3.1 the requirements shall be transformed into achitecture and 5.4.1 the architecture shall be refined until it is represented by units. Or am I reading too much into that?

If you trace by requirements tag how do you handle the situation of multiple requirements within one item? ie how do you reference the item for testing and documentation purposes?
 

yodon

Staff member
Super Moderator
#4
We follow the 1 "shall" per requirement rule to avoid any such confusion. Each 'shall' is traced to the depth we feel is appropriate. We've supported all device classes (but no implantables) and the tracing has always been acceptable.

I don't want to dissuade you from tracing into the software units if you feel it's important. There can be tremendous benefits; however, in my experience, the overhead to manage at that level has always outweighed the benefits.
 
Top Bottom