Use Case Evaluation Process

1. Use case subcommittee discuses new use cases 
2. For every use case, Use case subcommittee describes ONAP Platform capabilities desired for the implementation, produces use case flow diagrams, breaks use case into platform requirements (functional and non-functional), provides its view on the foreseen modules introductions/modifications and suggests potential PNFs / VNFs
3. Use case and Architecture subcommittees jointly review platform requirements required by the new use case and/or by the release
4. Use case subcommittee reaches out to potentially effected projects (Integration team) to get feedback on feasibility and development time estimation.
5. Architecture subcommittee evaluates impact of the platform requirements on the architecture and makes updates as required.
6. Iterate back to step 2.
7. Architecture, Use Case, and Modeling subcommittees discuss and select key platform requirements for the release
8. TSC approves the selected key platform requirements for the release.
9. In case a new modules or a new functionality to existing modules or a new APIs introduction is foreseen, architecture subcommittee defines the new/modified ONAP flows and the interfaces principles, based on the approved platform requirements. 
10. Projects define their extended functionality and their external APIs, following those principles
11. Detailed per-component flows are defined by the projects and projects write their user stories / implement them; Integration team continuously works with Use case subcommittee to accompany the requirements development, review epics/user stories, answer questions, etc. Use case and requirement leads behave as system engineers for the platform requirements through test start date
12. Integration team defines the gating platform requirements based on step 8 and finalizes the PNFs / VNFs selection, with the help of use case subcommittee, architecture subcommittee, PTLs of a different ONAP projects
13. Integration project leads (coordinates) effort to get the gating platform requirements tested, repaired, and verified, and the results are documented
14. Use case subcommittee along with the Integration team decides which new and complete use cases can be showcased following new platform capabilities introduction

 - The defined functional extensions should be as generic as possible to allow re-use of it by additional use cases.

• Use case is defined end to end and can be tested independently while functional requirement should be tested with some specific previously defined use case. Thus  functional requirement definition should include show case to be used.