BS IEC SRD 62559-4:2020
$167.15
Use case methodology – Best practices in use case development for IEC standardization processes and some examples for application outside standardization
| Published By | Publication Date | Number of Pages |
| BSI | 2020 | 42 |
IEC SRD 62559-4:2020 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, and – using use cases for IEC or enterprise projects.
PDF Catalog
| PDF Pages | PDF Title |
|---|---|
| 2 | undefined |
| 4 | CONTENTS |
| 6 | FOREWORD |
| 8 | INTRODUCTION 0.1 General 0.2 Objectives of this document |
| 10 | 1 Scope 2 Normative references 3 Terms, definitions and abbreviated terms 3.1 Terms and definitions |
| 11 | 3.2 Abbreviated terms 4 Overview of the methodology 4.1 Concept of systems engineering 4.2 Systems engineering methodology for use case development 4.2.1 General |
| 12 | Figures Figure 1 – Project definition process |
| 13 | 4.2.2 Overview of the phased approach 4.2.3 Phase 1: Methodology for executives |
| 15 | 4.2.4 Phase 2: Modelling user requirements with use cases Figure 2 – Internal and external stakeholders for the ATM example |
| 17 | Figure 3 – Use case workshop process |
| 18 | Figure 4 – Graphically drafted business use case for the ATM example |
| 19 | Figure 5 – Graphically drafted system use case for the ATM example |
| 20 | Tables Table 1 – Use case scenario description according to IEC 62559-2 |
| 21 | Table 2 – Use case information object description according to IEC 62559-2 Table 3 – Use case requirement description according to IEC 62559-2 |
| 22 | Figure 6 – Sequence diagram showing the appropriate boundariesof exchange in the step-by-step analysis |
| 23 | Figure 7 – Sequence diagram showing an inappropriate levelof detail of information exchange |
| 24 | 4.2.5 Phase 3: Methodology for project engineers: developing detailed user requirements Figure 8 – Flow diagram for alternate (error) scenarios |
| 26 | Table 4 – Examples of poorly-formed requirements and requisite improvement |
| 27 | 4.3 Use of Unified Modelling Language (UML) 4.3.1 General Figure 9 – Base plane of the SGAM showing its requisite domains and zones |
| 28 | 4.3.2 Use case diagram 4.3.3 Scenario flow chart Figure 10 – Example use case diagram showing actors,assumptions, objectives and preconditions. |
| 29 | 4.3.4 Activity diagram Figure 11 – Example use case diagram scenario flow |
| 30 | Figure 12 – Example activity diagram using Unified Modelling Language showingthe interaction of ATM operator bank, contractual bank, and a customer |
| 31 | Figure 13 – Example activity diagram with object flow Figure 14 – Example for use case modelling down to data flow modelling |
| 32 | 4.3.5 Sequence diagram 4.3.6 Data class diagram 4.4 Determining the quality of a use case 4.4.1 General Figure 15 – Example UML data class diagram showing the elements of a use case |
| 33 | 4.4.2 Considerations for use case management and collaborative working Figure 16 – Use case lifecycle process |
| 34 | 4.4.3 Version numbering 4.4.4 Management of use case overarching topics like actors, information objects or requirements |
| 35 | 4.4.5 Actor hierarchy und multiple instances of an actor Figure 17 – Management of use case overarching topics Figure 18 – Translation of a technical architecture into an actor hierarchy |
| 36 | 4.5 Coordination of parallel system use case supporting the same business use case 4.5.1 General |
| 37 | 4.5.2 Decomposition of coordinated high-level use case into sets of low-level use cases, maximizing the use of already existing elements of standards (e.g. implantation example use case) 4.5.3 Perform gap analysis to identify necessary standardization work Figure 19 – Mapping business processes with standards and components |
| 38 | 4.5.4 Components as the linking element between use cases, reference architectures model and standards 4.6 Outlook to support cooperation of different contributing domains by identifying cross standardization groups use cases Figure 20 – Components as the linking element between use cases,reference architecture models and standards |
| 39 | Figure 21 – Actor naming in cross-domain use cases |
| 40 | Bibliography |
