[xen staging] docs: fusa: reqs: Added a requirements writing style guide

[patchbot@xxxxxxx]

commit d61248b0fa2cdfc0be1d806c43d1b211a72b5d49
Author:     Ayan Kumar Halder <ayan.kumar.halder@xxxxxxx>
AuthorDate: Tue Aug 6 17:31:56 2024 +0100
Commit:     Stefano Stabellini <stefano.stabellini@xxxxxxx>
CommitDate: Fri Aug 9 16:58:04 2024 -0700

    docs: fusa: reqs: Added a requirements writing style guide
    
    Added a guide to help write and review requirements. The requirements
    are written to enable safety certification of Xen hypervisor.
    
    Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@xxxxxxx>
    Acked-by: Bertrand Marquis <bertrand.marquis@xxxxxxx>
---
 docs/fusa/reqs/REQUIREMENTS-STYLE | 34 ++++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/docs/fusa/reqs/REQUIREMENTS-STYLE 
b/docs/fusa/reqs/REQUIREMENTS-STYLE
new file mode 100644
index 0000000000..cd2408b9f2
--- /dev/null
+++ b/docs/fusa/reqs/REQUIREMENTS-STYLE
@@ -0,0 +1,34 @@
+Requirements writing style for the Xen Hypervisor
+=================================================
+
+The requirements writing style described below is the style used for writing 
the
+requirements of the Xen hypervisor to enable functional safety certification.
+
+The requirements writing style is inspired from the ANSI/IEEE guide to Software
+Requirements Standard. Specifically, the requirements should satisfy the
+following validation checklist.
+(Source - 
https://www.nasa.gov/reference/appendix-c-how-to-write-a-good-requirement)
+
+Clarity -
+The requirements should be clear, unambiguous, consise and simple. Each
+requirement should express a single thought. Each requirement stated should 
have
+a single interpretation.
+
+Consistency -
+Any requirement shouldn't contradict with any other requirement. The 
requirements
+should be categorized correctly (the categories have been explained in the
+README). The tone of each requirement should be definitive (ie "Xen shall ..."
+should be present in each requirement).
+
+Traceability -
+Any market requirement should be linked to the product requirement/s and
+vice versa. Any product requirement should be linked to the design 
requirement/s
+and vice versa. Full bi-directional traceability should be maintained between
+market, product and design requirements.
+
+Correctness -
+The requirements should be feasible and technically correct (at the time of
+writing). However, it is not expected that the requirements will be kept upto
+date with the code.
+
+The requirements follow the same license and line length as the code.
--
generated by git-patchbot for /home/xen/git/xen.git#staging