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>
---
Changes from :-

v1 - 1. No change.

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

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.
-- 
2.25.1

Hi Ayan,

> On 2 Aug 2024, at 11:46, Ayan Kumar Halder <ayan.kumar.halder@amd.com> wrote:
> 
> Added a guide to help write and review requirements. The requirements
> are written to enable safety certification of Xen hypervisor.
> 

Just a reminder if someone commits this serie:
PATCH 2 MUST NO BE COMMITED !!

Would have been a good idea to have it at the end of the serie and this one before.

In any case:

> Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Acked-by: Bertrand Marquis <bertrand.marquis@arm.com>

Cheers
Bertrand

> ---
> Changes from :-
> 
> v1 - 1. No change.
> 
> docs/fusa/reqs/REQUIREMENTS-STYLE | 34 +++++++++++++++++++++++++++++++
> 1 file changed, 34 insertions(+)
> create mode 100644 docs/fusa/reqs/REQUIREMENTS-STYLE
> 
> 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.
> -- 
> 2.25.1
>