1. EIDE System Requirements and Specification Documents
WECC DEWG EIDE Training

2. Overview What you will need to specify Identifying deliverables
Specification boilerplate

3. What you will need to specify
Network infrastructure
Security
Back office interfaces
Data mapping
Triggers
Error conditions
Redundancy

4. Network infrastructure
How can you use your existing network infrastructure to meet your security and functionality requirements?
Possibilities include:
Smart listener with code and access to back office through secure sockets or ports
Dumb listener with ability only to write documents
Somewhere in between

5. Security requirements
Any design you create must meet your security requirements and should be reviewed by the 1300 compliance monitor.
Firewall policy
DMZ policy
Authentication policy
This is not because the interface is necessarily critical, it is because of the interface to the potentially critical systems.
Firewall – are ports allowed to be opened inbound, is anything outbound restricted?
DMZ – can systems be placed in the DMZ
Authentication policy, does it allow client mapping?

6. Back office interfaces
Which systems will you be getting data from and sending data to?
How? Database, file, three tier?
Can changes to the back office systems be isolated from the gateway?
What methods will be implemented?
How will you ensure reliability?

7. Data Mapping
How will you flexibly map data between your system and others?
EIDE protocol is flexible and allows various methods.
Database structure and programming logic can allow any combination.
Hierarchical approach can be used.

8. Triggers Timed transfers? Who sets these up and how? Manual transfers?
What does the user interface look like?
Will you do gets?

9. Error conditions
What happens when you get an invalid inbound document?
What happens when your database is temporarily down?
What happens when you can’t find a path for a file write?
What happens when the receiver system is down?
How are timeouts and bad responses handled?
Do you need acknowledgement?
How are bad responses handled? Do you need acknowledgement?

10. Redundancy Dual internet connections through different vendors
No single point of failure
Hot standby configurations
Parallel configurations
Failover between database sessions

11. Identify Deliverables
Based on what tasks are to be performed
Assign responsibilities
Specification documents can be created for each module with interfaces specified in each
Deliverables may include: System Requirements Document, System Design Document, Database Design, Detailed Design, Technical Documentation, User Documentation, Data Dictionary or Glossary, RFP, Statement of Work
Sys req contains a specification of functions defines “what”, sys design contains high level data flows and defines “how”, detailed design contains specifics of how, including physical design details.

12. Specification boilerplate
Introduction including project scope, specification overview, and description of existing systems
Functional Requirements with subsections for each functional area
User interface requirements
Hardware and software requirements
Sizing, expansion, performance, upgrade, testing
Documentation and Training
Maintenance

13. Functional Requirements
Should specify “what” rather than “how” with exceptions where required
Should allow for creative implementations
Identify which methods will be required
Identify any specific implementation requirements for back office interfaces
How 23 and 25 hour day is handled
How data is mapped

14. EIDE requirement examples
Data sets containing a combination of EMS and Scheduling information can be configured to trigger each hour at HH:MM, each day at XX:MM, each week at XX:MM
Data from EMS and scheduling system can be sent using either PutSchedule or PutMeter
Messages received will be displayed at the _______ console in a popup box

15. EIDE Specification
Compliance with schema and communications protocol document
Ability to integrate schema modifications
Functional requirements include validation of received documents based on your own business rules, back end system interfaces
User interface requirements include both administrative and user.
Meter data accepted only in the past, schedules only in the future, schedules only 3 days back unless operator override, meters only 3 days back, max number of days to accept into the future

16. EIDE Spec
Functional requirements should also specify data translation requirements, whether gets will be used, etc.
Should also include timing requirements if there are any
Be sure to include 23 and 25 hour day handling, data compression, error conditions, etc.

17. RFP and SOW boiler plate
Needs to include:
Terms and conditions
Responsibilities, deliverables, schedule, disclosure, termination, performance, project rights, agreement on definition and handling of work outside scope, invoicing and payments, software license/ownership,etc.
Project organization and procedures
Any company specific requirements

18. Tool choices
There are many good tools available for describing the functional requirements
These include DFD, UML, relationship charts for database…