Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

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

New Requirement Flowchart


1Requirement Submission:

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

  1. Relevant study document if any,
  2. Corresponding Jira

P.S. If no study yet, an invitation to participate in an ongoing study where possible shall be 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, PO & CPS PTL&PO) at this stage we accept or reject the requirement after review. The PO shall also have the responsibility of proposing additional calls as required. 


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. 


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).

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 



  • No labels