...
Naively mapping sections to pulldowns would still have (Red) sections with more than 20 reqts, and would need some further breakdown or summarization. pulldowns with 0 or 1 requirement do not make sense, and should be consolidated. This would suggest ~16 pulldowns with an addition pulldown to consolidate the 4 sections with a single reqt, and some further breakdown/ summarization of the 44 reqts in 7.3.2.1.2. Something like:
| Section # | Num. of reqts | Pulldown titlep |
|---|---|---|
| 7.2.2 | 9 | Resource Description |
| 7.2.3 | 9 | Resource Configuration |
| 7.2.4 | 18 | Resource Control Loop |
| 7.2.5 | 7 | Compute, Network, and Storage Requirements |
| 7.2.6 | 3 | Testing |
| 7.2.7 | 9 | Licensing Requirements |
| 7.3.1 | 20 | Controller Interactions With VNF |
| 7.3.2.1.2 | 11 | Yang Models |
| 7.3.2.1.2 | 6 | Netconf RFCs |
| 7.3.4 | 14 | Chef Standards and Capabilities |
| 7.3.5 | 16 | Ansible Standards and Capabilities |
| 7.4.5.6 | 8 | Addressing and Delivery Protocol |
| 7.4.5.7 | 9 | Asynchronous and Synchronous Data Delivery |
| 7.4.5.8 | 4 | Security |
| 7.4.5.9 | 3 | Bulk Performance Measurement |
| 7.3.3 / 7.4.5.1 / 7.4.5.3 / 7.4.5.5 | 4 | VNF REST APIs / VNF telemetry via standardized interface / JSON / Reporting Frequency |
| 7.3.2.1.2 | 44 | (other- no subheading) ** needs further breakdown/summarization |
Scoring with simple counts of Met/Unmet will not be sufficient:
...
Section 7.4 has MAY or SHOULD requirements which should not have the same weight as a MUST requirement.
VNF Badging should avoid overlap/ duplication with VNF validation based on testing.
...