Topics

Transition from Use case to Requirements subcommittee


Alla Goldner
 

Hi all,

 

As we also extensively discussed during the f2f meeting in Prague, and following the TSC voting, we are transforming from the existing working model to the new working model, where we stop bringing use cases to the community, but rather bringing requirements, both functional and non-functional. Thus, Use case subcommittee is transformed to become Requirements subcommittee. This way:

 

  1. Requirements subcommittee will no longer deal with functional split between a different ONAP modules, architectural implementation etc. It ewill rather deal with high level requirements like:
    1. ONAP Guiling Release shall support 5GC network slicing

The job if a detailed architecture split will be done under Architecture subcommittee by working with a different projects. I would assume the Use cases implementation call responsibility also moves there, and should be reworked as well, mostly for a different requirements interactions

  1. Close-loop and security requirements will still be handled by a separate subcommittees
  2. Non-functional (platform/S3P) requirements will also be handled by the Requirements subcommittee
  3. We will have bi-weekly meetings, per need (i.e. if there is input to be discussed)
  4. There will be a task force reviewing those inputs and deciding on the next steps e.g. consult with EUAG, moce to architecture subcommittee etc.

 

I created a new wiki page and a several pages under this for the future work https://wiki.onap.org/display/DW/Requirements+subcommittee

Please bring your comments and suggestions and please ask me any questions you may have.

It would also be beneficial if you include business drivers description https://wiki.onap.org/display/DW/Template+to+be+fulfilled+per+each+requirement per requirement you bring, it will simplify the process.

I suggest we now strongly concentrate on work for Guilin, so please fill in the wiki page for your corresponding Guiling requirements to move it further.

It would be the best if during the meeting we review the requirements you already brought, so we can push them forward.

The first Requirements subcommittee meeting will be on January 27 during the regular Use case subcommittee meeting hours.

 

Best Regards, Alla

 

This email and the information contained herein is proprietary and confidential and subject to the Amdocs Email Terms of Service, which you may review at https://www.amdocs.com/about/email-terms-of-service


Alla Goldner
 

Hi all,

 

A reminder – please start filling in your proposed requirements for Guilin under https://wiki.onap.org/display/DW/Requirements+subcommittee

Please also let me know if there is anything ready which can be presented next week.

 

Best Regards, Alla

 

From: onap-usecasesub@... <onap-usecasesub@...> On Behalf Of Alla Goldner
Sent: Wednesday, January 15, 2020 4:30 PM
To: Onap-usecasesub@...
Cc: onap-tsc@...; onap-discuss@...
Subject: [Onap-usecasesub] Transition from Use case to Requirements subcommittee

 

Hi all,

 

As we also extensively discussed during the f2f meeting in Prague, and following the TSC voting, we are transforming from the existing working model to the new working model, where we stop bringing use cases to the community, but rather bringing requirements, both functional and non-functional. Thus, Use case subcommittee is transformed to become Requirements subcommittee. This way:

 

  1. Requirements subcommittee will no longer deal with functional split between a different ONAP modules, architectural implementation etc. It ewill rather deal with high level requirements like:
    1. ONAP Guiling Release shall support 5GC network slicing

The job if a detailed architecture split will be done under Architecture subcommittee by working with a different projects. I would assume the Use cases implementation call responsibility also moves there, and should be reworked as well, mostly for a different requirements interactions

  1. Close-loop and security requirements will still be handled by a separate subcommittees
  2. Non-functional (platform/S3P) requirements will also be handled by the Requirements subcommittee
  3. We will have bi-weekly meetings, per need (i.e. if there is input to be discussed)
  4. There will be a task force reviewing those inputs and deciding on the next steps e.g. consult with EUAG, moce to architecture subcommittee etc.

 

I created a new wiki page and a several pages under this for the future work https://wiki.onap.org/display/DW/Requirements+subcommittee

Please bring your comments and suggestions and please ask me any questions you may have.

It would also be beneficial if you include business drivers description https://wiki.onap.org/display/DW/Template+to+be+fulfilled+per+each+requirement per requirement you bring, it will simplify the process.

I suggest we now strongly concentrate on work for Guilin, so please fill in the wiki page for your corresponding Guiling requirements to move it further.

It would be the best if during the meeting we review the requirements you already brought, so we can push them forward.

The first Requirements subcommittee meeting will be on January 27 during the regular Use case subcommittee meeting hours.

 

Best Regards, Alla

 

This email and the information contained herein is proprietary and confidential and subject to the Amdocs Email Terms of Service, which you may review at https://www.amdocs.com/about/email-terms-of-service

This email and the information contained herein is proprietary and confidential and subject to the Amdocs Email Terms of Service, which you may review at https://www.amdocs.com/about/email-terms-of-service