# 1 AMI Enterprise Task Force of the Utility AMI Working Group SRS Team Plan Discussion For further information, contact Joe Zhou Team Lead

# 2 AMI Enterprise Task Force Use Case Team System Requirements Articulation Service Definitions Team SCE (Use Cases) IEC TC57 WG14, Other Standards Organizations EPRI HomePlug & ZigBee Integration Requirements Patterns Sequence Diagram Services WSDL Business-Oriented, Common Format Use Cases Recommendations to IEC TC57 WG14: CIM Extensions Message Type Updates System Reqmt Updates MultiSpeak

# 3 SRS Team Goal: Generate System Requirements Specification (SRS) Team Leader: Joe Zhou –Similar scope and coverage as SRS created by Utility AMI WG’s OpenHAN TF. Include the following topics: A discussion of the reasons the Utility members of the AMI-Ent will undertake this work –Includes a glossary of terms Guiding Principles and the System Architecture –Includes an assessment of the IEC61968 Interface Reference Model (IRM) as a means for organizing information exchange requirements among utility business functions. A list system requirements not necessarily covered by business use cases. –This document would lay the foundation on which independent use cases and services would be defined. First Step: Assess IEC standards to determine gaps between the standard and what is needed for AMI- Enterprise scope. Make recommendations to fill gaps.

# 4 Software architecture is a result of technical, business, and social influences. The existence of the software architecture in turn affects the technical, business, and social environments that subsequently influence future architectures. Architecture stakeholders are: –Customer –End user –Sales and marketing –Competitor/Market –Development organization –Maintenance There is no such thing as an inherently good or bad architecture. Architectures are either more or less fit for some stated purposes. What is Software Architecture? Source: Software Architecture in Practice

# 5 System quality attributes discernable at runtime –Performance, Security, Availability, Functionality, Usability, Scalability System quality attributes NOT discernable at runtime –Modifiability, Portability, Reusability, Integrability, Testability Business Qualities –Time to market; Cost; Projected life time of the system; Targeted market; Rollout schedule; Extensive use of legacy system Qualities directly related to the architecture –Conceptual integrity; Correctness and completeness; Buildability Architecture Quality Attributes – Design Criteria Source: Software Architecture in Practice

# 6 GridWise Interoperability Context-Setting Framework

# 7 AMI-Ent SRS AMI-Ent SRS is a system requirements specification for how GridWise Interoperability Context-Setting Framework can be applied for AMI enterprise integration using well defined architectural practice. SRS Table of Content –Introduction –Guiding Principals –Architecture Considerations –AMI-Ent Functions and Logical Systems –AMI-Ent Requirements Refer to integration requirements from the Service Definition Team Develop a list of requirements that are not covered by the above –AMI-Ent Glossary of terms and definitions

# 8 AMI-Ent SRS Next Steps 1.Develop and agree on the initial scope (Table of Content) 2.Develop the following: (things are needed for other teams right away)  Glossary of terms and definitions  Guiding principals  AMI-Ent functional and logical systems model (leverage IEC 61968) 3.Develop AMI-Ent requirements  Address GridWise Interoperability Framework component as they apply to AMI-Ent  Address the rest of architectural requirements not covered by the Framework  Refer to other standards where they apply, identify gaps where exist. 4.Develop, review and finalize AMI-Ent SRS document for public comment