nerc alerts project rfp

45
3353 Peachtree Road NE Suite 600, North Tower Atlanta, GA 30326 404-446-2560 | www.nerc.com Request for Proposal NERC Alert System July 11, 2012 Prepared By: Justin Lofquist Project Manager

Upload: nercalerts

Post on 20-Apr-2015

132 views

Category:

Documents


2 download

TRANSCRIPT

Page 1: NERC Alerts Project RFP

  

   

3353 Peachtree Road NE Suite 600, North Tower

Atlanta, GA 30326 404-446-2560 | www.nerc.com

Request for Proposal NERC Alert System

July 11, 2012

Prepared By: Justin Lofquist Project Manager

Page 2: NERC Alerts Project RFP
Page 3: NERC Alerts Project RFP

  

1  NERC Alert System RFP – April 2012 REV.: 1 

Table of Contents

 

Table of Contents ............................................................................................................................ 1 

1.  Overview ................................................................................................................................. 5 

1.1.  Introduction ...................................................................................................................... 5 

1.2.  Business Process Description ........................................................................................... 5 

1.3.  Business Objectives .......................................................................................................... 7 

2.  Functional Requirements ........................................................................................................ 7 

2.1.  User Role Definitions ........................................................................................................ 8 

2.2.  User Permissions Definitions (Table provided in Appendix) ............................................ 9 

2.3.  Roles and Permissions Requirements .............................................................................. 9 

System Administrator Role ................................................................................................... 10 

Primary Compliance Contact Role ........................................................................................ 10 

2.4.  Business Objects ............................................................................................................. 11 

2.5.  Alert Requirements ........................................................................................................ 12 

Creation ................................................................................................................................. 12 

Modifications and Links to other Alerts ................................................................................ 12 

Targeting ............................................................................................................................... 13 

Distribution / Alert Notification ............................................................................................ 13 

Viewing Alerts ....................................................................................................................... 14 

Printing Alerts ....................................................................................................................... 15 

2.6.  Acknowledgement Requirements .................................................................................. 15 

Configuration ........................................................................................................................ 15 

Acknowledgement ................................................................................................................ 16 

Page 4: NERC Alerts Project RFP

  

 

NERC Alert System RFP – 7/11/12  2 

2.7.  Response Requirements................................................................................................. 16 

Configuration ........................................................................................................................ 16 

Responses ............................................................................................................................. 17 

Locked Responses ................................................................................................................. 18 

Approval ................................................................................................................................ 18 

Periodic Responses ............................................................................................................... 18 

2.8.  On‐boarding Requirements ............................................................................................ 19 

2.9.  Reminders and Notifications Requirements .................................................................. 19 

2.10.  Administrator Requirements ...................................................................................... 20 

User Management ................................................................................................................ 20 

2.11.  Reporting Requirements ............................................................................................ 20 

3.  Non‐Functional Requirements .............................................................................................. 22 

3.1.  Security Requirements ................................................................................................... 22 

3.2.  Auditing Requirements .................................................................................................. 22 

3.3.  System Requirements .................................................................................................... 23 

3.4.  External Interface Requirements ................................................................................... 23 

3.5.  Performance Requirements ........................................................................................... 24 

3.6.  Look and Feel Requirements .......................................................................................... 24 

3.7.  Application Programming Interface (API) ...................................................................... 24 

3.8.  Data Requirements ........................................................................................................ 24 

3.9.  Browser Support Requirements ..................................................................................... 25 

3.10.  Maintainability Requirements .................................................................................... 25 

3.11.  System Availability, Data Retention and Recovery .................................................... 26 

4.  Project Requirements ........................................................................................................... 26 

4.1.  General ........................................................................................................................... 26 

Page 5: NERC Alerts Project RFP

  

3  NERC Alert System RFP – April 2012 REV.: 1 

4.2.  Assumptions ................................................................................................................... 27 

4.3.  Constraints ..................................................................................................................... 27 

5.  Quality Control Deliverables ................................................................................................. 27 

5.1.  Overview ........................................................................................................................ 27 

5.2.  Preliminary Design and Review ...................................................................................... 28 

5.3.  Final Design .................................................................................................................... 28 

5.4.  Code, Unit Testing and Integration Testing ................................................................... 29 

5.5.  Pre‐production Functional Test...................................................................................... 29 

5.6.  Delivery and Production Start‐Up .................................................................................. 29 

5.7.  Final Acceptance ............................................................................................................ 30 

5.8.  Documentation .............................................................................................................. 30 

5.9.  Training ........................................................................................................................... 31 

6.  Warranty, Support and Maintenance ................................................................................... 31 

6.1.  Warranty ........................................................................................................................ 31 

6.2.  Support ........................................................................................................................... 31 

6.3.  Defects ............................................................................................................................ 32 

6.4.  Enhancements ................................................................................................................ 33 

7.  Submission Information ........................................................................................................ 33 

7.1.  Estimated Delivery and Implementation Schedule ........................................................ 33 

7.2.  Selection Schedule ......................................................................................................... 34 

7.3.  Clarifications Process...................................................................................................... 34 

7.4.  Qualifications .................................................................................................................. 35 

7.5.  Format for Proposal ....................................................................................................... 35 

7.6.  Contract Terms ............................................................................................................... 36 

7.7.  Budgets ........................................................................................................................... 36 

7.8.  Evaluation Criteria .......................................................................................................... 37 

Page 6: NERC Alerts Project RFP

  

 

NERC Alert System RFP – 7/11/12  4 

7.9.  Award or Rejection of Bids ............................................................................................. 38 

8.  Appendices ............................................................................................................................ 38 

8.1.  Acronyms, Abbreviations, and Definitions ..................................................................... 38 

8.2.  Roles and Permissions .................................................................................................... 40 

8.3.  Supplemental Data ......................................................................................................... 41 

8.4.  Alert Handling Levels ...................................................................................................... 42 

8.5.  Sample Alert Email Notification ..................................................................................... 43 

 

 

Page 7: NERC Alerts Project RFP

  

5  NERC Alert System RFP – April 2012 REV.: 1 

1. Overview  

1.1. Introduction

The mission of the North American Electric Reliability Corporation (NERC) is to improve the reliability and security of the bulk power system (BPS) in North America.  NERC accomplished this mission through enforcing compliance with mandatory Reliability Standards, conducting education and training activities, performing Reliability and Adequacy assessments, analyzing events, monitoring the BPS, and protecting critical infrastructure. 

Related to this mission, NERC develops Alerts based on information gathered through various resources, including Registered Entities, government and industry partners, and other sources.  These Alerts are managed through the NERC Alert system. 

The purpose of the NERC Alert System is to distribute and monitor the status of NERC Alerts.  The NERC Alert system is also utilized for tracking and reporting of NERC Alerts.  

The current NERC Alert System is a web‐based system, and while functional, the system does not meet the operational needs and requirements of NERC’s Reliability Risk Management (RRM) and Electricity Sector Information Sharing and Analysis (ES‐ISAC) staff. The current system is very rigid and difficult to create alerts. Reports on published alerts are generated only by the vendor. 

NERC is issuing a Request for Proposal to replace the existing NERC Alert system.  The current NERC Alert system is a web‐based system, and while functional, the system does not meet the current operational needs and requirements of NERC’s Reliability Risk Management (RRM) and Electricity Sector Information Sharing and Analysis (ES‐ISAC) staff.  The new Alert System will allow NERC to issue and track the status of issued Alerts. Likewise, the system will provide the functionality to generate various reports.  

NERC’s preference is that the system be a turn‐key or custom‐developed solutions hosted on NERC infrastructure and co‐maintained by the vendor and NERC.  NERC infrastructure is developed on Microsoft technologies and SharePoint is the primary platform for enterprise application development.  If the solution is custom‐developed, NERC would strongly desire it be built on SharePoint.  However, NERC will consider other operational options. 

 

1.2. Business Process Description

As part of its normal course of business, NERC often either discovers, identifies, or is provided with information that is critical to ensuring the reliability of the BPS in North America.  In order to effectively disseminate this information, NERC utilizes Alerts, which are designed to provide concise, actionable information to the electricity industry.  As defined in its Rules of Procedure, NERC Alerts are divided into three distinct levels, as follows:  

Page 8: NERC Alerts Project RFP

  

 

