Bidirectional Traceability between StrictDoc and KiCad 10+

[siotesl]

The idea is to propose and explores a bidirectional integration between StrictDoc and KiCad 10 (or later) to provide end-to-end requirements traceability for hardware development.

StrictDoc would manage and version system, hardware, software, verification, and regulatory requirements, while KiCad would link design artifacts to those requirements. The integration would allow traceability in both directions:

Requirements ⇄ Design ⇄ Verification

Key objectives:

• Bidirectional links between StrictDoc requirements and KiCad design artifacts.
• Automatic traceability and coverage reports.
• Change-impact analysis.
• Support for quality assurance and safety-critical development workflows.

The long-term vision is to bring modern requirements management and lifecycle traceability to the open-source electronics ecosystem while remaining extensible and compatible with future KiCad releases.

[rkfrf2607]

I am intrigued by the idea of connecting the two. I would like to understand more about the concept (and offer feedback/be involved in the process).

My company is currently performing trials for KiCad as a replacement for our current EDA software suite. A requirements management tool that cross links to the schematic would be an additional feature that does not currently exist in our workflow and would likely tip scales further in KiCad's (and naturally strictdoc's) favor.

Some thoughts and questions as I consider how the implementation might work:

1. How do you envision the linkage will physically appear between a requirement and a design document?
   1. Would there be an object within KiCad that would contain an HTTP link, UID, or other type of hash that would have some knowledge of the strictdoc requirement?
   2. How "live" is that linkage? Would it require the strictdoc http server to be running?
   3. How will small sections of circuitry be called out specifically? (e.g. "Here is some math that shows why I chose these three filter
      component values, which satisfies the requirements shown in UID 'Input Filtering'")
   4. If the design documentation is printed or otherwise made static, how will the requirement linkage appear in that format?
2. How will that linkage maintained or updated as new requirements or circuits are introduced?
3. How will versioning be documented between the requirements and the hardware design files?
   1. That is, how will a user know what version of a requirement is linked in their design artifacts?
4. Would the hardware design documentation and strictdoc source requirement files need to be hosted in the same git repository?

If the KiCad object used to link to requirements is sufficiently genericized, this feature may also be utilized to link to an issue tracker. For example, we are currently evaluating tracking hardware issues within our internal gitlab instance. In this way, a three-way linkage between requirements, identified issues/tasks, and the hardware design artifacts themselves could be intrinsically linked. If a hardware design contains a link to a requirement(s) and an issue with hardware is identified, one could conceivably (1) create a corresponding gitlab issue, (2) call out or link affected requirements by UID or MID in that issue, (3) check in fixes to the hardware design files referring to the issue number all while (4) maintaining a live link to the requirement showing traceability within the hardware design itself.

Overall, I am encouraged by this concept and I think it would be very valuable to have this capability.