Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • MO PROJECT PROPOSALS

    • USE CASE TEAMS - The Use Case Teams prepare their proposals.
      • #1: BUSINESS DRIVER TEMPLATE - The Use Case Teams should develop their business driver template and consider their purpose and business impact for their use case. This would detail the executive summary, business impact, business markets, financial impacts and management and strategy. The template for the business driver case can be found here: Business Driver Template for Use Cases
      • #2: REQUIREMENTS SUB-COMMITTEE - Develop their proposals for the release which focus on defining their business imperatives.  When ready, the Team needs to present their business drivers and requirements to the requirements sub-committee. The Use Case owner would propose and select the requirements that would be worked on in that release. The requirements Sub-Committee can evaluate and identify cross-interactions between proposals. The requirements S/C can make prioritization recommendations to the TSC. The TSC (with EUAG input) can then make a decision to adopt or alter the prioritization recommendations. The presentation are given to the Requirements Sub-committee: Requirements subcommittee
      • #3: REQUIREMENTS PROPOSALS - After making a presentation to the Requirements sub-committee. Their requirements would then be put into the release proposed functional requirements page. An example for Release 7 (GuiLin) is at this wiki: Guilin release - functional requirements proposed list
      • #4: USE CASE DEFINITIONS - The team can then use the Use Case Template to fill out more details about their Use Case. Note: (see above), again, a Use Case is a comprised of a set of Requirements. The use Case Template can be found here: Use Case Tracking Template
      • #5: INTENTION TO PARTICIPATE - Teams can indicate their corporate intention to participate
      • #6: RELEASE TRACKING - Each release has a release tracking page. Wiki can be found here: Release Planning . You will need to clone REQ-1 (see link below)
      • #7: PROJECT SUBMISSION, PROPOSAL, PLANNING - The TSC coordinates the project submission, proposal and planning. A project submission, the intention to participate is announced. The TSC reviews and provides its disposition on all submitted projects proposal. In Project Planning closure, the submissions from all of the new projects have been submitted in wiki their Release Planning materials. These are also tracked on the Release Planning page.
      • #8: MODEL PLANNING - If you have model impact add to the model planning page ONAP R7 Modeling High Level Requirements
  • WIKI LINKS References for the Use Case Teams at M0

    WIKI LINKS REFERENCE AT M0
    M0DescriptionWiki Link
    1Business Driver TemplateBusiness Driver Template for Use Cases
    2Requirements S/CRequirements subcommittee
    3Functional Requirements ProposalsGuilin release - functional requirements proposed list
    3aRequirements TemplateTemplate to be fulfilled per each requirement
    4Use Case Tracking TemplateUse Case Tracking Template
    6Release Tracking page

    Release Planning (R6)

    https://wiki.onap.org/display/DW/Guilin+Release+Requirements (R7)

    ModModeling Release Planning Page

    ONAP R7 Modeling High Level Requirements

    Modeling Current Activity Status

    ModGeneric Information Element Template

    If you think you have modeling impact fill out the following template and include in your project Wiki Page:

    Generic Information Element Template

    ArcArchitecture Reference ArchitectureArchitecture
    ArcArchitecture S/C presentation Template

    R7 Guilin Architecture Review (template) - functional requirements

    Project Architectural Review Requirements and Process (Draft)

    REQ1Requirement Template

    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keyREQ-1

    INSTRUCTIONS: Documenting Release Requirements in JIRA

    • Project component (A&AI, SDNC SO etc) impacts, and test only impacts
    • Create an user story per impacted project
    • Which companies will develop and test each requirement per component?
    • How many developers per component?
    • Date for your Architecture sub-committee Review? and LINK.
    • Date of Requirements Review

    (REQ-1 TEMPLATE):

    Project (ONAP Component) IMPACT: TO/C
    * Impact Type: TO/C (Test-only/Code)
    * Companies Supporting: xyz
    * Resources: xyz
    * NFR Support: xyz (support for non-functional requirement)

    Story

    Jira

    Creating STORY JirasCreate a STORY Jira per impacted Project


  • Modeling team - At MO the Modeling S/C does MODEL PLANNING. The planning develops into “High Level Info-model Requirements”. These High level info-model requirements fall into 3 categories:
    • #1: NEW USE CASES - items from the expected Requirements/Use Cases in the release (Scope of modeling, continuing, introducing, standards updates). The Use Case Teams should engage the modeling team to propose new requirements into their release planning page. An example of the Modeling S/C planning page for R6 is here: ONAP R7 Modeling High Level Requirements
    • #2: REFINING EXISTING MODEL - Refining Existing info-model that has not made it to the information model; Use case teams to be aware of these changes to the model.
    • #3: EXPERIMENTAL WORK - At this stage, the Use Case/Requirements teams may not be entirely sure of modeling impacts; They should still schedule into the Modeling Roadmap (as Experimental).

...