User Needs -> Requirements -> SRS & SDD

[CDRuma]

Hi all,

I am developing a class II medical device (that primarily consists of software) and currently working on fleshing out all of the requirements, SRS, and SDD docs. We have an initial set of user needs derived from previous experiences, customer needs, and regulatory requirements. We are working on the software architecture diagram, and FDA's examples illustrate linking software modules to specific system or software requirements.

I am struggling a bit with structuring the DI hierarchy appropriately in a way that accomplishes this and also makes life easier for the devs, who need to produce system documentation that is both traceable and comprehensive enough for FDA. I have reviewed the FDA SW guidance and tried to structure the workflow to hit all of the points they specify. The SDD documents we currently employ describe interfaces, connections, architecture, etc. (I just didn't have room for all that here). Below, I have provided an example of how a general User need would be used to derive DIs within my current system.

This hierarchy does not allow for me to trace SWReqs or SYSReqs to individual components of the system since we have dedicated SRS and SDD sections for the system components. Additionally, for many cybersecurity controls/requirements, there may not be a single component that satisfies the requirement, so not every requirement may be able to be logically and meaningfully included in the architecture diagram and/or security architecture views.

I also worry I may be conflating the content of SRS and SDD documents. My understanding is that the SRS is a place to blow up SWReqs into more defined requirements and the SDDs explain how the system will meet those requirements.

Please let me know if I have the right idea with this documentation structure. I'd appreciate if you could point me in the direction of a good template/example.

 

[Tidge]

This is a somewhat complicated issue, both from the top-down PoV and from the "getting engineers to write code" PoV.

Personally, I've had the most success when the SRS are broken up and sequestered into semi-obvious distinct groupings to allow the engineers to start coding in bite-sized pieces. Many programmers prefer to also tackle things from a top-down approach, but my experience has been that they end up spending a lot of time refactoring code that doesn't satisfy requirements but instead is more framework oriented.

I mention this tendency because it can lead to some measure of analysis paralysis on the architecture (which will ultimately be in the hands of the programmers... that is, the DI hierarchy can't really force the shape of the architecture. Instead, once some of the key requirements can be demonstrated to be met, that is when the time to best formally construct the architecture and make sure that all of the requirements are being allocated, and that the allocation makes sense.

 

[yodon]

It just gets uglier when you layer on risk analysis and cybersecurity analysis!

And note that both of those could well drive architecture decisions.