Skip to end of metadata
Go to start of metadata

Usecase Subcommittee Members

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.


Participation

The use case subcommittee is open to all interested participants, and all meetings are open. 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

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.

Process


Meeting logistics

Mailing List

 onap-usecasesub@lists.onap.org 

Meeting Information

Every Monday - 7:00am PDT, 10:00am EDT, 10:00pm China Time

Topics for discussion:

  1. M[x]-GATES, Score Cards, PJM, Status on Milestones
  2. Architecture , Requirements – TSC Bridging
  3. Steering Key Topics for discussion & investigation
  4. Testing – Evolution – Integration/Regression Dev-Test
  5. PTL cameos
  6. Release Content & Next Release Content
  7. Conferences Preparation, Reports, Review & Discussion
  8. Use Case Reports & Status
  9. Cross-U/C Interactions Steering topics

This would be done under assumption that different use cases/functional requirements tracks for covering their detailed work continue.

 While:

  1. M-GATES – Discussion about the M1-2-3-4 gates. Where we are on Score Cards, PJM type discussion and topics, Status on Milestones. Bringing people together related to Use Case and where we are on the Use Cases.
  2. BRIDGING – tie together Architecture , Requirements, and TSC calls. Identifying those key things that come from those other calls back to what is relevant for Use Cases.
  3. STEERING –Steering Key Topics for discussion & investigation. Identifying what we need to be investigating.
  4. TESTING - Testing and Integration/Regression Dev-Test are key topics that span U/Cs. Tying in integration status, and discussion about where testing and integration needs to evolve. For example a discussion of regression testing and how that will be done, or what developments in automation of integration team means to the U/Cs.
  5. PTL CAMEOS – have a “schedule” of PTLs to make cameo appearances at the U/C (Monday) call and then reach out to the U/C owners to ask what they need to discuss w/ the PTLs and reserve 30min (or the whole meeting) to meet with that PTL discussion U/C topics.
  6. RELEASE CONTENT – the Release and Next Release Content, USE CASES/FUNCTIONAL REQUIREMENTS WISE. What potential new U/Cs are we thinking about for R5 El Alto for example.
  7. CONFERENCES – Discussion about Preparation and review of topics and presentations and logistics. Then after the conference discussion of Reports, Readouts, Review, and Retrospectives.
  8. U/C STATUS – Use Case Reports & Status
  9. Cross U/C INTERACTIONS and INTERDEPENDENCIES – share the Cross-U/C Interactions finding, and create Steering topics for further investigation by the U/C teams or U/C realization calls.

Use Case Subcommittee Meeting Minutes

IRC

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/655429955

Or iPhone one-tap (US Toll): +16465588656,655429955# or +14086380968,655429955#

Or Telephone:
Dial: +1 646 558 8656 (US Toll) or +1 408 638 0968 (US Toll)
Meeting ID: 655 429 955

International Numbers

 https://zoom.us/zoomconference?m=CqsAwHx4CSyRanCfPHKBvf6Vslgcsn86


  • No labels

5 Comments

  1. TSC subcommittee purpose:

    The use case subcommittee is responsible for developing use cases required for ONAP releases. This includes basic flows, VNFs and 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.

  2. Refining the VNF Requirements to test cases is likely to generate use cases focused on VNF Requirements  that would need to be aligned with the ETE  platform use cases.

  3. Steven: I revised Use case subcommittee definition to include this.

  4. Looks like a sensible refinement of the process. 

  5. Are the committee meetings recorded? The minutes are too high level if you're trying to gauge the current implementation status of a specific use case.