The objective of this process is to formalise and ensure stakeholders understand the process for a new requirement on CPS. 

New Requirement Flowchart

Requirement Submission

The requirement owner/stakeholders shall mail a proposal including the use case driving this requirement. Where possible please include;

1. Use case driving the requirement

2. Relevant study document if any,

3. Corresponding Jira

P.S. If no study yet, an invitation to participate in an ongoing study where possible is advised.

Discussion with Stakeholders

• The proposed new requirement shall be discussed briefly on our Wednesday bi-weekly call, where we have all the right stakeholders (3 architects, POs & CPS PTL&PO)

• During this call, the requirement will be reviewed and either accepted or rejected.

• The POs will coordinate with other stakeholders as necessary from Requirement Acceptance (Step 1 → Delivery Step 6).

Agree Priority

Upon accepting the new requirement as per step 2, the priority of the new work item shall be discussed and rightly documented. At this stage, it is crucial we align our expectations  as this could impact expected in delivery dates. Upon agreeing on the priority, It shall be moved to the right number on the CPS release planning page CPS Release Planning Page.  

Requirement Gathering

CPS PO shall organise a call to gather and clarify the requirement. Here meaningful technical discussion shall be the main agenda of this meeting, including initial analysis into current dependencies and constraints if any. Depending on how large the requirement is, the PO could propose a meeting series to ensure all function and non functional requirement are adequately captured. It's imperatively important we have right technical support from the requirement owners and architect likewise. A sample of what CPS requirement would usually look like CPS Implementation Proposal Template, although flexibility applies in some cases where certain aspect of the template may not required. 

4a Sign-off

• Requirements sign-off is done parallel with requirement gathering. When all functional and non functional requirement are identified & discussed sign of such requirement shall follow as agreed by the stakeholders during the call. 2 aspect that may linger on for a little longer for sign off shall be the Error Scenarios and Characteristics (performance of the feature).

4b AP (Action Point) During sign-off

• Ongoing stakeholder(s) engagement is crucial to finalize any pending requirements sign offs, to prevent development blockers and design deviations, especially when development is already in progress in CPS. To minimize development impact, requirement owners shall be expected to provide timely feedback to AP during the gathering phase to avoid further design impacts in NCMP design.

Development Phase

Post requirements gathering, the development phase shall commence with the functional and non-functional requirement were signed-off with the stakeholders. At this stage CPS shall begin to produce codes, further collaboration needed to drive the development shall be adhoc

Delivery

CPS PO shall align with the stakeholders on delivery. Where applicable demos shall be called with relevant stakeholders. All CPS Demos are recorded CPS Demos and all relevant release document can be found on CPS Release Notes — onap master documentation and this shall align as per CPS release process