Meeting Minutes

Or Telephone:
Dial: +1 646 558 8656 (US Toll) or +1 408 638 0968 (US Toll)
Meeting ID: 655 429 955
International numbers available: https://zoom.us/zoomconference?m=CqsAwHx4CSyRanCfPHKBvf6Vslgcsn86

Use case subcommittee mailing list

onap-usecasesub@lists.onap.org

Participating in UC meetings

Use case subcommittee is contribution-driven
- People can sign up for slots on the agenda
- We will request people to develop proposals/presentations to discuss during meetings and via email

TSC subcommittee purpose:

The use case subcommittee is responsible for developing use cases required for ONAP releases. This includes basic flows, VNFs and requirements, including alignment with use cases focused on VNF Requirements, along with a set of required guidelines for ONAP. It will be used as an input for developing functional architecture and detailed software architecture per release.

The use case subcommittee will not make decisions regarding Release’s functional architecture or internal functioning of projects. It is a support group for the TSC Chair and the TSC

The use case subcommittee is advisory by nature, and not authoritative. It may provide advice to projects and to the TSC and TSC’s Architecture subcommittee.

The use case subcommittee operates on a rough consensus basis. If the subcommittee is unable to reach consensus on what use case to offer, the subcommittee will refer the matter to the TSC.

TSC subcommittee expected deliverables:

The use case subcommittee will develop and maintain use case descriptions and any related explanatory material for ONAP releases.

Midway through a release, the use case subcommittee will provide its proposal for the use cases to be supported for the next release.

TSC subcommittee starting participants:

The use case subcommittee is open to all interested participants, and meetings are open.

Use case subcommittee flow:

1. Use case subcommittee discuses new use cases

2. Use case subcommittee produces use case flow diagrams, provides its view on the foreseen modules introductions/modifications and suggests potential PNFs / VNFs

3. Use case subcommittee gets feedback from the potentially effected projects including integration team on feasibility

4. Iterate back to 2

5. TSC approves the use case

6. 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 use cases

7. Projects define their extended functionality and their external APIs, following those principles.

8. 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 use case development, review epics/user stories, answer questions, etc. Use case subcommittee behaves as system engineers for the use case through test start date

9. Integration team defines the gating use case 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

10. TSC approves the gating use case

11. Integration project leads (coordinates) effort to get the gating use case tested, repaired, and verified, and the results are documented.

Usecase subcommittee