Presentation on theme: "PN UNC Workgroup 20/9/11 Requirements Definition to Delivery."— Presentation transcript:
PN UNC Workgroup 20/9/11 Requirements Definition to Delivery
Action from previous meeting Action NEX08/03: Xoserve to assess what was the most appropriate way to progress/bring in Modification 0380. Update to be provided at 20/09/11 meeting.
UNCERTAINTY Requirements to Delivery Project Nexus launch CurrentStart design Time Critical date (?) Able to defer? Need to accelerate? Lead time – ability to concertina? Reduce uncertainty UNC discussions SMIP ? Technical, efficiency and business requirements drivers
Requirements definition progress Excellent engagement – ‘requirements register’ being worked through Some aspects outside UNC – e.g. some iGT matters, industry data management Some matters stalled pending understanding of scope of SMIP – subsequently re-started Some key UNC industry requirements considered in detail – industry definition drawing to conclusion – year end target
Moving to the next Phase Preparing for economic, efficient, next phase with longevity Pre-requisites: –Defined requirements, expected outcomes and benefits –Priorities and dependencies Analysis of industry requirements Consider solution options Develop a delivery plan –reflecting the volume and nature of change –ensuring continuity of services Gain customer commitment Implemented UNC modification(s) [maybe in parallel with above]
Requirements Definition Industry Topic Development Industry Business rule definition Functional Requirements Xoserve Functional requirements Non-Functional Requirements Requirements Defined & Signed Off The development of a delivery plan may require iterations to fully work through the functional and non-functional requirements.
Mod 380 is part of a ‘family’: demand attribution, allocation and reconciliation A ‘family’ of processes and objectives: Reduced reliance on allocation –Allow for more DM on back of AMR and Smart Increased accuracy of NDM allocation –AQ representative of more recent usage (mod 380) –Introduce more EUCs – potentially support for modest change Reduced risk of AQ ‘gaming’ –Remove AQ amendments –Oblige shippers to submit all readings? NDM reconciliation attributable to individual sites –Meter point reconciliation
Typical medium/ Large scale programme Detailed Requirements Analysis & Design Application Build Infrastructure Build Testing & Trials ImplementationBusiness case, sourcing, contracting, mobilisation 3-6 months 3-5 months 3-6 months 6-9 months 3months 2months Programme life 20 – 30 months (not including lapsed time for Governance, procurement & contracting activities
Phasing and prioritisation - TBA 2012 2013 2014 2015 2016/17 2020 DCC Day 1 DCC evolution DCC Foundation In-flight project delivery UKL sustaining actions Smart roll out support DCC Access Control Exception & error Handling Dumb to Smart Meter Exchanges Increased Meter Read capacity Rolling AQ EU Changes DCC evolution Improved Energy Allocation products Meter Point Reconciliation UKL sustaining Nexus Topics European driven change ?
Next Process Check Points PNAG – 17/10/11 –Transition from support and guidance re approach to Requirements Definition? Shipper seminar – 3/11/11 Solution options and plan – likely Q2 2012