Requirements 5.2.2 b SW System I/O vs g Data Defs/DBs

[drm71]

What is the motivation for 2 separate items listed in 62304.5.2.2 (Requirements Contents) specifically to data formats, b) examples are related to SW system I/O but includes as examples data ranges, defaults, whereas g) mentions data definition (which in my head sounds overlapping with b) and databases, and mentions "form, fit and function" (which I'm not familiar with but googling around was hard to understand specifically what's important here).

OK, I can maybe guess there might be some advantages to having I/O data requirements and separate internal storage/calculation data formats, I'm just not sure what "the issue is" that stopped this being written in one point as data definition (including input output data) &databases

 

[yodon]

Without trying to get into the heads of the standards writers (heaven forbid!), I think the groupings there are mostly intended to be for thought stimulation as much as anything. The groupings are intended to ensure you consider as broad a range of potential requirements as possible rather than just on functionality. Regardless, I think group b items are more targeted at what's coming into the system (front end) and g items are what the system is saving / managing (back end). (After looking again, the "form / fit / function" note does seem weird.)

 

[Tidge]

I also cannot channel the authors' mental model, but it is obvious from many different medical device standards (especially ones that touch on/directly address software) that some elements of those standards were written from a sort of 'work backwards from (a) solution/problem (that is well understood by an author)' approach. In this case, I get the sense that one or more of the authors had once encountered some specific problem that caused the grief and so wanted to put some extra light on that particular area.