# 1

AMI Enterprise Task ForceAMI Enterprise Task Forceof theof the

Utility AMI Working GroupUtility AMI Working Group

SRS Team Plan DiscussionFor further information, contact Joe Zhou

Team Lead (jzhou@xtensible.net)

# 2

AMI Enterprise Task ForceAMI Enterprise Task Force

Use CaseTeam

System RequirementsArticulation

Service DefinitionsTeam

SCE(Use Cases)

IEC TC57 WG14,Other Standards

Organizations

EPRIHomePlug & ZigBee

•Integration Requirements•Patterns•Sequence Diagram•Services•WSDL

Business-Oriented,Common FormatUse Cases

Recommendations to IEC TC57 WG14:•CIM Extensions•Message Type Updates•System Reqmt Updates

http://osgug.ucaiug.org/utilityami/AMIENT

MultiSpeak

# 3

SRS TeamSRS Team

• Goal: Generate System Requirements Specification (SRS)

• Team Leader: Joe Zhou (jzhou@xtensible.net)– 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 61968 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? What is Software Architecture?

Source: Software Architecture in PracticeSource: 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 CriteriaArchitecture Quality Attributes – Design Criteria

Source: Software Architecture in PracticeSource: Software Architecture in Practice

# 6

GridWise Interoperability Context-Setting GridWise Interoperability Context-Setting FrameworkFramework

# 7

AMI-Ent SRSAMI-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 StepsAMI-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