The VNF Requirements Project maintains repos for the source documentation of various deliverable:
Repo | Published for | Description | EPIC supported | Deliverable document Title(s) |
---|---|---|---|---|
/guidelines | External audience | This includes objectives and motivations for the VNF Requirements work as well as aspirational, forward looking, narrative text for use in prototype RFP text. | VNFRQTS-6 |
|
/requirements | External Audience | This is narrative text for use in prototype RFP text. | VNFRQTS-6 |
|
/epics | Internal Audience | Formalized requirements descriptions e.g. "As a ROLE I need SOMETHING so that SOME PURPOSE IS REALIZED" | see Project Charter | |
/usecases | Internal audience | This is a template structure providing a context for specific requirements. This illustrates behavior, sequences of operation, variants, error conditions, etc. There may be multiple use cases associated with a single requirement. Documents VNF specific use cases in support of ONAP E2E use cases. | see Project Charter |
|
/testcases | Internal Audience | 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 | VNFRQTS-8 |
|
VNF Guidelines Document Outline - Wenyao Guan
- Purpose
- Scope
- Introduction
- Motivation
- Audience
- Program and Document structure
- VNF Context
- Business Process Impacts
- VNF View of ONAP integration
- Evolving towards VNFs
- VNF Characteristics
- VNF Development
- ONAP Ready
- Virtualization Environment Ready
- Summary
- Appendix
- Glossary
- References
- Comparison between VNF Guidelines and ETSI GS NFV-SWAxxx
VNF Requirements Document Outline - Herb Patten
- Purpose
- Scope
- Introduction
- Overview of the document, use of the requirements for
- VNF Development Requirements
- VNF Design
- VNF Resiliency
- VNF Security
- VNF Modularity
- Devops
- VNF Modeling Requirements
- TOSCA YAML
- HEAT
- Infrastructure Requirements
- OpenStack
- Azure
- ONAP Management Requirements
- Service Design
- VNF On-boarding and package management
- Configuration Management
- Monitoring & Management
- Appendix
- Data Record Formats
Seed Document mapping for VNFRQTS Deliverables
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 }
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.
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.
EPIC statements
The Project Charter also mentions the development of "EPIC statements". The ONAP JIRA wiki uses the term User Story Syntax for the same structure:
see discussion in ONAP/VNFRQTS VNF Requirement Discussion
EPIC statements a standalone deliverable beyond the JIRA wiki are not going to be produced in the Amsterdam release.
Use of EPIC Statements/ Suer Story Syntax as context in the VNFRQTS Requrimenst deliverable is optional in the Amsterdam release. ie it may be used to provide some explanatory context for the requirements statements, but it is not systematcially applied in the Amsterdam release.
Use Case Template
For each use case adopt a standardized format
- Title
- Requirement #
- summary
- Actors (VNF, Operator, ONAP Platform etc.)
- Preconditions
- Operational sequence ( e.g. Message Sequence chart + text explanations)
- Post conditions
Test Case Description Template
- Title
- Requirement #
- Use Case #
- summary
- ONAP Actors (VNF, Operator, ONAP Platform components etc.)
- Preconditions ( ONAP, VNF states, test equipment/ data patterns, measurements)
- Operational sequence ( e.g. Message Sequence chart + text explanations)
- Post conditions (any post processing of the measurements, any cleanup of the ONAP configuration, reset of the test equipment etc.)
- Test Result decision ( measurement decision criteria )