When introducing significant changes to the VNF Requirements project or changes that may require discussion.  It recommended that a Proposal be created.  The wiki page will be the place to collaborate and track changes as the proposal is reviewed, revised, and ultimately accepted or rejected.

Please follow these steps when creating a proposal.

1. Copy the Proposal Template and create a page under the Proposals section of the VNF Requirements Wiki.
2. Update the content of your proposal and set the status to Draft
3. Create a JIRA ticket in the VNF Requirements project announcing the ticket, and put a reference to the ticket on the Proposals page
   1. Project: VNF Requirements
   2. Issue Type: Task
   3. Summary: Proposal Review:Title of Proposal
   4. Description: Link to proposal

The VNF Requirements Project maintains repos for  the source documentation of various deliverable:

...

•  ONAP VNF Guidelines

...

•  ONAP VNF Requirements

...

• Mapping VNF use cases and with E2E Release A use cases

...

• ONAP VNF Requirements Test Descriptions 

VNF Guidelines Document Outline - Wenyao Guan

1. Purpose
2. Scope
3. Introduction 
   1. Motivation
   2. Audience
   3. Program and Document structure
4. VNF Context
   1. Business Process Impacts
   2. VNF View of ONAP integration
   3. Evolving towards VNFs
5. VNF Characteristics
   1. VNF Development
   2. ONAP Ready
   3. Virtualization Environment Ready
6. Summary
7. Appendix
   1. Glossary
   2. References
   3. Comparison between VNF Guidelines and ETSI GS NFV-SWAxxx

VNF Requirements Document Outline - Herb Patten

1. Purpose
2. Scope
3. Introduction
   1. Overview of the document, use of the requirements for
4. VNF Development Requirements
   1. VNF Design
   2. VNF Resiliency
   3. VNF Security
   4. VNF Modularity
   5. Devops
5. VNF Modeling Requirements
   1. TOSCA YAML
   2. HEAT
6. Infrastructure Requirements
   1. OpenStack
   2. Azure
7. ONAP Management Requirements
   1. Service Design
   2. VNF On-boarding and package management
   3. Configuration Management
   4. Monitoring & Management
8. Appendix
   1. 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 Subject of the Requirements sentence should be limited to { VNF | VNF Package | VNFC | VDU }

Requirements should be individually numbered. 

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

1. Title
2. Requirement #
3. summary
4. Actors (VNF, Operator, ONAP Platform etc.)
5. Preconditions
6. Operational sequence ( e.g. Message Sequence chart + text explanations) 
7. Post conditions

Test Case Description Template

1. Title
2. Requirement #
3. Use Case #
4. summary
5. ONAP Actors (VNF, Operator, ONAP Platform components etc.)
6. Preconditions ( ONAP, VNF states, test equipment/ data patterns, measurements) 
7. Operational sequence ( e.g. Message Sequence chart + text explanations) 
8. Post conditions (any post processing of the measurements, any cleanup of the ONAP configuration, reset of the test equipment etc.)
9. Test Result decision ( measurement  decision criteria )