NERC Alert System RFP – 7/11/12  6 

 Level 1 (Advisories) – Advisories are purely informational, intended to advise certain segments of the owners, operators and users of the BPS of findings and lessons learned.  Level 2 (Recommendations) – Recommendations are specific actions that NERC is recommending be considered on a particular topic by certain segments of owners, operators, and users of the BPS according to each entity’s facts and circumstances.  Level 3 (Essential Actions) – Essential Actions present specific actions that NERC has determined are essential for certain segments of owners, operators, or users of the BPS to take to ensure the reliability of the bulk power system. Such Essential Actions require NERC board approval before issuance. 

 Registered Entities who receive Level 2 (Recommendations) and Level 3 (Essential Actions) Alerts evaluate and take appropriate action. These Registered Entities provide reports of actions taken and provide timely updates on progress towards resolving the issues addressed in the Alert, in accordance with the reporting date(s) specified by NERC.  The Alerts system allows NERC RRM and ES‐ISAC personnel to send out alert notifications to predefined members and allow members to view and mange Alert acknowledgements and responses. Alerts are acknowledged by at least one member of the recipient entity. Alert notifications will be sent out via email, and optionally Short Message Service (SMS), in order to provide the best possible mechanism to ensure timely responses. Entity membership management is performed by the entity’s Primary Compliance Contact (PCC) or designee. The Alert System Administrator has the rights to manage the Primary Compliance Contact information. 

The typical lifecycle of an Alert conforms to the following process: 

1) NERC and ES‐ISAC staffs create an Alert by entering alert content into the system.  Attached to this Alert are several attributes, including a distribution list, the Alert level, whether the alert needs to be acknowledged and / or responded to, the questions an entity must answer when responding, and the frequency with which the response reminders will be sent. At any point, the Administrator can preview the Alert to verify layout and content are accurate.    

2) Once the Alert is published, a notification is sent to all members of the distribution list.  

3) A recipient of the alert notification will click on a link embedded in the e‐mail which will navigate to the Alert system, where they will log in and view the Alert.  Members will have the ability, based on authority level, to print the Alert for distribution.  

4) If applicable, users with explicit authority, (Company Officer or designee), representing the entire entity, will then acknowledge receipt of the Alert (some Alerts will not require 

Page 9: NERC Alerts Project RFP

  

7  NERC Alert System RFP – April 2012 REV.: 1 

an acknowledgement).  This acknowledgement immediately follows the Alert notification, typically within twenty‐four (24) hours.  Some Alerts may require formal responses (reports on the actions taken against the Alert), usually within six (6) months of acknowledgement.  These responses specifically address the questions attached to the Alert.  These responses are composed by authorized members representing a Registered Entity.  

5) Once reviewed, an entity representative will approve the response.  Once a response is approved, it can no longer be edited.  

6) Some Alerts may require that responses be filed periodically until adequate resolution of the Alert has been achieved by the Registered Entity.  These responses are typically filed on a quarterly or bi‐annual basis.    

1.3. Business Objectives

The business objectives for this project are in direct support of NERC’s strategic plan to promote reliability, collaboration and learning.   

Promote Reliability:  The NERC Alert system will increase the reliability of the BPS by facilitating: 

o The communication of findings, analyses and recommendations regarding specific BPS operations 

o The assurance that members receive Alerts 

o Accountability across the industry by ensuring appropriate responses are provided by Registered Entities 

o Consistency across the industry in taking specified actions 

Foster Collaboration: Increased collaboration among NERC, Regional Entities and Registered Entities will result through the centralization and secure distribution of Alert information across regions and the increased clarity and standardization of processes provided by the software solution. 

Serve as a Learning Organization: Through the development of the NERC Alerts system, NERC will effectively manage communications across industry and be able to provide tangible, actionable insight and guidance for Registered Entities.  

 

2. Functional Requirements  

Page 10: NERC Alerts Project RFP

  

 

NERC Alert System RFP – 7/11/12  8 

2.1. User Role Definitions

The following User Role definitions will be referenced when describing the “Roles and Permissions Requirements” presented in section 2.3.  Additional User Roles may be defined during detailed requirements gathering. 

 Information Technology (IT) Owner – NERC IT is considered the owner of the NERC Alert system.  IT Ownership responsibilities include managing the testing, development, deployment, and maintenance of the system.   NERC Alert System Administrator(s) – System and Application Administrator of the Alerts system, primarily concerned with facilitating deployment of alerts to industry personnel and global user management  

Primary Compliance Contact (PCC) for Registered Entity – The primary contact within the Registered Entity for user administration within the Registered Entity.  The PCC is responsible for ensuring that information regarding Registered Entity personnel is current and accurate. There is 1 PCC per Registered Entity. 

Administrators for Registered Entity – Assigned by the Primary Compliance Contact for a Registered Entity to perform user management duties. The Acknowledge and Respond privileges are optional for an Administrator and are designated by the PCC. 

Functional Group Members – Employees of the Registered Entity, assigned to a functional group.  Primarily only involved with the system in that they receive alert email notifications and view alerts that are targeted at their functional group. The Acknowledge and Respond privileges are optional for this user role and are designated by the PCC or Administrator. 

Company Officer (CO) – Assigned by the PCC, the primary responsibility of this role is to approve a Registered Entity’s response.  A Company Office has the ability to delegate this function.  

Regional Entity Staff – The staff from the eight Regional Entities granted access to the system by the NERC Alerts System Administrator. 

NERC Personnel – NERC employees 

Electricity Sector Participant – member of the electricity sector not employed by NERC, a Regional Entity or Registered Entity 

Non‐ERO Participant ‐ a government employee granted access to the Alerts system by the NERC Alerts System Administrator. 

 

Page 11: NERC Alerts Project RFP

  

9  NERC Alert System RFP – April 2012 REV.: 1 

2.2. User Permissions Definitions

The following User Role definitions will be referenced when describing the “Roles and Permissions Requirements” presented in section 2.3.  Additional user permissions may be defined during detailed requirements gathering.  

Add/Deactivate Users Globally – Add and deactivate users globally from the system  Add/Deactivate/Edit Local Users – The ability to add and deactivate an account and to edit user privileges from the system that are in a user’s Registered Entity    Acknowledge – The ability to acknowledge an Alert   Respond – The ability to submit a response for an Alert  Lock Responses – This role grants the ability to lock a response in order that no changes are made prior to response approval. 

 View Alerts – The ability to view Alerts   View Responses – The ability to view responses   View Acknowledgements – The ability to view acknowledgements   View Dashboards –  The  ability  to  view dashboard  reports of  the  functional  groups  a user’s registered entity belongs to  Reporting – The ability to view Alert system reports  Manage PCC Records – The ability to assign the PCC role to a newly added entity  Approve– The ability to approve Alert responses  

 Note: See appendix 8.2 “Roles and Permissions” for the default set of permissions assigned to role. 

 

2.3. Roles and Permissions Requirements

2.3.1. Each  role  has  a  standard  set  of  permissions.    This  set  of  permissions  can  be modified by  the  System Administrator.   Role modifications will  affect  the  role across  the  entire  system.    Therefore,  a  role  cannot  have  different  sets  of permissions for different entities or functional groups. 

 2.3.2. Permissions  can be  assigned  to  a user  independent of  role.    For example,  the 

functional  group  member  role  does  not  have  ‘acknowledge’  permission  by default.  However, an administrator can grant a specific user that permission so 

Page 12: NERC Alerts Project RFP

  

 

NERC Alert System RFP – 7/11/12  10 

the user  can acknowledge alert, even  though  the user has only  the  functional group member role.   

 

2.3.2.1. A  user  has  the  authority  to  assign  or  revoke  individual  permissions  to another user based on their own permissions.  

  2.3.2.2. A user may not revoke a specific permission from a user if that permission 

has  been  inherited  as  part  of  the  said  user’s  role.    For  example,  an administrator cannot  revoke  the Acknowledge permission  from  the PCC, as it is part of PCC role. 

 2.3.3. Additional custom roles can be created within the system by the NERC System 

Administrator.  2.3.4. The system administrator can create email lists where email addresses can be 

associated without requiring a user being created (NERC defined lists).   2.3.5. Users  can  have  multiple  roles  within  an  entity.    If  there  is  a  conflict  of 

permissions  within  roles,  the  effective  permissions  will  be  the  aggregation  o granted permissions amongst the roles.   

 2.3.6. A  user  can  assume  roles  for more  than  one  entity,  and  those  roles  can  be 

different.    2.3.6.1. Individual  and  role  permissions  do  not  inherit  across  entities.    For 

example,  if  a  user  is  a  PCC  for  entity  A  (with  ‘view  dashboard’ permissions),  but  only  a  FGM  for  entity B,  they will  not  have  the  ‘view dashboard’ permission for entity B. 

 

System Administrator Role 

2.3.7. The System Administrator can change the PCC for each entity.  

 

2.3.8. The System Administrator will manage account information for the PCC for each 

