Using OpenFastTrace to trace requirements in Xen functional safety
Size: 10.49 MB
Language: en
Added: Jun 07, 2024
Slides: 12 pages
Slide Content
Requirement Traceability in Xen FuSa with OFT Sebastian Bar – Exasol Ayan Kumar Halder – AMD
Requirements-as-Code - why Xen manages its documentation in the form of MD/RST/ Pandoc files. Thus, we intend to reuse the same formats. Ease of review Zero overhead to set up Use of Git for the revision control Easy to decouple the requirements from the traceability tool. So, the requirements does not stay within the tool itself. Thus, it becomes easier to extract the requirements and share it with other opensource and inhouse projects ( eg Zephyr, ELISA). Requirements Tool to manage/link/trace requirements Minimal influence of the tool on how we write/store requirements
Why we chose OpenFastTrace Allows us to write requirements as code Opensource, easy to set up Least intrusive. Doesn't really define how to write requirements Allows versioning of each requirement, thus detecting obsolete requirements Can link requirements ( ie text) to code and one code to another code Actively maintained and well supported Project has been in active development since 2016 Traceability report takes less than 1 second to generate
Let's learn more about OFT https://www.youtube.com/watch?v=P2o_swwQTNE https://my.hidrive.com/lnk/BX6rJxWBz#file
Market Requirement (L1 requirement) Specification id . This consists of 3 parts :- Artifact Type - XenMRQ Name - Boot_arm64_x86_hw Revision - 1 (This tells that this has not been modified since creation) This is linked to Product requirement ( XenPRQ as Artifact Type ) as a downstream element.
Product Requirement (L2 requirement) Artifact type is XenPRQ This is linked to the following marketing requirements with these spec id This is linked to Software Safety requirement ( XenSSR – Artifact Type) as a downstream element.
Software Safety Requirement (L3 requirement) RST HTML