diff mbox series

[v3,2/3] docs: fusa: reqs: Added a requirements writing style guide

Message ID 20240806163157.2850636-3-ayan.kumar.halder@amd.com (mailing list archive)
State New
Headers show
Series Introduce functional safety related documents | expand

Commit Message

Ayan Kumar Halder Aug. 6, 2024, 4:31 p.m. UTC
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@amd.com>
Acked-by: Bertrand Marquis <bertrand.marquis@arm.com>
---
Changes from -

v1, v2 - No changes.

 docs/fusa/reqs/REQUIREMENTS-STYLE | 34 +++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)
 create mode 100644 docs/fusa/reqs/REQUIREMENTS-STYLE
diff mbox series

Patch

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.