| Message ID | 20240802094614.1114227-4-ayan.kumar.halder@amd.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Introduce functional safety related documents | expand |
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 >
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.
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