entity. See section “3.4 External Interface Requirements” for details. 

 

Primary Compliance Contact Role 

2.3.9. PCCs manage contact and role information for Functional Group Members within 

their entity. 

 

2.3.9.1. PCCs  can  add  new  users  to  the  system  as  Functional  Group Members 

within their own Registered Entities.  

Page 13: NERC Alerts Project RFP

  

11  NERC Alert System RFP – April 2012 REV.: 1 

 2.3.9.2. PCCs can forfeit their Primary Compliance Contact designation to another 

individual within their organization.  

 

2.3.10. PCCs can ‘acknowledge’ an alert that is associated with their Registered Entity.  

2.3.11. PCCs  can  delegate  their  responsibilities  to  another  user within  the  Registered Entity. 

 

2.3.12. Members can hold this role for multiple Registered Entities. 

2.4. Business Objects

The diagram below describes the major business objects in the system and their relationships.  Those objects in dark blue are stored in the enterprise. 

Alert

Functional Area

UserRegistered Entity

Region

Subject Matter Area

 

 

2.4.1. User information will be stored in the enterprise Active Directory (2003).  (See section “3.4 External Interface Requirements” for details. 

 2.4.2. Registered Entity information will be stored in the NERC Compliance Registry 

database.  See section “3.4 External Interface Requirements” for details.   2.4.3. The system shall store Alert data including but not limited to Alert Type (Industry 

Advisory, Recommendation to Industry, Essential Action), Title of Alert, Functional Group and Subject Matter Area to which it applies, and date on when the Alert was distributed. 

Page 14: NERC Alerts Project RFP

  

 

NERC Alert System RFP – 7/11/12  12 

2.5. Alert Requirements

Creation 

2.5.1. Users with ‘Create Alert’ permissions will be able to copy/paste or manually type alert information directly into the alert form. 

 2.5.2. A functional area or areas MUST BE SELECTED for an alert, or the alert cannot be 

published. 

 

2.5.3. Alert creators will have the ability to add attachments to the Alert. 

 

2.5.4. There will be separate permissions for creating and publishing Alerts.   

 

2.5.4.1. No workflow will be required to manage this sub‐process.   

 

2.5.4.2. The status of the Alert will be clearly visible (Draft or Published). 

 

2.5.5. There will be 3 different templates that correspond to the level of the alert.  

Modification of these templates will be an enhancement of the system – not 

required as customizable by a system user. 

 

2.5.6. Zero to multiple questions can be created for an alert (See ‘3.7 Response 

Requirements ‐> Configuration).  Responses to these questions will always be 

required. 

 2.5.7. The NERC Alert system will provide the ability to preview the alert as how it will 

look when printed by a user viewing the alert.  2.5.8. The Alert creator can configure whether an acknowledgment or response is 

required.  2.5.8.1. There is a default timeline for acknowledgement / response.  2.5.8.2. This default can be overwritten during the Alert creation. 

 

2.5.9. Alerts will be authored by different business units within NERC.  Alerts may be flagged for viewing by only specific business units.   

 

Modifications and Links to other Alerts 

2.5.10. Alerts cannot be modified after they are published.  

Page 15: NERC Alerts Project RFP

  

13  NERC Alert System RFP – April 2012 REV.: 1 

2.5.11. If an Alert needs to be updated, a new alert will be created, with the ability to reference an existing alert. This reference will be bi‐directional, so both Alerts (the referencing and the referenced) will display a link to the other. 

 

Targeting 

2.5.12. Alerts are targeted to one, more or all registered functions, subject matter areas, Regional Entities, and Registered Entities, in any combination. 

 For example, an Alert can be targeted for Generation Engineers belonging to Generator Operator Entities in the NPCC Region.  If a user belongs to a Generator Operator Entity, but in the WECC region, the user will not receive the alert. 

 2.5.12.1. Selection options should be as follows:  

Select one or all entity functional groups at once 

De‐select one or all entity functional groups  

Select one or all subject matter areas at once 

De‐select one or all subject matter areas at once  

Select one or all regions at once 

De‐select one or all regions at once  

Select an individual Registered Entity  

2.5.13. NERC Defined Lists can be added to an alert distribution list.  

Distribution / Alert Notification 

2.5.14. Alert Notifications will be sent to all Functional Group Members who meet the targeting criteria. 

 2.5.15. Alert email notifications will be sent via email and optionally SMS (configured 

when creating the alert).  

 

2.5.16. If a user is a member of a combination of functional groups and responsibilities 

targeted by an alert, the user will only receive one alert notification. 

 2.5.17. A report will show the email addresses which have “bounced” on alert emails.   

2.5.17.1. This report will only be sent to the creator of the alert and the system administrator.   

 2.5.17.2. This report can be accessed from the Alert Detail screen by those with the 

appropriate authority.  

Page 16: NERC Alerts Project RFP

  

 

NERC Alert System RFP – 7/11/12  14 

 2.5.17.3. A bounce‐back report can be sent to all PCCs whose entity is targeted in 

the Alert.  The report will only contain the names of the users that are members of that entity.    

  2.5.18. The  alert  email  notification  sent  out  by  the  system  will  contain  textual 

information See section “8.5 Sample Alert Email Notification”. 

 

A brief description of the Alert 

The Alert level 

Registered Functions targeted by the Alert 

Responsibilities targeted by the Alert 

A  link  to  the  system  login page.   Upon  successful  sign‐in,  the user will be directed to the page displaying the alert. 

‘Forget Username / Password’ instructions 

Contact information for inquiries  

2.5.19. When both an email and SMS message are sent, the alert text may vary between 

SMS and email.  

 2.5.20. Alert notifications are sent to the email address and phone number on the 

contact information record. 

 

2.5.21. The system shall provide the ability to send messages/updates for Alerts to a 

pre‐defined group or a sub‐set of a group within the alert distribution list (e.g. all 

those who have not responded to an alert). 

 

2.5.21.1. This list can be generated from reports:  the system will provide a 

mechanism to convert the list of users on the report to a distribution list. 

 

2.5.21.2. The message will have custom content. 

 

Viewing Alerts 

2.5.22. Users have 2 views of the system Alerts.  One is a detailed view which will show all information about an alert.  The second is a list view, which shows all alerts the user has permissions to view, sorted by most recent of top.   

 2.5.23. When the user clicks the link in the alert notification, once logged in, she will be 

directed to the detail page of that alert.    

2.5.23.1. This detail view will show the full content of the alert.  

Page 17: NERC Alerts Project RFP

  

15  NERC Alert System RFP – April 2012 REV.: 1 

2.5.23.2. The detail view will also display all available actions that can be taken against the alert (e.g. acknowledge, respond, print) 

 2.5.23.3. From the detail view, the user can navigate back to the list view. 

 2.5.24. The list view is the default view  

2.5.24.1. The most recently issued alert is highlighted   2.5.24.2. This list includes all alerts that were published before the entity joined the 

BES (see section “2.8 On‐boarding Entities”)  2.5.24.3. Based on security, a user can see their entity’s status for that particular 

alert (e.g. acknowledged, approved, and responded).   

2.5.24.4. Based on security, a user can click ‘shortcut’ buttons on the list view that takes them directly to the Alerts’ acknowledgement form, response form, referenced alert (if applicable) and Alert detail page.   

 2.5.25. Based on security, when a user logs into the system it shall clearly state their 

entities’ status for that particular alert (e.g. last updated, approved, etc), on both the list and detail view. 

 2.5.26. View permissions are different than notification permissions: a user can view an 

alert that she was not notified of.  2.5.27. For users that are members of multiple entities, the system will indicate for 

which entity (or entities) the Alert was targeted.  

Printing Alerts 

2.5.28. System users can export alerts to PDF only.  This option will be restricted to those alerts they receive.  (Based on their role and alert levels, users may not receive certain alert notifications and/or view certain alerts).  

 2.5.29. Printable version of alert from Alert System will have the exact same look as the 

Alert as displayed on the screen.   

2.6. Acknowledgement Requirements

Configuration 

2.6.1. Alert  creators  can  configure  a  timeframe  for  an  acknowledgement  to  be 

received. 

 

2.6.1.1. This information is included in the Alert details and is configurable during 

Page 18: NERC Alerts Project RFP

  

 

NERC Alert System RFP – 7/11/12  16 

Alert creation.  

 

2.6.1.2. Default acknowledgement is within 24 hours.  Acknowledgement windows 

will not vary by entity or targeted group within an alert. 

Acknowledgement 

2.6.2. When a user enters the system to view an alert (on the detail or list view), there 

will be an option  to acknowledge  the alert  (if  the user has permissions).   This 

option will only be available until the alert has been acknowledged for an entity.   

 

2.6.2.1. If  a  race  condition  exists  (i.e.  2  users  log  in  at  the  same  time  and 

acknowledge), only the first acknowledgement will be recorded.  The user 

submitting the second acknowledgement will be notified.   

 

2.6.3. The  acknowledgment  form will  be  automatically  populated with  the  following 

information: 

 

NERC Compliance Registry ID Number  

Name of Entity as listed on NCR 

Primary Compliance Contact Info (name, email and phone) 

Acknowledger’s contact Info (name, email and phone)  

2.6.4. Multiple entities may be acknowledged on one form, so long as the 

Acknowledger is a member of those entities and is so designated.  The system 

will list all Entities (and corresponding PCC information) to which the 

acknowledger has acknowledgement privileges, with a ‘select all’ option. 

 

2.6.5. Alert acknowledgement and the responsibility to respond is only required for 

companies/entities that are active at the time the alert is issued, except for 

those alerts flagged as requiring action for any subsequent on‐boarded entities 

(See section “2.8 On‐Boarding Entities”). 

 

2.6.6. Not all alerts require an acknowledgement 

2.7. Response Requirements

Configuration 

2.7.1. Alert  creators  can  configure  a  timeframe  for  an  acknowledgement  and  a 

response to be received. 

 

2.7.1.1. This information is included in the Alert details and is configurable during 

Page 19: NERC Alerts Project RFP

  

17  NERC Alert System RFP – April 2012 REV.: 1 

Alert creation. 

  

2.7.1.2. Default acknowledgement is 60 days.  Response windows will not vary by 

entity or targeted group within an alert. 

 2.7.2. The response form can be accessed from either the detail or list view and will be 

automatically populated.   Example of  the automatically populated  information 

include: 

  

Subject or Alert to which the response pertains  

Date and time of response  

NCR ID Number Name of Entity as listed on NCR 

Primary Compliance Contact Info (Name, Email, Phone Number)  

Responder information (Name, Email, Phone Number) 

Required  reporting as  specified  in  the questions posed  (action  taken, progress 

towards resolving issues raised)   

 2.7.3. The alert creator will specify the response field type when creating 

questions (e.g. text field, date field, option group, check boxes).    

2.7.4. The system will not allow responses to have tiered response due dates on 

multiple questions.  

 

Responses 

2.7.5. Entities will be able to modify the response up until it is approved.  2.7.6. If  a user has Respond permissions  for multiple  entities,  she  can  generate one 

response on the behalf of one, all or a subset of the entities for which she  is a respondent. 

 2.7.7. Responses cannot be given by multiple Respondents  for an entity.   So, 2 users 

may  have  the  right  to  respond,  but  only  1  response  record  is  created  and 

modified. 

 

2.7.8. The  list  of  questions  on  a  response  form  can  be  exported  to Word  so  that 

entities can distribute questions, compile the answers, and then copy/paste the 

answers back into the response form without re‐typing.  

 

2.7.9. The system will allow users to upload documents associated to the reponse. 

 

Page 20: NERC Alerts Project RFP

  

 

NERC Alert System RFP – 7/11/12  18 

Locked Responses 

2.7.10. The system shall provide the ability to flag and lock responses that are considered complete. 

 2.7.11. The System Administrator has the permissions to unlock a response for re‐

editing.  

2.7.12. In the case that a response has already been given by another Respondent and locked,  a  message  will  appear  indicating  that  a  response  has  already  been 

entered and  locked by a Respondent  for  this entity.   That  response cannot be 

updated‐ only viewed.  

 2.7.13. When the response is locked, all other users that have respond permissions for 

that entity will be notified that the response is ready for approval.  

Approval 

2.7.14. Only users with appropriate permissions may approve a response. 

 

2.7.15. The  ‘Approve’  option  will  only  be  available  on  the  response  form  once  the 

response has been locked. 

 

2.7.16. Once the response has been approved, all other users with Approval permissions 

for the entity will be notified that the response has been approved. 

 

2.7.17. All users with Approval permissions should receive “Ready for Approval” email notification when a response is ready to approve (i.e. locked). 

 2.7.18. The System Administrator will have the ability to open the response for re‐

editing after the approval process has been completed. 

Periodic Responses 

2.7.19. Some alerts require follow‐up responses on a periodic basis (e.g. every quarter) until the entity resolves the issues outlined in that Alert.  

  2.7.20. There will only be one set of questions across all response periods for an Alert.  2.7.21. A user will be able to configure the frequency and timeframe the entities must 

adhere to for these periodic responses.  2.7.22. Periodic responses will follow the same process as non‐periodic responses (e.g. 

locking and approval).  

Page 21: NERC Alerts Project RFP

  

19  NERC Alert System RFP – April 2012 REV.: 1 

2.7.23. The system will display all responses to an alert together in a list, so that a user can see a narrative of an entity’s response to an alert over time. 

 2.7.24. The system shall provide the ability to lock responses, so that no additional 

responses can be entered for a particular period.  For the next update period, the previous responses shall remain locked and a new response period should open the ability to respond again until another date.  The system shall provide the ability to support this process on‐going. 

 2.7.24.1. These periods are configurable when creating the Alert.   2.7.24.2. The administrator can unlock responses.  2.7.24.3. Note ‐ this is different than the Locked Responses process described 

above. 

2.8. On-boarding Requirements

2.8.1. An Alert can be configured so that an acknowledgement and/or response is required by entities that join the BPS after the alert has been published. 

 2.8.2. These alerts are automatically associated to an entity when the entity is first 

registered with the system.  2.8.3. An email is automatically sent to the PPC with the list of alerts requiring 

response, and the alert will appear on the list of Alerts for that entity.  2.8.4. An entity can be related to a previously existing entity.  For example, an entities 

might merge or be re‐assigned NCR numbers due to ownership changes.  The alert history for the expired entity will be carried over.  However, these alerts will be reset, so that they will need to be re‐acknowledged and responses re‐approved by the new entity. 

 

2.9. Reminders and Notifications Requirements

2.9.1. The system will send an email reminder to late Acknowledgers, and Responders.  2.9.1.1. There will be a default configuration as to the number and schedule of the 

reminders.    2.9.1.2. The alert creator will be able to configure these reminders during Alert 

creation.  2.9.1.3. Reminders to the target group or sub‐group can be sent manually as well 

(e.g. those that have not yet responded to an Alert).  This will not override the reminder schedule. 

Page 22: NERC Alerts Project RFP

  

 

NERC Alert System RFP – 7/11/12  20 

2.9.2. The  system will  automatically  send  an overdue notification  to  all  entities  that 

have  not  acknowledged  and/or  responded  by  the  “Acknowledge  /  Response 

Required” date/time.  

 

2.9.2.1. There will be a default configuration as to the number and schedule of the overdue notifications.   

 2.9.2.2. The alert creator will be able to configure these notifications during Alert 

creation.  2.9.2.3. Over‐due notifications to the target group or sub‐group can be sent 

manually as well.  This will not override the reminder schedule. 

2.10. Administrator Requirements

User Management 

2.10.1. User management will be distributed, so that the Administrator role can manage all users and the PCC for an entity will manage users for that entity. 

 2.10.1.1. All user actions (role changes, re‐activations, etc) can be assigned as tasks 

by the system administrator to a PCC.  

2.10.2. Users can be associated to multiple Registered Entities concurrently.  2.10.3. There must be at least one Respondent selected per Subject Matter Area and 

Functional Group to which an entity is assigned.  2.10.4. Users must be associated to at least one role.  2.10.5. Contacts within an Entity can be marked ‘inactive’, but the system will not delete 

any alert or response information tied to these contacts, including the audit log.  

2.10.5.1. Users can be re‐activated by the PCC or the system administrator.  

2.11. Reporting Requirements

Standard reports will include but not be limited to the following: 

 

2.11.1. Acknowledgements, responses and approvals  

By alert or entity 

Across historical time periods 

For periodic alerts, this will be broken down by cycle 

Page 23: NERC Alerts Project RFP

  

21  NERC Alert System RFP – April 2012 REV.: 1 

 

2.11.2. Entities that have not provided acknowledgements or responses 

By alert or entity 

Across historical time periods 

For periodic alerts, this will be broken down by cycle 

 

2.11.3. Alerts 

List of entities issued the alert 

List of alerts issued to an entity 

 

2.11.4. Entities 

List of new entities since a particular date 

List of entities and their registration dates, filtered by date range 

Entities that do not have any assigned users 

Percent of Alerts an entity has been late in acknowledging or responding to 

 

2.11.5. Periodic Alerts 

For periodic  alerts,  the number of  cycles  an entity has been  aware of  the 

alert 

List of all periodic alerts a newly created entity must subscribe to 

 2.11.6. The system shall provide dashboards for Registered Entities, Regional Entities, 

and NERC Business Owners, which display a summary of information regarding alerts (e.g. the number of entities that have responded versus the percent that have not).    

2.11.6.1. Each dashboard will display information applicable to the logged‐in user with regard to their role and permissions. 

 2.11.7. The system shall provide a report that shows all user information, including their 

roles and corresponding permissions, by entity and/or by region.  2.11.8. The NERC Alert system shall provide the ability to perform, query and use a 

report –creation tool to produce custom reports.  Examples of reports include (but are not limited to): 

 

NERC Alerts generated for a defined time period 

Responses for specific NERC Alerts 

Reports by Regional Entities 

Reports by Registered Entity types  

2.11.9. The system shall provide the ability to download reports in multiple formats  

Page 24: NERC Alerts Project RFP

  

 

NERC Alert System RFP – 7/11/12  22 

3. Non-Functional Requirements  

3.1. Security Requirements

3.1.1. The system shall meet all NERC Critical Infrastructure Protection (CIP) standards as outlined and provided by NERC IT. 

 3.1.2. When a user logs into the system, the system shall ensure that the user is only 

presented with the access as designated for their account (e.g. buttons/options not available for their access should not be presented). 

 3.1.3. NERC IT will have administrative/root access to system and supporting 

infrastructure.    3.1.4. The system shall use secure protocols for all data transfers (e.g. use of 

encryption and SSL).  3.1.5. The system shall support object level permissions (e.g. some users have 

permission to take specific actions on a particular Alert while others do not).  3.1.6. Session time out is set to 45 minutes, with a warning 5 minute before the session 

expires.  Information not saved at that time will be lost.  3.1.7. The system shall provide a secure means for user identification retrieval.  3.1.8. The system shall prevent concurrent login sessions for a user.  3.1.9. The system shall lock out after a specified time period.  3.1.10. The system shall present an authorized use banner/statement for all users 

entering the system.  3.1.11. The collective content of outgoing emails (Subject plus Body) does NOT contain 

more than one of the following: Username, Password, or URL to the NERC Alert System. 

 

3.2. Auditing Requirements

3.2.1. The system shall provide a secure audit trail of all activities, for all accounts, taken by users on business objects, including the date, type of action, description, and the acting user, and whether the event was a success or failure. 

 

Page 25: NERC Alerts Project RFP

  

23  NERC Alert System RFP – April 2012 REV.: 1 

3.2.2. All system errors will be logged, and a distribution list for error notifications will be maintained by the system. 

 

3.3. System Requirements

3.3.1. Business objects (including user accounts) will be exportable to Microsoft Excel, including but not restricted to lists of Users, Alerts, Registered Entities, Regional Entities and functions.  

 3.3.2. Secure scripting and NERC coding practices will be implemented across the 

entire system, including the use of the latest version of C# if possible.  3.3.3. The application user interface shall be web‐based and accessible via the Internet.  3.3.4. The system shall support data validation for all data entry. 

3.3.5. The  user will  be  able  to  copy/paste  information  into  the  form  in  addition  to 

manually entering text.  

 3.3.6. The NERCALERTS.COM domain will be used to send out alerts from the 

[email protected] address.   3.3.7. The NERC Alert system must adhere to NERC CIP standards and NERC internal 

standards and policies (to be provided to vendor).  3.3.8. The system shall provide the robust searching capabilities, including but not 

restricted to:  

Registered Entity Search (Name, NCR Number) 

Alert (Name, Alert Number) 

Users (First Name, Last Name, Email Address)  

3.3.9. The system shall provide detailed on‐line and searchable help files.  3.3.10. The system shall identify each business object by a unique identifier.  3.3.11. The system shall provide the ability to store user created fields.  3.3.12. The system shall support an automated and customizable workflow for Alert 

types.  

3.4. External Interface Requirements

3.4.1. For user management, the system shall integrate with a NERC‐developed application interface that exposes Active Directory 2003 to the enterprise.  User 

Page 26: NERC Alerts Project RFP

  

 

NERC Alert System RFP – 7/11/12  24 

management functions will be exposed to the Alerts Administrator through screens developed as part of this project.  Those screens will include password management, activating and inactivating users, and modification of profile information. 

 3.4.2. The system will interact with the Compliance Registry database in order to 

retrieve a current, active list of Registered Entities.  The Alerts system will respond in near‐real time to changes in the Registry database, including addition of new entities and those inactivated.  

3.5. Performance Requirements

3.5.1. Alert email notifications should be sent immediately upon publication.   3.5.2. The system will be able to send an email notification request with up to 20,000 

recipients to an email server.  3.5.3. The system will be capable of supporting up to 2,000 concurrent users.   3.5.4. The system shall support an average response time of less than 3 seconds under 

peak operating situations when executed on the production infrastructure.  3.5.5. The average response time for all report requests shall be 10 seconds or less for 

synchronous and 5 minutes or less for asynchronous tasks on the production infrastructure. 

 

3.6. Look and Feel Requirements

3.6.1. Site  look and  feel will be  identical  to  the NERC web  site and approved by  the 

NERC Communications Group.  A styling guide will be provided.  

 

3.7. Application Programming Interface (API)

3.7.1. The system shall offer direct database access.  

3.8. Data Requirements

Please note, all volumes described below should be considered estimates, not upper limits.  

3.8.1. Data shall be stored in a secure RDBMS.  

Page 27: NERC Alerts Project RFP

  

25  NERC Alert System RFP – April 2012 REV.: 1 

3.8.2. The NERC Alert system shall support a minimum of 20,000 active user accounts, with a projected yearly growth of 10%. 

 3.8.3. The NERC Alert system shall support a minimum of 20,000 inactive user 

accounts, with a projected yearly growth of 5%.  3.8.4. They system shall support a minimum of 5,000 registered entities, with a 

projected yearly growth of 5%.  3.8.5. The NERC system will generate approximately 30 alerts a year, with 20,000 

acknowledgements and responses.  3.8.6. The system shall provide adequate capacity to archive 10 years of data and the 

ability for instant retrieval of such data when necessary.  

3.9. Browser Support Requirements

3.9.1. The system shall support the browsers that make up 90%+ of internet usage at the time of project initiation.   

 3.9.1.1. The system shall support the most current version of these browsers that 

have been on the market for minimum 6 months.  

3.10. Maintainability Requirements  In designing the application architecture, a high degree of consideration shall be given to the long term maintainability of the system. Considerations to long term enhancement, troubleshooting, interchangeability and repair of the system is of most importance. The objective is to minimize future maintenance labor, material costs and resources. 

 3.10.1. Standard components, including open source solutions that have been accepted 

and tested by the software industry, may be used. 

 

3.10.2. A software preventative maintenance schedule shall be developed and approved 

by NERC.  

 

3.10.3. No non‐standard component or practice shall be used without the explicit 

approval of NERC. 

 

3.10.4. There shall be a means to verify the release and version of the systems 

components that have been deployed to the production environment. 

 

Page 28: NERC Alerts Project RFP

  

 

NERC Alert System RFP – 7/11/12  26 

3.10.5. Upgrades to the host operating system or host database shall not require 

changes to the application.   

 

3.11. System Availability, Data Retention and Recovery

The NERC Alert system is considered a mission critical system, and therefore the following requirements will be implemented as part of the application.  

3.11.1. Recovery of system, data and interfaces within 2 hours.  3.11.2. The disaster recovery process will be jointly developed by NERC and the vendor. 

 

4. Project Requirements  

4.1. General

 4.1.1. It is expected that the Vendor supply project management, business analysis, 

and testing services for the project.  NERC will supply IT resources to advice and aid with integration, along with project management for engagement oversight. 

 4.1.1.1. Additional business analysis will be performed by the selected vendor in 

order to gather additional details not outlined in this RFP.  This includes interviewing two business units with a total of approximating 10 users.  

4.1.1.2. Vendor project management efforts will align with NERC project management methodology, which includes the following processes and artifacts: 

 

Communications management and status reporting 

Issue tracking and risk management 

Scope control 

Activity planning and resource loading 

Quality planning and control 

Change control management  

4.1.1.3. NERC PMO will provide project oversight and control, while facilitating communications between the vendor and the NERC organization. 

 4.1.2. Vendor will be provided initial seed data to be loaded into the system. 

Page 29: NERC Alerts Project RFP

  

27  NERC Alert System RFP – April 2012 REV.: 1 

 4.1.3. Remote vendor access into all NERC system environments will conform to NERC 

IT standards.  

4.1.3.1. The vendor shall provide a methodology to be used to conform to the security procedures enforced by NERC.  The methodology must address user access, protection against viruses, accidental disturbances of the database and other contaminating software. 

 4.1.4. Vendor will be required to perform an Extraction, Transformation and Load (ETL) 

of data from the existing Alerts System.  Support for any errors encountered during the process will be supplied by NERC staff. 

 

4.2. Assumptions

4.2.1. The vendor will be provided a group of Alert templates whose look and feel will be mimicked on the new system. 

 4.2.2. NERC will procure the hardware required to implement the system, with 

specification guidance provided by the vendor.  

4.3. Constraints

4.3.1. Vendor will not have access to production data.  

5. Quality Control Deliverables  

5.1. Overview

Design, development, test and delivery cover the bulk of the activities of the vendor for this project. These activities are defined to include the formally defined "life cycle" activities of: 

Preliminary Design 

Final Design 

Code and unit Test 

Integration Test 

Functional Test 

Delivery and Start‐Up 

Acceptance  5.1.1. Inspections, demonstrations and testing by NERC will be required periodically 

during the project to monitor its progress.  The use of an iterative development methodology such as Agile would meet this requirement. 

 

Page 30: NERC Alerts Project RFP

  

 

NERC Alert System RFP – 7/11/12  28 

5.2. Preliminary Design and Review

The preliminary design is a conceptual level view of the elements of the system where the selected vendor develops a functional specification of the system from the user's perspective. After these designs and specifications are reviewed by NERC they will serve as the basis for the system.  

5.2.1. During the preliminary design the contractor is to present NERC with its intended system design, code structure and design patterns to be used, system wireframes, development methodologies, and identify issues to be resolved. 

 5.2.2. This design phase shall also include a review of at least: 

User function descriptions 

Wireframe layouts 

Software architecture and interfaces 

Any updates to reliability, expansion or capacity issues 

Information needs 

Acceptance Test Procedure (ATP) based on the functional specifications  5.2.3. The ATP shall address a full function software test of the website to verify 

design, workmanship and performance. This includes test methodology and setup, evaluation criteria, individual function tests, sequence tests and test report. The testing procedure shall be required in order to adequacy monitor phases of the system development and installation.   

 5.2.4. The review shall be conducted by NERC and held not more than <timeline 

dependant> weeks after "Notice to Proceed" is issued to the contractor.  

5.3. Final Design

The final design activities will build on the baseline established in the preliminary design phase.  

5.3.1. The final design will conclude with a technical design review by NERC including but not limited to: 

 

Review of all documentation 

Final screen layouts including final branding details and formats 

Review of the Acceptance Test Procedure 

Review of software architecture, transactions and data 

Application development and implementation schedule 

 

Page 31: NERC Alerts Project RFP

  

29  NERC Alert System RFP – April 2012 REV.: 1 

5.3.2. The final design shall be conducted within 2 weeks of the preliminary design review for the NERC's approval.  

5.4. Code, Unit Testing and Integration Testing

5.4.1. The NERC project team shall participate in periodic reviews of the software code development.  This review shall include both design characteristics and quality of workmanship.  

 5.4.2. Unit tests shall be written as a means to regression test and maintain the 

system.  A minimum of 85% code coverage is required. Unit tests shall be included as part of the solution deliverable and be part of the system regression test.  

 5.4.3. The Acceptance Test Procedure shall be completed in this phase and ready for 

review, approval and acceptance by NERCs project team.  5.4.4. As part of development, the vendor will be responsible for performing 

integration testing between the system and any existing system interfaces as required.  

 

5.5. Pre-production Functional Test

5.5.1. Upon completion of the system, a NERC witnessed functional test shall be conducted and successfully completed prior to delivery to the NERC. This test shall be conducted in a hardware environment that represents the production environment.   

 5.5.2. The acceptance criteria established in the Acceptance Test Procedure will be 

used to evaluate the compliance of the website to the original specifications.  5.5.3. The system must demonstrate the capability to perform the required functions 

under loads defined in section “3.5 Performance Requirements”. Likewise, the system must demonstrate the capability to operate at the required speeds and perform at the required throughputs.  

 5.5.4. During this phase, the system shall pass a thorough a formal application 

vulnerability testing assessment.  5.5.5. Completeness of documentation shall also be evaluated at this time.      

 

5.6. Delivery and Production Start-Up

5.6.1. All deliverables shall be delivered electronically on NERC approved media, to NERC prior to production startup. Items delivered shall include unit tests, test results and documentation. 

Page 32: NERC Alerts Project RFP

  

 

NERC Alert System RFP – 7/11/12  30 

 5.6.2. Production start‐up (defined as deployment of code and data into the 

production environment and bringing the solution online) shall begin after the functional test has been successfully executed.  

 

5.7. Final Acceptance

5.7.1. After the system has been installed in the production environment, the Acceptance Test Procedure used in the Functional Test will be used along with any revisions resulting from that test.  

 5.7.2. The system must demonstrate the capability to perform the required functions 

under loads defined in section “3.5 Performance Requirements”. Likewise, the system must demonstrate the capability to operate at the required speeds and perform at the required throughputs.  

 5.7.3. Final completeness of documentation shall be evaluated at this time.  5.7.4. The system must be able to sustain a duty and reliability test of <NUMBER> () 

consecutive days conducted by NERC IT personnel.  If the duty and reliability test is interrupted due to serious software failures the test must be restarted after corrective work has been performed by the vendor. A serious software failure shall be considered to be whenever it is not possible to perform a system function or render a page without error. 

 5.7.5. Successful completion of this test as well as completion of any defined training 

must occur before the website is accepted by NERC. Currently <MONTH> through <MONTH> of 2011 as scheduled for final test and training. 

 

5.8. Documentation

5.8.1. Documentation describing the interface specifications and operation as well as training manuals are required.  

 5.8.2. Documents shall be delivered electronically. Documents shall use the Microsoft 

Word format and be delivered in Word and as a PDF.    5.8.3. Outlines and details of documentation and training manuals shall be reviewed 

and approved by NERC during the design phases.  

Page 33: NERC Alerts Project RFP

  

31  NERC Alert System RFP – April 2012 REV.: 1 

5.9. Training

5.9.1. The contractor shall develop and conduct a training program which will enable NERC members' personnel to operate, maintain and update vendor developed portions of the system. 

 5.9.2. Training shall provide operational instruction for NERC personnel to understand 

and execute any custom functionality provided by the vendor. Training shall be conducted on a system which emulates the actual production system and where trainees can work at a workstation representative of the actual system.  

 5.9.3. For bidding purposes estimate the number of training hours to not exceed two 

(2) days. Training shall be completed no later than 1 week before production deployment. Training will be held preferably at NERC's Atlanta offices at times that are mutually agreed upon. 

 

6. Warranty, Support and Maintenance  

6.1. Warranty

6.1.1. The system is expected to be free from defect. The vendor shall assume all responsibilities for workmanship.   

 6.1.2. A complete warranty package for the system shall be provided by the vendor.  

Defect resolution shall be completed in total as part of this package.   6.1.3. NERC reserves the right to reject any delivered solution that does not satisfy the 

requirements outlined in this document.  The vendor will have a prescribed time to rectify the short‐comings, at no cost to NERC.  If, after the allocated time, the system still does not meet system requirements, NERC reserves the right to reject delivery of the system. 

6.2. Support

The vendor will not have access to production data.  Therefore, support shall be a joint effort between NERC and the vendor. 

 6.2.1. The vendor shall be responsible for supporting the triage of all defects and fixing 

those defects deemed to be functional and covered within the Statement of Work.  

6.2.1.1. The vendor shall keep online a test environment that substantially mimics production, including data, in order to perform highly responsive troubleshooting. 

 

Page 34: NERC Alerts Project RFP

  

 

NERC Alert System RFP – 7/11/12  32 

6.2.2. NERC will be responsible for all hardware, network and other infrastructure support.    

6.2.3. The vendor shall work cooperatively with NERC to identify and resolve any performance issues and database tuning efforts.   

 

6.3. Defects

6.3.1. Defects shall be classified with priority levels of 1‐5 and shall be resolved based on priority. The resolution of outstanding defects shall be performed on an ongoing basis by the vendor.  

Defect Priorities are defined as: 

P1: System Down, Data Loss 

P2: Major Functionality Loss – no work‐around available 

P3: Minor Functionality Loss – work‐around available 

P4: Cosmetic – all functionality available 

P5: Enhancement  6.3.1.1. Any defect classified as P1 will trigger the necessity of an emergency 

release.  6.3.1.2. Any defect classified as P2 will trigger the necessity to schedule a release 

to occur within 3 months of the submittal of the defect to the vendor.    6.3.1.3. All other defects shall be included in scheduled releases.  

Maintenance releases shall be of two types: 

Emergency 

Scheduled   

6.3.2. All components in a release shall be versioned so that each item placed into the production environment can be traced back to a specific release. 

 An emergency release shall be made to address system failures which result in the failure of the business process or in the loss of or corruption of data.  

 6.3.3. Emergency and scheduled maintained releases produced by the resolution 

process shall be scheduled for deployment in accordance with a maintenance plan developed by the vendor and approved by NERC.  

 

Page 35: NERC Alerts Project RFP

  

33  NERC Alert System RFP – April 2012 REV.: 1 

6.3.3.1. The frequency of scheduled releases shall be agreed on by NERC and vendor prior to the initial deployment, with the opportunity to modify based on the volume and classification of defects.   

 6.3.3.2. A maintenance release shall follow the same development, testing and 

deployment guidelines defined in this document and used for the initial system development. 

 

6.4. Enhancements

NERC expects that changes in future business will require enhancements to the Alerts system after the Alerts system has been deployed into production.   

6.4.1. The amount of lag before working on enhancement requests shall be agreed on by NERC and the vendor during contract negotiations. 

 6.4.2. Enhancements shall undergo the same development, testing and deployment 

guidelines defined in this document and used for initial system development. 

 

7. Submission Information  

NERC is inviting several companies to submit bid proposals for this project. Those who desire to make a bid must make an estimate for developing, delivering (including training), a contingency plan to support full system availability, and five years of support, including enhancements, as described in sections “6.2 Support” and “6.4 Enhancements”. Those desiring to bid shall exercise special care in studying the functional and technical personnel within their organizations to ensure that the products and services offered are accurately represented. If a decision is made to submit a proposal, the instructions contained herein must be followed.   Bidders shall provide a summary of their qualifications in the proposals submitted.  Where the “bidder” represents a partnership, a summary of qualifications for each of the partners shall be included. During the bidding process, bidders, including all associated parties, may be asked to sign confidentiality agreements associated with this project. The successful bidder, including all associated parties, will be required to comply with and be signatory to the necessary data confidentiality agreement(s) that protects entities from inappropriate release of sensitive electric system information.    

7.1. Estimated Delivery and Implementation Schedule

The following schedule has been proposed to support NERC’s strategic business objectives.  Ideally, all proposals will fit within this schedule.  A timeline extending beyond these timelines may be proposed; and, as long as appropriate justification is presented, these proposals will still be considered. 

Page 36: NERC Alerts Project RFP

  

 

NERC Alert System RFP – 7/11/12  34 

The delivery of each phase will include testing, deployment, documentation and training, all to be delivered on or before the date specified below. 

 

Project Schedule 

Action  Delivery Date 

Project start  August 15, 2012 

Final acceptance  December 31, 2012 

 

 

 

7.2. Selection Schedule

The following schedule will be followed during the selection process: 

Selection Schedule 

Action  Date 

RFP Publication  July 13, 2012 

Deadline for submitting questions and clarifications 

July 18, 2012 

NERC responses to clarifying questions 

   July 20, 2012 

RFP Response submission  July 25, 2012 

Notification of winning vendor 

August 1, 2012 

 

7.3. Clarifications Process

Any questions regarding content within the RFP may be emailed to [email protected].  If appropriate, please refer to the specific section of the RFP when submitting questions.   

Questions and answers will be distributed by Justin Lofquist to all candidates through email communications. 

Page 37: NERC Alerts Project RFP

  

35  NERC Alert System RFP – April 2012 REV.: 1 

 

7.4. Qualifications

Describe your experience in producing applications for government and/or regulatory entity projects.  

Provide current reference information for three former or current clients. Please include the services your firm supplied, and include URLs of public‐facing sites your company was responsible for developing if possible.  

Briefly describe your firm’s organizational capacity to develop this solution (e.g. staff, equipment, software, physical space, office location, etc.).  

How many full‐time staff does your firm employ?  

Provide a company profile, length of time in business and core competencies.  

Briefly describe the percentage of your staff that would end of working on this project relative to your entire staff (using full time equivalents).  

Please describe the organizational makeup of the team assigned to the project, including roles, and minimum experience of resources filling those roles.   

Briefly describe your firm’s project management process.  

Describe the percent of total revenue derived from development projects and other business ventures.  

Explain your business model.  

Please discuss your testing and support plan.  

Please explain your service level agreement (SLA) structure.  

Please provide an estimated time frame for completion. Time frames will be part of the contractual agreement; therefore, a realistic time frame for completion is requested.  

Please describe your process and responsiveness to requests for product enhancements, after the product has gone to production.   

Please describe your process for include input from all business units. Please state how you intend to communicate with all business units areas to gather all of the required information.  

Please provide your company’s Terms and Conditions.   

7.5. Format for Proposal

Please use the following as a guideline to format your proposal:  

Length and Font Size:  

Please use fonts no smaller than 10 point. Maximum proposal length including title page, cover letter, proposal, qualifications and budget should not exceed 10 pages (not including Attachment).  

Title Page:  Please include the following information on the title page: 

NERC Alerts Project Proposal 

Page 38: NERC Alerts Project RFP

  

 

NERC Alert System RFP – 7/11/12  36 

Company Name 

Company Address 

Company Website 

Primary Contact 

Telephone Number 

Email Address  Proposal:  Discuss your proposed solution, including the features, benefits and uniqueness of your solution, including under what conditions the requirements in the RFP can be met (i.e hardware requirements).  You should also touch on your ability to deliver the project in the time frame noted.  Qualifications:  Provide the information requested in section “7.4 Qualifications”.   Budget and Fees:  List budgets as requested above. Identify staff you anticipate working on the project and their hourly rates for work that may be needed.   Please list out as a separate line item the cost to implement SMS functionality as part of the final solution.  Attachments:  Please include any additional information, such as screenshots of other similar projects, which will enhance your position as the most qualified provider for this solution. 

 

7.6. Contract Terms

NERC will negotiate contract terms upon selection. All contracts are subject to review by NERC’s legal counsel, and a project will be awarded upon signing of an agreement or contract, which outlines terms, scope, budget and other necessary items. 

 

7.7. Budgets

Please provide a cost proposal to accomplish the scope outlined below. The budget must encompass all project management, design, development, training, documentation, support and software acquisitions necessary for development and maintenance of the solution.  

This project will ideally be set as a fixed bid project.  However, additional contract types will be entertained, including cost + incentive fee, cost + shared variance, and T&M. 

 

Page 39: NERC Alerts Project RFP

  

37  NERC Alert System RFP – April 2012 REV.: 1 

7.8. Evaluation Criteria

The following criteria will form the basis upon which NERC will evaluate proposals. The mandatory criteria must be met and include:  

Bidders shall submit one copy of their proposal in electronic format, either Microsoft Word or Adobe PDF, no later than July 31st, 2012. Deliver electronic proposals to [email protected], with the subject line “<<Company Name>>’s proposal for the NERC Alerts project”. 

Your proposal must include a cost proposal as described above. All costs associated with the delivery of the project should be broken out in detail. The proposals shall be signed by the person authorized to act for the submitting party. The proposal should also indicate the time period for which it is valid. 

Proposals that meet the mandatory requirements, as stated above, will be evaluated with the following criteria:  

Proposer understands the project and has the ability to perform requirements (30%) o Understanding project objectives o Overall understanding of business requirements o Understanding of problem statement and end‐state vision o Completeness of response to requirements o Presentation of value‐adds and recommendations o Relevant, unidentified problems addressed 

 

Proposer's organization and management plan (15%) o Overall project organization (Org Chart) o Roles and Responsibilities o Proposed communication methods o Team Balance o Project schedule 

 

Project Methodology and Software Development Lifecycle Approach (15%) o Application to this project o Phases clearly defined o Deliverables, milestones and key decision points  o Tools and templates o High‐level work plan o Implementation strategy o Change management approach o PM Deliverables o Testing / training o Quality Assurance 

 

Proposer's corporate profile, experience and past performance (15%) o Accreditations / awards 

Page 40: NERC Alerts Project RFP

  

 

NERC Alert System RFP – 7/11/12  38 

o Management structure o Financial viability o On‐time delivery within budget o Overall exposure to government sector  o Experience with similar projects o Client satisfaction  o Quality of reference testimonials 

 

Cost (10%) o Initial project cost o Recurring costs o Cost justification 

 

Technical Solution (10%) o System Interface o Information storage and retrieval o Overall system design o Addresses technical requirements in the RFP o Solution is workable o Open, flexible and scalable o Cost‐effective to maintain 

 

Communication Skills and RFP Compliance (5%) o Clarity and readability of written proposal o Completeness of response o Overall professionalism and quality 

 

7.9. Award or Rejection of Bids

The contract will be awarded to one bidder, provided that the proposal is deemed reasonable and in the interest of NERC to accept. The bidder to whom the award is made will be notified at the earliest practical date. NERC reserves the right to reject any and all proposals and to waive any formality in proposals received whenever NERC deems such rejection or waiver to be in the best interest of NERC.  

8. Appendices  

8.1. Acronyms, Abbreviations, and Definitions

NERC: North American Electric Reliability Corporation 

Page 41: NERC Alerts Project RFP

  

39  NERC Alert System RFP – April 2012 REV.: 1 

BPS: (Bulk Power System) The collection of registered entities that supply power to the United States. 

Registered Entity:  An independent company that aids in serving energy to consumers through transmission and / or generation of electricity, and qualifies to be a member of the BES 

NCR: (NERC Compliance Registry Number) A unique number assigned by NERC to all Registered Entities 

ES_ISAC: Electricity Sector Information Sharing and Analysis Center 

RRM: NERC Risk and Reliability Management department 

Registered Function:  A function that a Registered Entity can perform within the industry (e.g. Generator Owner ‐ GO, Generator Operator ‐ GOP).  A Registered Entity can perform multiple registered functions. 

Subject Matter Area: A specific function that a specific user will perform.   

Functional Group: A collection all users that are members of a Registered Function  

Regional Staff: A system user that is not assigned to a NERC Registered Entity and is employed by one of the eight NERC Regions. 

Electric Sector Participant: Any user not assigned to a NERC Registered Entity and has been vetted by NERC staff as a member of the electric sector. 

Government Stakeholder Participant: Government users that are designated by NERC Staff (e.g.: FERC, Canadian Gov., Provinces, States, US DOE)  

NERC Defined List: A list of alert recipients created by the NERC Alert System Administrator.  

Designee: Any Functional Group Member that has been given privileges, by the registered entity’s Primary Compliance Contact (PCC) or Administrator, to acknowledge and/or respond for a Registered Function of a NERC Registered Entity  NERC Alert:  a notification that is distributed to Registered Entities which contains actionable information related to maintaining the reliability of the BPS.   There are three types of NERC Alerts:  Industry Advisory, Recommendation to Industry, and Essential Action  Industry Advisory:  A type of NERC Alert that is purely informational and is intended to alert Registered Entities to issues or potential problems. A response to NERC is not necessary.  Recommendation:  A type of NERC Alert that recommends specific action be taken by Registered Entities; requires a response from recipients as defined in the alert.  

Page 42: NERC Alerts Project RFP

  

 

NERC Alert System RFP – 7/11/12  40 

Essential Action:  A type of NERC Alert that identifies actions deemed to be “essential” to BPS reliability; requires NERC Board of Trustees approval prior to issuance.  This alert requires recipients to respond as defined in the alert. 

 

8.2. Roles and Permissions

The following table describes the initial permission settings for the application.  The System Administrator can modify any of these roles.  Additional roles and permissions may be defined during detailed requirements gathering. 

Roles and Permissions Matrix 

Permission 

Role 

System

 Administrator 

Primary Compliance Contact 

Administrator 

Compan

y Officer 

Regional Staff 

Functional Group M

embers 

Electric Sector Participan

Government Stakeholder 

Participan

NER

C Personnel  

Other 

Add/Deactivate Users Globally 

A  N  N  N  N  N  N  N  N  N 

Add/Deactivate Users Locally 

A  RE  RE  N  N  N  N  N  N  N 

Edit Local User Privileges  A  RE  RE  N  N  N  N  N  N  N 

Acknowledge  N  RE  N  RE  N  RE  N  N  N  N 

Respond  N  RE  N  RE  N  N  N  N  N  N 

Lock Responses  N  RE  N  RE  N  N  N  N  N  N 

View Alerts 

Public  Y  Y  Y  Y  Y  Y  Y  Y  Y  N 

Private  Y  RE  RE  RE  R  RE  AR  AR  Y  N 

Sensitive  Y  RE  RE  RE  R  RE  N  N  N  N 

Confidential  Y  RE  AR  AR  R  AR  N  N  N  N 

Page 43: NERC Alerts Project RFP

  

41  NERC Alert System RFP – April 2012 REV.: 1 

View Dashboards  A  RE  RE  RE  R  N  N  N  N  N 

View Acknowledgements  A  RE  RE  RE  R  Y  N  N  AL  N 

View Reponses  A  RE  RE  RE  R  N  N  N  AL  N 

Manage PCC Records  A  N  N  N  N  N  N  N  N  N 

Approvals  N  RE  N  RE  N  N  N  N  N  N 

Reporting  A  RE  RE  RE  R  N  N  N  Y  N 

Associate Users to Multiple Entities 

Y  N  N  N  N  N  N  N  N  N 

Create Alerts (and Response Templates) 

Y  N  N  N  N  N  N  N  Y  N 

Publish Alerts  Y  N  N  N  N  N  N  N  N  N 

  

Key 

A – All records AL – All alerts that the user created AR – As Required  N – No access O – Optional R – All records within the region RE – All records within the Registered Entity Y – Yes  

8.3. Supplemental Data

1. Regional Entities 

  FRCC ‐ Florida Reliability Coordinating Council  

MRO ‐ Midwest Reliability Organization  

NPCC ‐ Northeast Power Coordinating Council  

RFC ‐ Reliability First Corporation  

SERC ‐ SERC Reliability Corporation  

SPP ‐ Southwest Power Pool, RE  

TRE Texas Regional Entity  

WECC ‐ Western Electricity Coordinating Council   

Page 44: NERC Alerts Project RFP

  

 

NERC Alert System RFP – 7/11/12  42 

2. Registered Functions   

BA Balancing Authority 

DP Distribution Provider  

GO Generator Owner  

GOP Generator Operator  

IA Interchange Authority  

LSE Load‐Serving Entity 

PA Planning Authority  

PSE Purchasing‐Selling Entity  

RC Reliability Coordinator  

RP Resource Planner  

RSG Reserve Sharing Group  

TP Transmission Planner  

TO Transmission Owner  

TOP Transmission Operator  

TSP Transmission Service Provider   

3. Subject Matter Areas – including, but not limited to, the following:  

Security: Chief Security Officer  

Security: Physical Security  

Security: Cyber Security – Control Systems  

Security: Cyber Security – Corporate IT  

Operations: Engineering System Operators  

Operations: Engineering System Operators – System Protection  

Operations: Engineering System Operations – Transmission Engineering 

Operations: Engineering Generation Engineering  

Operations: Engineering Transmission Planning  

8.4. Alert Handling Levels

 

Public: No Restrictions. Will be posted to NERC’s website alert page. 

 Private: Restrict to Internal Use and Necessary Consultants / Third‐Party Providers 

Sensitive: Internal Use Only (Do Not Distribute Outside Your Company) 

Page 45: NERC Alerts Project RFP

  

43  NERC Alert System RFP – April 2012 REV.: 1 

 Confidential: Limited Internal Distribution Decided Upon by an Officer of the Company 

 

8.5. Sample Alert Email Notification

From: NERC Alerts Distribution To: NERC Alerts Distribution Subject: ADVISORY: <<insert subject line>> (NO RESPONSE REQUIRED) Date: Tuesday, April 10, 2012 9:01:18 AM  A NERC Industry Advisory regarding <<insert subject>> has been issued. The handling level for this alert has been set at green Public: No Restrictions. Will be posted to NERC's website alert page. “This Industry Advisory applies to All Registered Functions.”   The contents of this alert may be specifically useful to individuals with the following responsibilities: Physical Security, Cyber Security ‐ Control Systems, Cyber Security ‐ Corporate IT, System Operators, System Operators ‐ System Protection, System Operations ‐ Transmission Engineering, Generation Engineering, Transmission Planning, Generation Operations.  To view the alert please log in to the NERC Secure Alert System (https://www.nercalerts.com/) using your assigned username and password. If you are experiencing difficulties logging in, or cannot find your username or password, please click the "Forgot my username or password" link located on the login page.  Inquiries regarding the subject matter of this Industry Advisory should be directed to:  <<entity contact information>> North American Electric Reliability Corporation <<entity contact number>> 

<<entity contact email>>