Page Status:
| Status | ||||
|---|---|---|---|---|
|
...
| Repo | Description | Deliverable document Title(s) |
|---|---|---|
| /guidelines | This includes objectives and motivations for the VNF Requirements work as well as forward looking, narrative text for use in prototype RFP text. | |
| /requirements | This includes formalized, uniquely numbered requirements that outline the requirements and specifications to which a VNF provider should adhere. Requirements will strive to be discrete and testable where possible, and will follow the guidance of RFC 2119 of requirement key words (e.g. SHOULD, MAY, etc.) for all numbered requirements. | |
| /usecases | Documents VNF specific use cases in support of ONAP E2E use cases illustrating behavior, sequences of operation, variants, error conditions, etc. There may be multiple use cases associated with a single requirementNot every Use Case supported by ONAP will be documented in this section. Instead, key Use Cases that require specific coordination with the VNF can be added here to better describe the VNF's responsibilities as a participant in the Use Case. | |
| /testcases | This expands the use case template structure to supply the additional fields necessary to describe a test scenario. There may be multiple test case descriptions associated with a single use case |
...
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, 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. | ||||
| 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 |
|
Use Case Standards
The VNF and PNF Use Cases define high-level capabilities that guide how end users, the VNF, and the various ONAP components collaborate to support a given use case. 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.
Formal requirements must not be defined in this section, but instead they should be defined in the appropriate requirements section of the document. Those requirements should detail out the any specific management, monitoring, or other capabilities the VNF must provide to support a given use case.
The use case section can be referenced by the requirements to provide additional context and better illustrate the interactions.
At this stage the format for use cases is not rigid, but is should comprise of the following elements:
- A sequence diagram that shows the API-level interactions between any users, ONAP components, and the VNF itself to effectively coordinate the use case. Multiple diagrams can be provided if appropriate.
- NOTE: sequence diagrams can be provided as images or leverage the Sphinx seqdiag capabilities
- A description of the workflow
- An enumerated list of VNF impacts that detail out the specific concerns for the VNF provider and provide references to key requirements
Test Case Standards
TODO