Table of Contents
...
- 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 generally start off with the subject of the requirement and refer to one of the following, and then further refine from there
VNF
PNF
- VNF or PNF
- VNF Provider
- PNF Provider
- VNF or PNF Provider
- VNF Heat Package
- VNF CSAR Package
- PNF CSAR Package
- VNF or PNF Package
- VNF Documentation Package
- PNF Documentation Package
- VNF or PNF Documentation Package
- Example: The VNF Heat Package's base module **MUST** contain...
- The requirement should apply only to a single aspect of its intended requirements target, and not combine multiple independent statements into a single requirement.
...
The following table outlines the proposed standard metadata elements that will be associated with the requirements. This list may change over time.
Table 2: Requirement MetadataAnchor requirement_metadata requirement_metadata
Field Name | Required vs. Optional | Data Type | Valid Values/Format | Notes | ||||
|---|---|---|---|---|---|---|---|---|
| id | Required | String | R-##### | The unique requirement ID for this requirement. See VNFRQTS How to Contribute for more details. | ||||
| target | Required | String | VNF, PNF, VNF OR PNF, VNF|PNF|VNF or PNF PROVIDER, VNF HEAT PACKAGE, VNF|PNF|VNF or PNF CSAR PACKAGE, VNF|PNF|VNF or PNF DOCUMENTATION PACKAGE | 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. | ||||
| links | Optional | List of String | Comma or semi-colon separated list of requirement IDs | This is a list of IDs that this requirement is dependent on. When the HTML documentation is produced, linkages will be provided between the requirements. | ||||
| test_case | Optional | RST Link |
| |||||
| notes | Optional | String | Free form text |
|
...