Business Requirements Specification

Transcription

1 Business Requirements Specification Many to Many Substitution Requests Date Created: 6/20/2014 Revision History Date Version Description 11/18/ Creation of Document 3/13/ 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 Copyright 2012 California ISO Doc ID: GNFDMDEHU6BB Page 1 of 12

2 Date Version Description 4/29/ Reworded BRQ003 to reflect updated business requirement based on System Requirement Specification development. BRQ022 has been updated to remove business rule. The term partial forced no longer applies. BRQ031 removed example a since it is not relevant for external users. 6/20/ Including Phasing information Page 2 of 12

3 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. Page 3 of 12

4 Table of Contents 1. INTRODUCTION PURPOSE DETAILS OF BUSINESS NEED/PROBLEM DESCRIPTION BUSINESS PROCESS IMPACTS HIGH LEVEL BUSINESS PROCESS Description DESCRIPTION JUSTIFICATION BUSINESS REQUIREMENTS BUSINESS PROCESS: MANAGE RELIABILITY REQUIREMENTS Business Requirements BUSINESS PROCESS: OUTAGE DATA PROCESSING Business Requirements Page 4 of 12

5 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. Page 5 of 12

6 2. Details of Business Need/Problem 2.1 Description Business Opportunity/Problem Statement: What: When: Why do we have this opportunity/problem: Who does this opportunity/problem impact: 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. It impacts Market Participants wishing to use Non-RA Capacity to cover RA capacity that is on outage. 3. Business Process Impacts 3.1 High Level Business Process 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. Page 6 of 12

7 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 Business Requirements ID# Business Feature Requirement Type Potential Application(s) Impacted Phase BRQ001 Market Participants must have the capability to request many to many substitutions using one substitute unit to cover multiple forced outages. BRQ002 BRQ003 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. 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. RA system shall allow the user to request the release of substitute capacity. Page 7 of 12

8 ID# Business Feature Requirement Type Potential Application(s) Impacted Phase BRQ032 BRQ005 BRQ006 BRQ007 Outage requests submitted between T-7 and T- 4 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. 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). RA system must have the ability to reserve eligible Non-RA capacity if the request is in Pending status. Core RA System Phase 1 Business Rule: If request is denied, the system must make available the capacity for other substitution requests. BRQ009 RA system must adhere to the rules as described within Appendix A of this document. Core RA System BRQ033 The system needs to be able to track RA, Non- RA, and substitution capacity. Core RA System; Settlements Phase 2 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. Page 8 of 12

9 ID# BRQ011 Business Feature System must display allocations at the resource level varying by day including RA, CPM, RMR, and available approved/pending substitution capacity. Requirement Type Potential Application(s) Impacted Phase BRQ012 BRQ013 BRQ014 BRQ015 BRQ016 BRQ017 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. System must have the ability to use substitution data to validate replacement requests (OM approved replacements and CPM) for NQC and PMAX validation. Core RA System Core RA System Phase 1 BRQ018 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. Core Existing Functionality RA System; Settlements Phase 2 BRQ019 System must have the ability to send substitution data to Settlements. Core Existing Functionality RA System; Settlements; Integration Phase 1 Page 9 of 12

10 ID# Business Feature Requirement Type Potential Application(s) Impacted Phase BRQ021 Settlement system must have the ability to validate the bidding requirement of the substitution capacity (including many to many substitution requests). Core Existing Functionality Settlements Phase 2 Page 10 of 12

11 4.2 Business Process: Outage Data Processing This section contains requirements around the consumption of outage data and the processing requirements Business Requirements ID# BRQ022 BRQ023 Business Feature 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. 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. 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. Requirement Type Potential Application(s) Impacted Phase Core RA System; OMS Phase 1 Core RA System; OMS Phase 2 Page 11 of 12

12 ID# BRQ024 BRQ026 BRQ027 Business Feature RA system shall consume use nature of work field to determine if outages can be exempt from Standard Capacity Product (SCP). Business Rule: The nature of work and outage type fields will be used to determine availability calculations. 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. RA system must have the capability to manage T-45 snapshot processing. Requirement Type Potential Application(s) Impacted Phase Core RA System; OMS Phase 1 Core RA System; OMS Phase 1 Core RA System; OMS Phase 1 BRQ031 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 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 Core RA System; Phase 2 Page 12 of 12