Upload
phungdien
View
220
Download
3
Embed Size (px)
Citation preview
Business Requirements Specification
Access and Identity Management
Version 1.2
January 17, 2013
Revision History
Date Version Description
9/26/12 1.0 Creation of document
10/19/12 1.1 Minor edits to document
01/17/13 1.2 Added Phase 1/Phase 2 designation to each requirement. Also, added section 4.2 – Requirements for External POC data maintenance by ISO administrative staff
In
Owner:PMO Program Office
Copyright 2012 California ISO. Page 2 of 19
TechnologyTechnology
Review Date:
Policy No.:
Requirements for Access and Identity Management
Business Requirements Specification - Planning
Version No.: 1.2
Effective Date 01/17/2013
Table of Contents
1. INTRODUCTION .................................................................................................................................................... 4
1.1 PURPOSE ......................................................................................................................................................... 4 1.2 REFERENCES .......................................................................................... ERROR! BOOKMARK NOT DEFINED.
2. DETAILS OF BUSINESS NEED/PROBLEM ..................................................................................................... 5
2.1 DESCRIPTION .................................................................................................................................................. 5
3. BUSINESS PROCESS IMPACTS ....................................................................................................................... 6
3.1 HIGH LEVEL BUSINESS PROCESS .................................................................................................................. 6 3.1.1 Description ................................................................................................................................................. 6 3.1.2 Pros............................................................................................................................................................. 6 3.1.3 Cons ............................................................................................................................................................ 6
4. BUSINESS REQUIREMENTS ............................................................................................................................. 7
4.1 BUSINESS PROCESS: IDENTITY & ACCESS REQUEST MANAGEMENT AND PROVISIONING ........................... 7 4.1.1 Business Requirements – Submit AIM Requests ................................................................................ 9 4.1.2 Business Requirements – View User Permissions and AIM requests ........................................... 14 4.1.3 Business Requirements – Access/Identity Expiration Alerts ........................................................... 15 4.1.4 Business Requirements – Create Reports/Views ............................................................................. 15 4.1.5 Business Requirements – Training ...................................................................................................... 16
In
Owner:PMO Program Office
Copyright 2012 California ISO. Page 3 of 19
TechnologyTechnology
Review Date:
Policy No.:
Requirements for Access and Identity Management
Business Requirements Specification - Planning
Version No.: 1.2
Effective Date 01/17/2013
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.
In
Owner:PMO Program Office
Copyright 2012 California ISO. Page 4 of 19
TechnologyTechnology
Review Date:
Policy No.:
Requirements for Access and Identity Management
Business Requirements Specification - Planning
Version No.: 1.2
Effective Date 01/17/2013
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 bilateral 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 are intended for submission to the Information Technology Services (ITS) department and will serve as the initial set of business unit requirements for the appropriate software application/systems development effort. It is understood that ITS will perform additional requirements and systems analysis and may produce “To Be” Business Process Models, System Requirements Specifications and Use Cases to serve as the set of requirements documents used by the ITS 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 ITS requirements documentation produced.
In
Owner:PMO Program Office
Copyright 2012 California ISO. Page 5 of 19
TechnologyTechnology
Review Date:
Policy No.:
Requirements for Access and Identity Management
Business Requirements Specification - Planning
Version No.: 1.2
Effective Date 01/17/2013
2. Details of Business Need/Problem
2.1 Description
The ISO maintains approximately six thousand certificates granting internal and external customers access to roughly 50 ISO applications and systems. Each customer has designated one or more individuals within their organization to act as the Point of Contact (POC), authorized for initiating and maintaining access to ISO applications and systems. Currently, a POC maintenance process has been implemented in CIDI that facilitates the process of establishing, updating and terminating POCs as well as providing visibility (transparency), ease of use and self-service where appropriate to POCs to manage this process. In addition, an interim Application Access Request Form (AARF) Improvement Process that consolidates the submission of documents utilizing CIDI to create an AARC (Application Access Request Case) with a centralized approval and provisioning process was put in place. This process provides some degree of transparency and notification to the POC as the case is processed. The AIM project will finalize the process and technology improvements by: 1. Providing self-service automated access request functionality to the users via a common UI and
notifications; 2. Defining and implementing an approval process for new access requests that complies with audit and
security requirements; 3. Automating access provisioning requests; 4. Integration with Centralized Security Data Service (CSDS); 5. Providing internal training and external training documentation; 6. Providing external training of market participants that will use the automated entry point; 7. Providing updates to the BPM’s and internal processes as identified in the impact assessment; 8. Providing interfaces/integration across ISO systems to support the above requirements; and 9. Implementing the above in production and non-production systems.
In
Owner:PMO Program Office
Copyright 2012 California ISO. Page 6 of 19
TechnologyTechnology
Review Date:
Policy No.:
Requirements for Access and Identity Management
Business Requirements Specification - Planning
Version No.: 1.2
Effective Date 01/17/2013
3. Business Process Impacts
3.1 High Level Business Process
3.1.1 Description
This project will expand on the existing IT access management and certificate based access business process. This is categorized under Support Business Services business process. The following enhancements will be made to the existing business process to: 1. Interface with the recently implemented POC maintenance process that utilizes CIDI; 2. Enhance the existing IT access provisioning/management business processes; and 3. Expand the scope of the IT access provisioning/management business process to leverage data already
existing in other ISO systems, interfacing with those systems to eliminate manual processes, improve efficiencies and increase transparency through proactive processes.
3.1.2 Pros
1. Provide state of the industry customer transparency to requesters of system access; 2. Eliminate potential human error; and 3. Reduce the manual intervention through automation.
3.1.3 Cons
1. N/A
In
Owner:PMO Program Office
Copyright 2012 California ISO. Page 7 of 19
TechnologyTechnology
Review Date:
Policy No.:
Requirements for Access and Identity Management
Business Requirements Specification - Planning
Version No.: 1.2
Effective Date 01/17/2013
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.
Note: Requirements regarding maintenance of external POC data by ISO administrative staff and the functionality that currently resides in the CIDI application have been included in the scope of the AIM project in section 4.2. Also, each requirement that is in scope has been categorized into phase 1 or phase 2 where phase 1 at a high level covers read-only features of the AIM application as well as the external POC maintenance features while phase 2 covers read-write (create, update, delete) features of the AIM application.
4.1 Business Process: Identity & Access Request Management and Provisioning
Identity & Access request management and provisioning deals with the process of organizations/entities
requesting access to ISO applications or devices (in some cases it is the ISO that requires access to external
devices) via Points of Contact (POCs).It also deals with internal ISO users requesting access to applications.
Essentially, this will replace the manual AARF form submission and access activation/deactivation process.
The goal of the AIM process is to facilitate, across the ISO, a standardized approach to the process of
establishing, updating and terminating access as well as providing visibility (transparency), ease of use and
self-service where appropriate to POCs, internal ISO users, business units and IT to manage this process
from end to end. Five distinct objectives of the “to be” AIM business process are:
1. Submission of AIM requests via GUI; 2. Viewing of user permissions or AIM requests via GUI; 3. Access/Identity expiration alert; and 4. Creating reports/views.
The process steps associated with each category are shown in the diagrams below:
In
Owner:PMO Program Office
Copyright 2012 California ISO. Page 8 of 19
TechnologyTechnology
Review Date:
Policy No.:
Requirements for Access and Identity Management
Business Requirements Specification - Planning
Version No.: 1.2
Effective Date 01/17/2013 P
OC
/ In
tern
al IS
O u
se
rs
create
AIM
request
submit
AIM
request
success
incompleterequest
create
AIM
request
elements
route
AIM
request
elements
review
AIM
request
close
AIM
request
element
update
AIM
request
status
close
request
update
AIM
request
status
update
AIM
request
status
send out
notification of
AIM request
completion
receive
certificate
install
certificate
perform
provisioning/
de-provisioning
action
Identity/Access Request Management “To Be” Process
(1) Objectives (Internal/External):(1) Submit AIM requests via GUI(2) View AIM requests/user permissions via GUI(3) Access/identity expiration alert(4) Create reports/views
send
certificate
to requester
RIG/DPG
disapprove
send out
notification of
AIM request
disapproval
per application/
certificateBUapprovalrequired
else
create
certificate
new certificaterequired
else
close
AIM
request
element approve
create/
update
user
account
close
AIM
request
element
update
user
account
Bu
sin
es
s U
nit
Legend
Basic flow
Alternative flow
Exception flow
send out
notification of
access request
submission
update
AIM
request
status
pre-
validate
AIM
request
update
AIM
request
status
incomplete
else
completerequest
failure
Info
rma
tio
n T
ec
hn
olo
gy
else
In
Owner:PMO Program Office
Copyright 2012 California ISO. Page 9 of 19
TechnologyTechnology
Review Date:
Policy No.:
Requirements for Access and Identity Management
Business Requirements Specification - Planning
Version No.: 1.2
Effective Date 01/17/2013 P
OC
/ In
tern
al IS
O u
se
rsIT
/Cu
sto
me
r S
erv
ice
check for
identity/
access
soon to
expire
generate
alerts to POCs
& ISO staff
nonefound
else(3)
view user
permissions/
AIM requests
display
AIM
requests
display
authorized
users
AIMrequest
userpermissions
(2)
(4)
generate
report/view
display
report/view
report
save
report/view
display
save
regularbasis
Legend
Basic flow
Alternative flow
Exception flow
For externalusers only
The major stakeholders involved in the identity and access request management and provisioning business process are:
1. POC – Person designated to request identity and access authorization on behalf of a group of people belonging to an organization that has a relationship with the ISO.
2. External user – Person associated with an organization/entity requiring access to applications or devices.
3. Internal ISO user – An ISO employee requiring access to applications.
4. ISO Customer Services – Application and Business units (process) within the ISO responsible for facilitating access and identity management.
5. Other ISO Business Units - Business units within the ISO that own different applications/devices and are responsible for approving AIM requests.
6. ISO Information Technology – Primarily, IT Corporate Services is responsible for pre-validating AIM requests, managing certificates as well as managing access.
4.1.1 Business Requirements – Submit AIM Requests
In
Owner:PMO Program Office
Copyright 2012 California ISO. Page 10 of 19
TechnologyTechnology
Review Date:
Policy No.:
Requirements for Access and Identity Management
Business Requirements Specification - Planning
Version No.: 1.2
Effective Date 01/17/2013
ID# Business Feature
Require
ment
Type
Potential
Applicati
on(s)
Impacted
Phase
1/Phase
2
AIM-BRQ001 POCs and all internal ISO users must be able to submit or cancel requests via GUI. In order to update a request, the original request must be canceled and a new one submitted in its place. A request can only be canceled before it has been approved or in cases where there is no approval required, before it has been provisioned.
Core Phase 2
AIM-BRQ003 The creation of requests shall include validation such as: 1. ensuring requests can only be submitted by eligible users
(POCs & internal users) and for the eligible applications; and
2. ensuring that requests for access are not duplicated
Core Phase 2
AIM-BRQ004 Complete and structurally correct requests that have been successfully validated can be submitted for processing by a POC or an internal ISO user.
Core Phase 2
AIM-BRQ050 AIM process must integrate with internal systems for validation where applicable
Core Phase 2
AIM-BRQ005 An AIM request may be used to initiate a single action associated with multiple users to: 1. provision/deprovision application access; 2. provision/deprovision device access; or 3. manage user accounts. Failure for a single user will not hold up or cancel processing of an entire request. Possible actions at a high level include: 1. new request to create user accounts 2. new request for access to an application or device 3. modification of existing access:
a. add more levels of access to an application b. remove some levels of access to an application c. add an application or device d. remove an application or device
4. termination of access 5. renewal of access 6. modification of user accounts
a. name change b. contact detail changes
7. removal of user accounts that have no access rights
Core Phase 2
In
Owner:PMO Program Office
Copyright 2012 California ISO. Page 11 of 19
TechnologyTechnology
Review Date:
Policy No.:
Requirements for Access and Identity Management
Business Requirements Specification - Planning
Version No.: 1.2
Effective Date 01/17/2013
ID# Business Feature
Require
ment
Type
Potential
Applicati
on(s)
Impacted
Phase
1/Phase
2
AIM-BRQ006 An AIM request for application or device access must include the applicable application and resource information currently in the following manual forms: 1. User application access request form; 2. Device certificate request form; 3. Integration application access request form; 4. SFTP application access request form; 5. PIRP access form; 6. ADS ACL form; 7. SLIC – sub BA ID (requested via special notes/instructions
in the user/integration application access request forms); or
8. Revoke application access request form. For AIM requests for ADS and PIRP, these requests will not be accepted unless it is indicated (for each SCID requested) if full access is needed or what specific resources are needed if access is restricted.
Core Phase 2
AIM-BRQ007 The AIM process must be able to uniquely identify users and organizations regardless of name changes that may occur.
Core Phase 1
AIM-BRQ008 ISO’s AIM process must automatically issue receipt notifications upon receipt of an AIM request with a unique id for the request. Recipients of notifications must be configurable.
Core Phase 2
AIM-BRQ009 Each successfully submitted AIM request will generate 1 or more elements required to fulfill the request. These elements include but are not limited to: 1. User account creation, modification or removal/disabling; 2. Approval by business unit; 3. Certificate generation, renewal or revocation; and 4. Application access creation, update, renewal or
revocation. Each element must be assigned to a responsible party with an expected target completion date.
Core Phase 2
AIM-BRQ010 Each element associated with an AIM request must be routed to the appropriate party(ies) for completion.
Core Phase 2
AIM-BRQ011 The workflow for routing elements of an AIM request to appropriate party(ies) must be configurable. It must be able to handle non-CMA certificate provisioning actions that require business unit involvement
Core Phase 2
In
Owner:PMO Program Office
Copyright 2012 California ISO. Page 12 of 19
TechnologyTechnology
Review Date:
Policy No.:
Requirements for Access and Identity Management
Business Requirements Specification - Planning
Version No.: 1.2
Effective Date 01/17/2013
ID# Business Feature
Require
ment
Type
Potential
Applicati
on(s)
Impacted
Phase
1/Phase
2
AIM-BRQ012 AIM requests for application access submitted by internal ISO users must be routed for approval to the appropriate business units depending on the applications for which access is requested. AIM requests for application access submitted by POCs may be auto-approved or routed to business units for approval depending on the applications for which access is requested. Business units may approve or disapprove a request or request more information from the submitter of the request.
Core Phase 2
AIM-BRQ013 During the approval process, an approver may modify an AIM request to incorporate additional information required to fulfill the request; e.g., the addition of information about LDAP groups associated with ADS exceptions or the modification of roles with respects to SIBR.
Core Phase 2
AIM-BRQ014 A user must be associated with only one organization, as his/her identity belongs to one organization. A user or identity is considered to be a person at an organization. It is conceivable for a person to have multiple identities/user accounts with the ISO.
Core Phase 1
AIM-BRQ015 A request for termination of a user can only occur via the POC of the organization the user belongs to and it must result in the termination of all identity and access rights to ISO applications/devices.
Core Phase 2
AIM-BRQ016 A request for revocation of access rights associated with a user can occur via: 1. The POC of the organization the user belongs to; or 2. The POC of another organization that has granted some
access rights to the user; i.e., the owner of the access control group.
Core Phase 2
AIM-BRQ017 The relationship of the organization represented by a POC with the ISO will determine the list of applications available for AIM requests.
Core Phase 2
AIM-BRQ018 POCs and internal ISO users shall be able to attach files to their AIM requests. This is a specific requirement for RIG/DPG for a certificate signing request (CSR) to accompany an AIM request for device access. Also, to permit the attachment of an applicable NDA form.
Core Phase 2
AIM-BRQ020 POCs and internal ISO users must be able to copy an existing user to 1 or more new users as well as carry out a bulk modification of existing users.
Core Phase 2
In
Owner:PMO Program Office
Copyright 2012 California ISO. Page 13 of 19
TechnologyTechnology
Review Date:
Policy No.:
Requirements for Access and Identity Management
Business Requirements Specification - Planning
Version No.: 1.2
Effective Date 01/17/2013
ID# Business Feature
Require
ment
Type
Potential
Applicati
on(s)
Impacted
Phase
1/Phase
2
AIM-BRQ021 POCs must be able to submit certificate renewals without requiring re-approval.
Core Phase 2
AIM-BRQ022 POCs must be able to request access for a user at an organization besides the organization they belong to, provided the appropriate cross organizational relationships are in place.
Core Phase 2
AIM-BRQ023 Each user or AIM request shall be associated with one or more of the different types of relationships that currently exist between the ISO and external entities or a new type of relationship that could be added in the future. A relationship with the ISO is currently identified as one of the following: 1. A contract agreement with a registered scheduling
coordinator with 1 or more corresponding SC ID; 2. A project established in RIMS with a corresponding project
ID; 3. A generator owner identified for a RIG/DPG identified by a
resource ID; 4. Agency requiring information from the ISO identified by an
agency name; 5. ISO employee; or 6. ISO contractor.
Core Phase 2
AIM-BRQ024 Each AIM request must have a lifecycle which will be made up of states such as created, submitted, closed, approved, rejected, etc., which will be updated.
Core Phase 2
AIM-BRQ025 Each element within an AIM request must have it’s own lifecycle distinct from the request, such as new, completed, error. Elements within a request may have different statuses.
Core Phase 2
AIM-BRQ026 Notifications must be sent and status updates visible (transparency) to POCs, external end users & ISO staff during the different stages (refer to AIM-BRQ023) of the lifecycle of a request and it’s associated elements.
Core Phase 2
AIM-BRQ027 Each user account must have a lifecycle that will be made up of states such as active, terminated, invalid, etc.
Core Phase 1
AIM-BRQ028 Alerts must be generated when an element associated with a request is not completed within the agreed upon SLA. Recipients of alerts shall be configurable and shall receive the alert notification on a regular basis until the element is completed. The proximity of alerts to expected completion date shall be configurable and the frequency of alerts once triggered shall be configurable. Also, the SLA shall be configurable.
Core Phase 2
In
Owner:PMO Program Office
Copyright 2012 California ISO. Page 14 of 19
TechnologyTechnology
Review Date:
Policy No.:
Requirements for Access and Identity Management
Business Requirements Specification - Planning
Version No.: 1.2
Effective Date 01/17/2013
ID# Business Feature
Require
ment
Type
Potential
Applicati
on(s)
Impacted
Phase
1/Phase
2
AIM-BRQ031 Currently existing user account information must be migrated into the AIM process
Core Phase 1
AIM-BRQ032 The AIM process shall adhere to the existing ISO policy with regards to disabling/deleting users and the ability to re-activate/recreate them when required (such as internal users are disabled and then re-activated while external users are deleted and then recreated).
Core Phase 2
AIM-BRQ033 A history of user accounts, AIM requests and associated request elements shall be maintained and viewable by the AIM process.
Core Phase 2
AIM-BRQ049 The AIM process shall track what POCs are authorized to do; i.e., the organization a POC belongs to and the applications a POC is authorized to make requests for.
Core Phase 2
AIM-BRQ052 An organization may have 1 or more different relationships
with the ISO
Core RIMS, RIG/DPG Access Database, MF, etc
Phase 1
AIM-BRQ053 2 or more affiliated organizations may have the same POC. Core RIMS, RIG/DPG Access Database, MF, etc
Phase 2
4.1.2 Business Requirements – View User Permissions and AIM requests
ID# Business Feature
Require
ment
Type
Potential
Applicati
on(s)
Impacted
Phase
1/Phas
e 2
AIM-BRQ034 POCs and internal ISO users shall be able to view AIM requests and user permissions. POCs shall be able to view requests and user accounts identified by the authorized relationship(s) with the ISO. Internal users shall be able to view requests and user accounts that pertain to them. ISO business units and IT staff involved in the AIM process shall be able to view all requests and user accounts as well as the details of elements associated with each request such as status, assigned to, date assigned, etc.
Core Phase1/ Phase 2
In
Owner:PMO Program Office
Copyright 2012 California ISO. Page 15 of 19
TechnologyTechnology
Review Date:
Policy No.:
Requirements for Access and Identity Management
Business Requirements Specification - Planning
Version No.: 1.2
Effective Date 01/17/2013
ID# Business Feature
Require
ment
Type
Potential
Applicati
on(s)
Impacted
Phase
1/Phas
e 2
AIM-BRQ035 Display of AIM requests must include: 1. ISO relationship ids (e.g. SCIDs, resource IDs, project ID,
agency name); 2. Applications; 3. User role (job function); 4. Certificate expiration; 5. Organization; 6. Access role; 7. Environments; and 8. Effective date.
Core Phase 2
AIM-BRQ036 The display of user accounts to POCs, internal users and ISO staff involved with the AIM process must at a minimum comprise of: 1. User’s name; 2. Contact details; 3. Status; 4. Certificates; and 5. Application access rights.
Core Phase 1
4.1.3 Business Requirements – Access/Identity Expiration Alerts
ID# Business Feature
Require
ment
Type
Potential
Applicati
on(s)
Impacted
Phase
1/
Phase 2
AIM-BRQ040 The AIM process must be able to generate alerts when certificates for external users are close to expiration. POCs and ISO staff shall receive the alert notification on a regular basis until a renewal request is submitted.
Core Phase 2
AIM-BRQ041 Proximity of alerts to the expiration dates of certificates shall be configurable. Also, the frequency of alerts once triggered and the receipients of the alerts shall be configurable.
Core Phase 2
4.1.4 Business Requirements – Create Reports/Views
ID# Business Feature
Require
ment
Type
Potential
Applicati
on(s)
Impacted
Phase 1/
Phase 2
In
Owner:PMO Program Office
Copyright 2012 California ISO. Page 16 of 19
TechnologyTechnology
Review Date:
Policy No.:
Requirements for Access and Identity Management
Business Requirements Specification - Planning
Version No.: 1.2
Effective Date 01/17/2013
ID# Business Feature
Require
ment
Type
Potential
Applicati
on(s)
Impacted
Phase 1/
Phase 2
AIM-BRQ042 Authorized ISO customer services & IT staff must be able to create reports by applying different combinations of filters and sorting to POC, POC request, POC request elements, user account details, AIM request and AIM request elements. Filtering capability for user account details shall include: 1. expiration date; 2. user/device; 3. application; 4. profile; and 5. access role. Filtering capability for AIM requests shall include: 1. user/device; and 2. request status.
Core Phase 1/ Phase 2
AIM-BRQ043 Authorized ISO customer services & IT staff must be able to view generated reports.
Core Phase 1/ Phase 2
AIM-BRQ044 Authorized ISO customer services & IT staff must be able to print or save reports generated.
Core Phase 1/ Phase 2
4.1.5 Business Requirements – Training
ID# Business Feature
Require
ment
Type
Potential
Applicati
on(s)
Impacted
Phase 1/
Phase 2
AIM-BRQ054 The ISO shall provide training for POCs for AIM. Core Phase 1/ Phase 2
AIM-BRQ055 The ISO shall provide training documentation for AIM. Core Phase 1/ Phase 2
AIM-BRQ056 The ISO shall create Computer Based Training for AIM and add it to the curriculum.
Core Phase 1/ Phase 2
4.2 Business Process: External POC Maintenance
Maintenance of external POC data by ISO administrative staff applies to organizations/entities that require
access to ISO applications. These organizations/entities designate one or more Points of Contacts (POCs) to
manage the process of requesting user access to ISO applications. The goal of the AIM project with regards
to the POC maintenance process is to replace the POC maintenance functionality currently in the CIDI
application; i.e., maintenance of certain data elements associated with a POC such as contact information,
organization, area of responsibility. This does not include establishing, updating or terminating POCs.
In
Owner:PMO Program Office
Copyright 2012 California ISO. Page 17 of 19
TechnologyTechnology
Review Date:
Policy No.:
Requirements for Access and Identity Management
Business Requirements Specification - Planning
Version No.: 1.2
Effective Date 01/17/2013
4.2.1 Business Requirements – Maintain External POC Data
ID# Business Feature
Require
ment
Type
Potential
Applicati
on(s)
Impacte
d
Phase 1/ Phase 2
EPOC-BRQ001 Data about external POCs shall be maintained by the ISO’s POC maintenance process with the ability for ISO admin staff to view and modify the data.
Core Phase 1
EPOC-BRQ002 Each external POC shall be associated with one or more of the different types of relationships that currently exist between the ISO and external entities or a new type of relationship that could be added in the future. A relationship between the ISO and an external entity is currently identified as one of the following: 1. A contract agreement with a registered scheduling
coordinator with a corresponding SC ID; 2. A project established in RIMS with a corresponding
project ID; 3. A generator owner identified for a RIG/DPG identified by
a resource ID; or 4. Agency requiring information from the ISO identified by
an agency name.
Core RIMS, RIG/DPG Access Database, MF, etc
Phase 1
EPOC-BRQ003 Each external POC shall have capabilities associated with it, which will include: 1. Primary or Secondary role; 2. Type of relationship with the ISO (determined by the
organization represented); and 3. Area of responsibility (for each type of relationship that
exists with the ISO, there could be a further sub category within the relationship identified by an area of responsibility).
Core Phase 1
EPOC-BRQ004 A history of external POCs, and associated elements shall be maintained by the POC maintenance process.
Core Phase 1
EPOC-BRQ005 External POCs shall be able to view data about themselves as well as other external POCs identified by the authorized relationship with the ISO. ISO admin staff shall be able to view all external POCs.
Core
Phase 1
EPOC-BRQ006 The display of external POC data must at a minimum comprise of: 1. POC’s name; 2. Contact details (email address, phone number, physical
address); 3. Status; 4. Capabilities (Primary/Secondary POC, Type of
relationship, Area of Responsibility – by SC IDs, by Applications); and
5. POC effective dates (start, end and inactive dates).
Core Phase 1
In
Owner:PMO Program Office
Copyright 2012 California ISO. Page 18 of 19
TechnologyTechnology
Review Date:
Policy No.:
Requirements for Access and Identity Management
Business Requirements Specification - Planning
Version No.: 1.2
Effective Date 01/17/2013