Use case methodology - Best practices in use case development for IEC standardization processes and some examples for application outside standardization

Use case methodology - Best practices in use case development for IEC standardization processes and some examples for application outside standardization

Regular price
£272.00
Sale price
£272.00
Regular price
£136.00
Sold out
Unit price
per 

What is BS IEC SRD 62559-4 about?  

BS IEC SRD 62559-4 specifies best practices for an entity to engage in a use cases redaction process to determine and describe their user requirements for systems, based on the business needs. It complements the information in IEC TR 62559-1, IEC 62559-2 and IEC 62559-3 by providing users with best practices in: 

  • Use cases drafting process 
  • Determining the skill sets of the people required 
  • Use case repository management 
  • Using use cases for IEC or enterprise projects. 

Who is BS IEC SRD 62559-4 for? 

BS IEC SRD 62559-4 on use case methodology is useful for: 

  • Research and development teams 
  • The domain experts and design engineers 
  • Project engineers 
  • The professionals who can execute the business decisions 

Why should you use BS IEC SRD 62559-4?  

BS IEC SRD 62559-4 was originally developed as part of the IntelliGrid Architecture developed by the Electrical Power Research Institute (EPRI) to implement the “IntelliGrid vision” of the automated, self-healing, and efficient power system of the future. However, the aim of BS IEC SRD 62559-4 has changed in such a way that it is now intended to describe a methodology that is generic enough to become applicable for all domains served by IEC or other standardization bodies. 

Implementing BS IEC SRD 62559-4 has the following benefits: 

  • Develop a standard methodology for determining and defining user requirements in a consistent and comprehensive manner. Standards often address only the technical issues that are included in technical specifications; however, it is just as vital to develop standards to assist users to clearly and comprehensively define their requirements. 
  • Clarifies the distinction between “user requirements” (the “what” as needed by domain system experts) and “technical specifications” (the “how” as technical descriptions of systems, applications, and information flows to meet the “what”). Currently this distinction is an “invisible line” so that often the “what” and the “how” are mixed together with technology-oriented project engineers jumping directly to the “how” without fully exploring the “what” with the domain system experts 
  • To emphasize the critical need to determine all user requirements first, before any commitments are made on “how” to meet those requirements. Because automation and control systems are so complex and are becoming increasingly so, if all requirements are not clearly defined first, then the premature design of systems can block or seriously hinder meeting those requirements that were not initially recognized. 
  • Provides a means for testing the systems once implemented to ensure that the user requirements are truly met, regardless of what standards and technologies are ultimately incorporated by the vendors