...
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 onboard, deploy, and operate a VNF on the ONAP platform. The goal of this section is to provide independent, enumerated, and generally verifiable requirements for to which a VNF should adhere to be managed on the ONAP platform and adhere to meet ONAP's architectural principles.
As these are requirements, they should follow standard general expectations for what constitutes a good requirement:
...
Requirements that meet these criteria will have a specific format within the requirements document . which will consist of a requirement statement and the metadata.
Requirement Statement Standards
Here is an example requirement statement:
...
- 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 Table 2: Requirement Metadata
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.
These objectives are as follows:
- apply only to a single aspect of its intended requirements target, and not combine multiple independent statements into a single requirement.
Requirement Metadata Standards
In addition to the statement itself, this project captures assorted metadata about the requirement about the requirement for a variety of purposes:
- Supporting Associate standard, structured metadata with each requirement to aid in a variety of use cases such as dependency tracking, searching, filtering, and reporting.
- Export Exporting requirements in a machine-readable format for use by other projects such as the VNF Validation Project.
- Generate Generating different formats and outputs without duplicating requirement content (ex: appendices, tables, CSV files, etc.)
- Provide Providing traceability within the document between requirements, test cases, and other items within the documents.
Approach
This project makes use of an Sphinx extension called sphinxcontrib-needs project to in support of these objectives. Requirements will still be maintained in the reStructuredText file, but they will be shifted to structured directives using formatted according to work with the sphinxcontrib-needs extension. This extension provides a way to meet each of the needs above.
Here is an example of a requirement after the conversion:that adheres to the standards
Requirement Example
|
These requirement definitions can be processed by the sphinxcontrib-needs extension and used in a variety of ways.
...
...
Metadata Standards
The following table outlines the proposed standard metadata elements that will be associated with the requirements. This list may change over time.
...
Field Name | Required vs. Optional | Data Type | Valid Values/Format | Notes | ||||
|---|---|---|---|---|---|---|---|---|
| target | Required | String | VNF, VNFC, VNF PROVIDER, VNF HEAT ORCHESTRATION TEMPLATE, VNF PACKAGE, PNF, XNF | The component to which the requirement applies. | ||||
| keyword | Required | String | MUST, MUST NOT, SHOULD, SHOULD NOT, MAY | The RFC 2119 keyword for the requirement | ||||
| introduced | Optional | String | lower case release name (ex: bejing, casablanca) | The release the requirement was initially introduced. New requirements should always have this. | ||||
| updated | Optional | String | lower case release name | The release the requirement was last modified. Any updated requirements going forward should have this. | ||||
| impacts | Optional | List of String | Comma separated list of ONAP components (ex: so, sdc) | The various ONAP components that need to be aware of any changes to the requirement | ||||
| validation_mode | Optional | String | static, stand_alone, in_service | How the requirement is validated: static - validated by statically inspecting the VNF package data stand_alone - validated by running tests against the VNF itself in_service - validated in the context of a full or partial ONAP deployment | ||||
| validated_by | Optional | List of String | Comma separated list: vvp, vnfsdk, sdc | Projects that implement validations of this requirement. | ||||
| test_case | Optional | RST Link |
| |||||
| notes | Optional | String | Free form text | Short notes about the requirement |
ONAP/VNFRQTS VNF Requirements Discussion
Requirements should be single sentences using an RFC 2119 keyword { MUST | MUST NOT | SHOULD | SHOULD NOT | MAY }. The keyword should be bold.
The Subject of the Requirements sentence should be limited to { VNF | VNF Package | VNFC | VDU } – Does not match Table values
Requirements should be individually numbered. Format initially will be R-xxxxx
Draft example of the .rst format for requirements:
* R-xxxxx VNFs **MUST** meet their own resiliency goals and not rely on the Network Cloud....