...
VNF Requirements are the foundation of the project and as such have the most stringent content standards. The requirements form the basis of the specifications that a VNF provider must adhere to in order to successfully deploy and operate a VNF on the ONAP platform. The goal of this section is to provide independent, enumerated, and generally verifable verifiable requirements for which a VNF should adhere to be managed on the ONAP platform and adhere to ONAP's architectural principlesprinciples.
As these are requirements, they should follow standard expectations for what constitutes a good requirement:
- Unambiguous - It should have a single, objective interpretation. It should avoid subjective terms that would be open for misinterpretation. It should also include sufficient text or references to ensure how it should comply with a directive where applicable.
- Concise - An individual requirement should be specific about a single aspect, and strive to be as short as possible without sacrificing clarity. In general, a requirement should strive to be a single sentence where possible.
- Verifiable - Compliance with the requirement should be possible with some form of test, inspection, or demonstration.
- Consistent - Requirements must not introduce conflicting or contradictory guidance
- Feasible - The requirement must be reasonably implementable by existing technology and practices. Forward looking guidance and aspirational goals are best suited for the Guidelines section of the document.
- Observable - The requirement should lend itself to externally, observable behavior where ever possible. Guidance on internal implementation of meeting specific non-functional requirements should likely be included in guidance or as supplementary text.
Requirements that meet these criteria will have a specific format within the requirements document.
Here is an example requirement statement:
R-18725 - The VNF MUST handle the restart of a single VNFC instance without requiring all VNFC instances to be restarted.
Here are the additional standards the requirement must adhere to in the context of this project:
- The requirement must be uniquely numbered (ex R-XXXXX). Please refer to VNFRQTS How to Contribute for more information on how requirement numbers are assigned.
- The requirement must use RFC 2119 keywords (MUST | MUST NOT | SHOULD | SHOULD NOT | MAY), and these keywords must be in uppercase and in bold. In RST, bold is achieved by wrapping the text in double asterisks (ex: **MUST**)
- The requirement should start off with the subject of the requirement and refer to one of the following:
VNF
VNFC
VNF Provider
VNF HEAT Orchestration Template
VNF Package
PNF
xNF (NOTE: xNF is a requirement that applies to both PNF and VNFs)
- The requirement should include the metadata as defined in
The Subject of the Requirements sentence should be limited to { VNF | VNF Package | VNFC | VDU } – Does not match Table values
The .rst formatting of the requirements should be such that the documentation can extract a complete set of requirements as a table in an appendix.
This project makes use of an Sphinx extension called sphinxcontrib-needs to enable a number of useful features both internal to the project and enable sharing of structured data/information between projects.
...