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