Business Requirements Specification Many to Many Substitution Requests Document Version: 1.1 Date Created: 3/13/2014 Revision History Date Version Description 11/18/2013 1.0 Creation of Document 3/13/2014 1.1 Reworded BRQ032 Removed “actuals” from BRQ022 BRQ022/23/24/26/27: Removed Settlements from “impacted systems” BRQ003: Added “same rules as initial substitutions apply” Removed BRQ009 (requirement not pertinent to external participants) Removed BRQ012 (this requirement is already defined in other requirements such as BRQ033) Reworded BRQ014 Updated “requirement type” in BRQ018 & BRQ019 Owner: Owens; Andrew Program Office Copyright 2012 California ISO Doc ID: GNFDMDEHU6BB-46-53 Page 1 of 11 Template Version: 2.9 Document Version: 1.1 Technology Many to Many Substitution Requests Business Requirements Specification Date Created: 3/13/2014 Disclaimer All information contained in this draft Business Requirements Specification (BRS) as provided by the California Independent System Operator Corporation (ISO) is prepared for discussion and information purposes only. The draft BRS is provided “as is” without representation or warranty of any kind, including, without limitation, a representation or warranty as to accuracy, completeness, or appropriateness for any particular purpose. The draft BRS shall be revised as the development and review of the business requirements progresses. The ISO assumes no responsibility for the consequences of any errors or omissions. The ISO may revise or withdraw all or part of this information at any time at its discretion without notice. Owner: Owens; Andrew Doc ID: GNFDMDEHU6BB-46-53 Copyright 2012 California ISO Program Office Page 2 of 11 Template Version: 2.9 Document Version: 1.1 Technology Many to Many Substitution Requests Business Requirements Specification Date Created: 3/13/2014 Table of Contents 1. INTRODUCTION ........................................................................................................................................................................ 4 1.1 2. DETAILS OF BUSINESS NEED/PROBLEM .......................................................................................................................... 5 2.1 3. PURPOSE .................................................................................................................................................................................... 4 DESCRIPTION.............................................................................................................................................................................. 5 BUSINESS PROCESS IMPACTS .............................................................................................................................................. 5 3.1 HIGH LEVEL BUSINESS PROCESS................................................................................................................................................ 5 3.1.1 4. Description ...................................................................................................................................................................... 5 3.2 DESCRIPTION.............................................................................................................................................................................. 5 3.3 JUSTIFICATION ........................................................................................................................................................................... 5 BUSINESS REQUIREMENTS ................................................................................................................................................... 6 4.1 BUSINESS PROCESS: MANAGE RELIABILITY REQUIREMENTS ..................................................................................................... 6 4.1.1 4.2 Business Requirements .................................................................................................................................................... 6 BUSINESS PROCESS: OUTAGE DATA PROCESSING .................................................................................................................... 10 4.2.1 Business Requirements .................................................................................................................................................. 10 Owner: Owens; Andrew Doc ID: GNFDMDEHU6BB-46-53 Copyright 2012 California ISO Program Office Page 3 of 11 Template Version: 2.9 Document Version: 1.1 Technology Many to Many Substitution Requests Business Requirements Specification Date Created: 3/13/2014 1. Introduction 1.1 Purpose The purpose of this document is to capture and record a description of what the Users and Business Stakeholders of the project wish to obtain by providing high-level business requirements. This document establishes the basis for the agreement between the initiators and implementers of the project. The information in this document serves as input to determining the scope of Information Systems projects and to all Business Process Modeling and System Requirements Specifications efforts. These requirements will serve as the initial set of business unit requirements for the appropriate software application/systems development effort. It is understood that additional requirements and systems analysis may produce “To Be” Business Process Models, System Requirements Specifications, and Use Cases to serve as the set of requirements documents used by the development teams to buy, modify, or build the necessary software and hardware systems. The Business Unit(s) involved in the project will have an opportunity to review and approve all requirements documentation produced. Market Participants desire the capability to request many to many substitutions, using one substitute unit to cover multiple forced outages thus making available the Non-RA capacity to cover impact of other outages. Currently, ISO systems do not permit this because of a system limitation which was not addressed during SCP I and II. Owner: Owens; Andrew Doc ID: GNFDMDEHU6BB-46-53 Copyright 2012 California ISO Program Office Page 4 of 11 Template Version: 2.9 Document Version: 1.1 Technology Many to Many Substitution Requests Business Requirements Specification Date Created: 3/13/2014 2. Details of Business Need/Problem 2.1 Description Business Opportunity/Problem Statement: What: Market Participants desire the capability to request many to many substitutions, using one substitute unit to cover multiple forced outages thus making use of Non-RA capacity to cover impact of other outages. Problem existed between 2009-current This was originally de-scoped from SCP I & SCP II due to project timing. When: Why do we have this opportunity/problem: Who does this It impacts Market Participants wishing to use Non-RA Capacity to cover opportunity/problem RA capacity that is on outage. impact: 3. Business Process Impacts 3.1 High Level Business Process 3.1.1 Description Implementing the Many to Many Substitution initiative will impact the following existing business processes: Manage Reliability Requirements 3.2 Description Specific impacts on these business processes that the Many to Many Substitution Requests team has identified to date are as follows: Manage Reliability Requirements Depending on the extent of system changes, potential business process impacts may be present around the implementation of Many to Many Substitution requests. Specifically, the ISO anticipates developing new process flows related to substitutions for resources that are on forced outages. 3.3 Justification Many to Many Substitution requests are being requested by our Market Participants to be able to make available non-RA capacity that is currently being constrained due to system limitations. This initiative will correct any system limitations. Owner: Owens; Andrew Doc ID: GNFDMDEHU6BB-46-53 Copyright 2012 California ISO Program Office Page 5 of 11 Template Version: 2.9 Document Version: 1.1 Technology Many to Many Substitution Requests Business Requirements Specification Date Created: 3/13/2014 4. Business Requirements The sections below describe the Business Processes and the associated Business Requirements involved in the project. These may represent high level functional, non-functional, reporting and/or infrastructure requirements. These business requirements directly relate to the high level scope items determined for the project. 4.1 Business Process: Manage Reliability Requirements 4.1.1 Business Requirements ID# Business Feature Requirement Type Potential Application(s) Impacted M2MSRBRQ001 Market Participants must have the capability to request many to many substitutions using one substitute unit to cover multiple forced outages. Core RA System Core RA System Business Rule: Many to many substitution requests are defined as having the capability to use one Non-RA resource to cover multiple forced outages on one or many RA resources. Business Rule: Local for local is allowed in the RT (pre-qualified resources only). Local for local and system for system or local for system substitutions shall be permitted in the DA. M2MSRBRQ002 If there are multiple substitution requests using the same resource, the ISO shall use a first come first serve approach in evaluating submission/approval of requests when the cumulative capacity is greater than the available Non-RA capacity on the resource. Owner: Owens; Andrew Doc ID: GNFDMDEHU6BB-46-53 Copyright 2012 California ISO Program Office Page 6 of 11 Template Version: 2.9 Document Version: 1.1 Technology Many to Many Substitution Requests Business Requirements Specification ID# Business Feature Requirement Type Date Created: 3/13/2014 Potential Application(s) Impacted M2MSRBRQ003 RA system shall allow unit substitutions only for the period of the outage. The following business rules must be adhered to: Core RA System Core RA System Core RA System Core RA System 1. If the end date of the outage is made shorter, then the SC for the original resource must have the capability to request the release of the substitute capacity. 2. If the end date of the outage is made longer, then the SC for the resource on outage must submit a new substitution request. 3. If the outage ends sooner, and the SC for the original resource requests the release of the substitute capacity, the original unit must remain available (same rules as initial substitutions apply) for at least 24 hours before the substitution can be released. M2MSRBRQ032 Outage requests submitted between T-7 and T4 must adhere to the following rules: i. The outage shall be exempted from the SCP availability calculation. Outage requests submitted between T-4 and T must adhere to the following rules: ii. M2MSRBRQ005 M2MSRBRQ006 Current Standard Capacity Product rules shall apply RA system user interface must accommodate many to many substitution requests. System must have the capability to use any Non-RA capacity for a substitution even if the unit is used for another substitution as long as eligible Non-RA capacity exists. Business Rule: Eligible Non-RA capacity is defined as net qualified capacity that is not designated as RA, CPM, RMR, substitution capacity (both pending and approved), Outage Management (both pending and approved) replacement capacity, and replacement capacity (approved and pending). Owner: Owens; Andrew Doc ID: GNFDMDEHU6BB-46-53 Copyright 2012 California ISO Program Office Page 7 of 11 Template Version: 2.9 Document Version: 1.1 Technology Many to Many Substitution Requests Business Requirements Specification ID# Business Feature Requirement Type Date Created: 3/13/2014 Potential Application(s) Impacted M2MSRBRQ007 RA system must have the ability to reserve eligible Non-RA capacity if the request is in “Pending” status. Core RA System Core RA System Core RA System; Settlements Core RA System Core RA System Core RA System Core RA System Core RA System Core RA System Business Rule: If request is denied, the system must make available the capacity for other substitution requests. M2MSRBRQ009 M2MSRBRQ033 M2MSRBRQ011 M2MSRBRQ012 M2MSRBRQ013 M2MSRBRQ014 M2MSRBRQ015 M2MSRBRQ016 RA system must adhere to the rules as described within Appendix A of this document. The system needs to be able to track RA, NonRA, and substitution capacity. Business Rule: Non-RA capacity is defined as net qualifying capacity that is not designated as RA, CPM, RMR, substitution capacity (both pending and approved), Outage Management (both pending and approved) replacement capacity. System must display allocations at the resource level varying by day including RA, CPM, RMR, and available approved/pending substitution capacity. System must display at the resource level: iii. Non-RA = NQC - ∑ (RA+ CPM + RMR + Substitution + Replacement Capacity) Substitution = Approved and pending Replacement Capacity = Approved and pending System must display the stated availability at the resource level. System must display the capacity eligible for substitution. Eligible capacity for substitutions = Min (NonRA, Availability) System must display substitution requests, usage of resources, and outage information (outage impact to RA capacity, outage ID, etc.) System must have the ability to accept substitution requests with substitute capacity varying by day using multiple resources. Owner: Owens; Andrew Doc ID: GNFDMDEHU6BB-46-53 Copyright 2012 California ISO Program Office Page 8 of 11 Template Version: 2.9 Document Version: 1.1 Technology Many to Many Substitution Requests Business Requirements Specification ID# Business Feature Requirement Type Date Created: 3/13/2014 Potential Application(s) Impacted M2MSRBRQ017 M2MSRBRQ018 System must have the ability to use substitution data to validate replacement requests (OM approved replacements and CPM) for NQC and PMAX validation. Settlements must have the ability to calculate or receive availability data for RA resources. Business Rule: The data for many to one is already being sent to Settlements. This requirement deals with the added functionality of many to many. M2MSRBRQ019 M2MSRBRQ021 System must have the ability to send substitution data to Settlements. Core RA System Core RA System; Settlements Existing Functionality Core Existing Functionality Settlement system must have the ability to validate the bidding requirement of the substitution capacity (including many to many substitution requests). Owner: Owens; Andrew Doc ID: GNFDMDEHU6BB-46-53 Copyright 2012 California ISO Core RA System; Settlements; Integration Settlements Existing Functionality Program Office Page 9 of 11 Template Version: 2.9 Document Version: 1.1 Technology Many to Many Substitution Requests Business Requirements Specification Date Created: 3/13/2014 4.2 Business Process: Outage Data Processing This section contains requirements around the consumption of outage data and the processing requirements. 4.2.1 Business Requirements ID# Business Feature Requirement Type Potential Application(s) Impacted M2MSRBRQ022 Outage Management System shall provide the availability point values (point) associated with the outage (stated in Outage Management System by market participants) to RA System at resource level. Core RA System; OMS Core RA System; OMS Business Rules: 1. This shall be at the granularity of the change in points (not at a daily level). 2. Each availability point value will be accompanied by: a. the planned curtailment MW value for planned outages b. the forced curtailment MW value for forced outages 3. Outage types to be considered are planned and forced along with all of the attribute types associated with outage. M2MSRBRQ023 Business Rule: Assumption is that the outages are marked similar to how the outage system handles today. There is no concept of partial forced. The RA system must display RA resource information. The UI must support the following variations: - RA information without the impact of outages - RA information with the impact of forced outages - RA information with the impact of planned outages - RA resources availability taking in to account all outage types - RA resource area information - RA resource NQC and PMAX - SC information Business Rule: The above information must be at a resource level. Owner: Owens; Andrew Doc ID: GNFDMDEHU6BB-46-53 Copyright 2012 California ISO Program Office Page 10 of 11 Template Version: 2.9 Document Version: 1.1 Technology Many to Many Substitution Requests Business Requirements Specification ID# Business Feature Requirement Type Date Created: 3/13/2014 Potential Application(s) Impacted M2MSRBRQ024 RA system shall consume use nature of work field to determine if outages can be exempt from Standard Capacity Product (SCP). Core RA System; OMS Core RA System; OMS Core RA System; OMS Core RA System; Business Rule: The nature of work and outage type fields will be used to determine availability calculations. M2MSRBRQ026 RA system shall consume short notice and off peak opportunity outages designation. Business Rule: The above attribute and outage type will be used to determine availability calculations. M2MSRBRQ027 M2MSRBRQ031 RA system must have the capability to manage T45 snapshot processing. The system must provide the ability for participants to request for outage correction in the RA system. The ISO shall review and evaluate each request in the RA system. Outage Correction Process: 1. System must allow external users and ISO users to enter an outage correction request for forced outages 2. System must allow user to enter outage correction request any time after the outage has been approved a. Example: In 2013 user must have the capability to enter a request for outage back in 2010 3. The System must allow ISO users to accept or deny the request 4. If outage correction is approved in this process then outage should be exempt from SCP penalties Owner: Owens; Andrew Doc ID: GNFDMDEHU6BB-46-53 Copyright 2012 California ISO Program Office Page 11 of 11