Presentation on theme: "EIDE System Requirements and Specification Documents"— Presentation transcript:
1EIDE System Requirements and Specification Documents WECC DEWG EIDE Training
2Overview What you will need to specify Identifying deliverables Specification boilerplate
3What you will need to specify Network infrastructureSecurityBack office interfacesData mappingTriggersError conditionsRedundancy
4Network 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 portsDumb listener with ability only to write documentsSomewhere in between
5Security requirements Any design you create must meet your security requirements and should be reviewed by the 1300 compliance monitor.Firewall policyDMZ policyAuthentication policyThis 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 DMZAuthentication policy, does it allow client mapping?
6Back 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?
7Data MappingHow 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.
8Triggers Timed transfers? Who sets these up and how? Manual transfers? What does the user interface look like?Will you do gets?
9Error conditionsWhat 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?
10Redundancy Dual internet connections through different vendors No single point of failureHot standby configurationsParallel configurationsFailover between database sessions
11Identify Deliverables Based on what tasks are to be performedAssign responsibilitiesSpecification documents can be created for each module with interfaces specified in eachDeliverables may include: System Requirements Document, System Design Document, Database Design, Detailed Design, Technical Documentation, User Documentation, Data Dictionary or Glossary, RFP, Statement of WorkSys 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.
12Specification boilerplate Introduction including project scope, specification overview, and description of existing systemsFunctional Requirements with subsections for each functional areaUser interface requirementsHardware and software requirementsSizing, expansion, performance, upgrade, testingDocumentation and TrainingMaintenance
13Functional Requirements Should specify “what” rather than “how” with exceptions where requiredShould allow for creative implementationsIdentify which methods will be requiredIdentify any specific implementation requirements for back office interfacesHow 23 and 25 hour day is handledHow data is mapped
14EIDE 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:MMData from EMS and scheduling system can be sent using either PutSchedule or PutMeterMessages received will be displayed at the _______ console in a popup box
15EIDE SpecificationCompliance with schema and communications protocol documentAbility to integrate schema modificationsFunctional requirements include validation of received documents based on your own business rules, back end system interfacesUser 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
16EIDE SpecFunctional requirements should also specify data translation requirements, whether gets will be used, etc.Should also include timing requirements if there are anyBe sure to include 23 and 25 hour day handling, data compression, error conditions, etc.
17RFP and SOW boiler plate Needs to include:Terms and conditionsResponsibilities, 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 proceduresAny company specific requirements
18Tool choicesThere are many good tools available for describing the functional requirementsThese include DFD, UML, relationship charts for database…