Table of Contents
...
The intent of the VNF Requirement and Guidelines project is to inform VNF providers of the standards, specifications, and guidlines to which they should adhere when targeting the ONAP platform. These requirements and guidelines will support the ONAP Architecture Principles, and ensure a consistent experience for VNF providers across the VNF lifecycle. See the VNF Requirements Charter for more information.
...
- 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 VNFC
PNF
- VNF or PNF
- VNF Provider
- PNF Provider
- VNF or PNF Provider
- VNF HEAT Orchestration TemplateVNF 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.
...
Here is an example of a requirement that adheres to the standards.
You may use the VNFRQTS Requirement Generation Tool to generate properly RST formatted requirements with unique ID numbers.
Requirement Example
|
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. On a new requirement, this attribute can be left off and the tox -e docs or check.py script generate and ID and populate this field. | |||||||||||||||||||||
| target | Required | String | VNF | VNF, VNFC, VNF PROVIDER, VNF HEAT ORCHESTRATION TEMPLATE, VNF PACKAGE, PNF, VNF or PNF | 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. When adding a new requirement, this can be left off and the tox -e docs or check.py script will add this for you. | |||||||||||||||||||||
| 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 IDsThis 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 |
|
Use Case Standards
The use case section of the document affords a way to provide a VNF Provider a VNF-centric view of certain use cases. It is not required that every use case supported by ONAP be documented in this section. Instead, key use cases that require discrete actions and coordination with the VNF can be described here to provide a clearer understanding of potentially multi-step complex interactions.
...