Initial Report on Guidelines for Systems Engineering for SoS. Document Number: D21.3. Date: September Public Document

Transcription

1 Project: COMPASS Grant Agreement: Comprehensive Modelling for Advanced Systems of Systems Initial Report on Guidelines for Systems Engineering for SoS Document Number: D2.3 Date: September 203 Public Document

2 D2.3 Initial Report on Guidelines for Systems Contributors: Jon Holt (JDH), ATEGO Simon Perry (SAP), ATEGO Finn Overgaard Hansen (FOH), IHA Alvaro Miyazawa (AM), UY Klaus Kristensen (KK), B&OA Ralph Hains (RH), ATEGO Editors: Simon Perry, ATEGO Jon Holt, ATEGO Reviewers: Richard Payne, UNUT Alvaro Miyazawa, UY Sune Wolff, B&O 2

3 D2.3 Initial Report on Guidelines for Systems Document History Release Versions Version Date Author Description S. Perry Initial complete version for review by COMPASS members A. Larkham Address internal review comments S. Perry Additional comments addressed. Pre-release versions Version Date Author Description S. Perry Initial draft outline version incomplete S. Perry Started work on Section S. Perry Sections 3 & 4 complete S. Perry Section 7 ed S. Perry Section 7 complete S. Perry Restructure; new Section 3 added S. Perry Section 6 complete; section complete; abstract written; section completed S. Perry Sections 2 & 9 added A. Miyazawa Section 0.3 added S. Perry Section 7 completed R.Hains Section 0.2 added 3

4 D2.3 Initial Report on Guidelines for Systems Abstract This deliverable contains a summary of the COMPASS approach to System of Systems engineering (SoSE). The COMPASS approach consists of two key parts, the COMPASS Architectural Framework and the COMPASS Process Library. Each of these are described, bringing together the relevant Ontologies, Frameworks and Process from contributing COMPASS deliverables. A number of Scenarios are discussed showing how the various elements of the approach are used in the development or maintenance of a System of Systems (SoS). In order to successfully carry out SoSE, it is important to have people with the correct skills. A number of Competency Scopes are presented that cover the Stakeholder Roles involved in all of the COMPASS SoSE Processes defined to date. 4

5 D2.3 Initial Report on Guidelines for Systems Table of Contents. Introduction Scope Context Writing Convention Existing Best Practice Guidelines The COMPASS Approach The COMPASS Ontology The Existing COMPASS Ontologies The Full COMPASS SoSE Ontology The COMPASS Architectural Framework The Existing COMPASS Frameworks The Combined Framework The COMPASS Processes and Guidelines SoS Requirements Processes Architectural Framework Processes Architecture Guidelines System Integration Processes Application of the COMPASS Approach Life Cycles and Life Cycle Models Application to SoS Development Application to SoS Maintenance Application to COMPASS Case Studies Competence and SoSE The Competence Ontology Example Competency Scopes Configuration Manager Competency Scope Requirement Manager Competency Scope Project Manager Competency Scope Requirement Engineer Competency Scope Systems Modeller Competency Scope Tester Competency Scope Reviewer Competency Scope Process Modeller Competency scope Builder Competency Scope SoS Engineer Competency Scope Compliance Tool Support Atego Process Director Artisan Studio CML Toolset Conclusions References Appendix I The COMPASS SoSE Ontology

6 D2.3 Initial Report on Guidelines for Systems 4. Appendix II The COMPASS Architectural Framework Appendix III - Summary of the COMPASS Processes and Guidelines 77 6

7 D2.3 Initial Report on Guidelines for Systems Figures Figure - Overview of the COMPASS Approach... 3 Figure 2 - Ontology Definition View focussing of SoS Requirements... 5 Figure 3 - Ontology Definition View focussing on Processes and Competency... 5 Figure 4 - Ontology Definition View focussing on Architectures and Architectural Frameworks... 6 Figure 5 - Ontology Definition View focussing on Integration... 6 Figure 6 - Ontology Definition View focussing on traceability... 7 Figure 7 - The full COMPASS SoSE Ontology... 8 Figure 8 - Relationships View for the COMPASS SoS-ACRE Requirements Framework Figure 9 - Relationships View for the Seven Views Process Framework Figure 0 - Relationships View for the COMPASS Architectural Framework Framework (CAFF)... 2 Figure - Relationships View for the Integration Framework... 2 Figure 2 - Relationships View for the Traceability Framework Figure 3 - Relationships View for the COMPASS Architectural Framework Figure 4 - Relationships View for the COMPASS Architectural Framework showing overlapping packages to highlight shared s Figure 5 - Process Content View showing COMPASS Process Library Process Groups Figure 6 - Process Content View for System of Systems Requirements Engineering Process Group Processes Figure 7 - Process Content View for System of Systems Requirements Management Process Group Processes Figure 8 - Process Content View for Architectural Framework Group Processes... 3 Figure 9 - Process Content View for Integration Technical Group Processes Figure 20 - Process Content View for Integration Management Group Processes Figure 2 - Example Life Cycle - the Stages of ISO5288: Figure 22 - Typical Life Cycle Stages covered by COMPASS approach Figure 23 - Typical Life Cycle Stages covered by COMPASS approach for an existing System Figure 24 COMPASS Processes executed during the Conception Stage for the development of a new System... 4 Figure 25 COMPASS Processes executed during the Conception Stage for the development of an existing System Figure 26 COMPASS Processes executed during the Development Stage Figure 27 COMPASS Processes executed during the Production Stage Figure 28 Overall Life Cycle Model for a maintenance Project with change detected during Support Stage Figure 29 COMPASS Processes executed during the Support Stage Figure 30 - Ontology Definition View focussing on Competence

8 D2.3 Initial Report on Guidelines for Systems Figure 3 Competency Scope for Configuration Manager Stakeholder Role based on the INCOSE Systems Engineering Competencies Framework Figure 32 Competency Scope for Requirement Manager Stakeholder Role based on the INCOSE Systems Engineering Competencies Framework Figure 33 Competency Scope for Project Manager Stakeholder Role based on the INCOSE Systems Engineering Competencies Framework... 5 Figure 34 Competency Scope for Requirement Engineer Stakeholder Role based on the INCOSE Systems Engineering Competencies Framework Figure 35 Competency Scope for Systems Modeller Stakeholder Role based on the INCOSE Systems Engineering Competencies Framework Figure 36 Competency Scope for Tester Stakeholder Role based on the INCOSE Systems Engineering Competencies Framework Figure 37 Competency Scope for Reviewer Stakeholder Role based on the INCOSE Systems Engineering Competencies Framework Figure 38 Competency scope for Process Modeller Stakeholder Role based on the INCOSE Competencies Framework Figure 39 Competency Scope for Builder Stakeholder Role based on the INCOSE Systems Engineering Competencies Framework Figure 40 Competency Scope for SoS Engineer Stakeholder Role based on the INCOSE Systems Engineering Competencies Framework Figure 4 - The full COMPASS SoSE Ontology Figure 42 - Relationships View for the COMPASS Architectural Framework Tables Table - Example sentences to illustrate the convention... Table 2 - Summary of Best Practice Sources Used... 2 Table 3 - Original sources for Ontologies... 7 Table 4 - Original sources for Frameworks Table 5 - Summary of the COMPASS SoS Requirements Processes Table 6 - Summary of the COMPASS Architectural Framework Processes Table 7 - Summary of the COMPASS Architecture Guidelines Table 8 - Summary of the COMPASS System Integration Processes Table 9 - Compliance Information in Input Documents Table 0 - Descriptions of Ontology Elements Table - Descriptions of s Table 2 - Summary of the COMPASS Processes and Guidelines

9 D2.3 Initial Report on Guidelines for Systems. Introduction This section defines the scope and context for this report. Also included in this section is a set of writing conventions that will be used throughout this report... Scope This document presents the initial report on the Guidelines for System of Systems (SoS) Engineering (SoSE). It brings together the Guidelines on Requirements engineering, Architectural Framework definition, production of System Architectures and System Integration found in previous COMPASS deliverables. The Ontologies, Frameworks and Processes or Guidelines found in these deliverables are combined into an over-arching COMPASS approach that consists of the COMPASS Architectural Framework and the COMPASS Process Library. A number of Scenarios are discussed showing how the various elements of the approach are used in the development or maintenance of an SoS. Consideration is given to the tool support that is provided for the dissemination of the approach, the modelling of a SoS through both SyML and CML and formal reasoning about models. In order to carry out SoSE successfully, it is necessary to have people in place with the necessary skills. A Competency Ontology is presented, along with a number of Competency Scopes that cover the Stakeholder Roles involved in all of the COMPASS SoSE Processes defined to date..2. Context This report contains the initial version of the COMPASS approach. It is intended to be an overview of the approach based on the following documents: Report on Guidelines for SoS Requirements [D2. 202] Initial Report on Guidelines for Architectural Level SoS Modelling [D ] Report on Guidelines for System Integration for SoS [D ] This report brings together the content of the above documents into a summary of the approach, updating the material abstracted from those documents where necessary to address any inconsistencies that have resulted from advances in the research since the documents were originally issued. No additional content has been added on the approach in this document, other than the material on Competence. The final version of this document, D2.6 Final Report on Guidelines for SoS Engineering, will complete the approach; additional material expected to be included will cover refinement, evolution, testing, the definition of Competency 9

10 D2.3 Initial Report on Guidelines for Systems Frameworks and the carrying out of Competency assessments, and the modelling and definition of Processes..3. Writing Convention The following writing conventions are adopted in this report: All terms from the SysML notation, that form part of the standard, are written in italics. Therefore, the use of block refers to the SysML construct, whereas the same word without italics block refers to an impediment. All terms that are defined as part of the overall COMPASS model, such as the COMPASS Ontology, COMPASS Framework, etc. are presented with capitalised words. Therefore the use of Need refers to the Ontology Element, whereas the same word without capitals need refers to a non-specific usage of the term as a noun or verb. All words that are being referenced from a specific diagram are shown in quotes. Therefore, the use of Need is referring to a specific element in a specific diagram. All View names are shown as singular. Therefore, the term Process Behaviour View may be referring to any number of diagrams, rather than a single one Any word that requires emphasis is shown in double quotes. Some examples of this are: Example sentence A Use Case may be visualised as a use case Engineering activity can be shown as an Activity on a Process and may be visualised as an activity Meaning Use Case term from the COMPASS Ontology use case the term from SysML notation activity the everyday usage of the word Activity the term from the MBSE Ontology activity the term from the SysML notation 0

11 D2.3 Initial Report on Guidelines for Systems Example sentence The diagram here shows the COMPASS Process Framework is made up of one or more Process Behaviour View When defining Processes it is typical to create a number of activity diagrams that will visualise the Process Behaviour View. Meaning COMPASS Process Framework a specific term from a specific diagram that is being described. Process Behaviour View a specific term from a specific diagram that is being described. Processes the term from the COMPASS Ontology. activity diagram the term from SysML notation. It is important to understand the why of MBSE Process Behaviour View the term from the COMPASS Framework why emphasis of the word Table - Example sentences to illustrate the convention The table here shows some example sentences, the convention adopted and how they should be read. In summary, consideration must be given to Quotes, Capitalisation and italics as these have specific meaning. Finally, the use of double quotes simple represents emphasis.

12 SoSE area DoD SoS Guidelines [DoD202] ISO 5288 [ISO5288:2008] ISO 4200 [ISO4200:20] INCOSE Systems Engineering Competencies Framework [INCOSE 200] OTHER KEY INPUTS D2.3 Initial Report on Guidelines for Systems 2. Existing Best Practice Guidelines In developing the COMPASS approach, a number of best practice sources were consulted and used as significant inputs to the reports covering SoS Requirements engineering, Architectures and Architectural Frameworks and System Integration. A number of best practice sources were also consulted and used as inputs to the additional material on Competence and Competency Frameworks found in this report. The best practice material abstracted from each is described in each input report. Table 2 provides a summary of the main source elements used in each COMPASS report used as an input to this document. For details, see the relevant report. SoS Requirements Engineering [D2. 202] Architectural Frameworks [D ] Architectures [D ] System Integration [D ] Competence (this document) Yes Yes No No [Lewis et al 2009] No No Yes No [TRAK 203] Yes Yes No No [Dickerson & Mavris 2009] Yes Yes No No [D ] No No No Yes [APM 203] [SFIA 203] Table 2 - Summary of Best Practice Sources Used In addition to the best practice sources explicitly used and referenced by the various reports that input into this report, COMPASS deliverable D.2 Convergence Report 2 [D.2 203] includes information on the current state of the common concept definitions which are being developed as the project Wiki ; and an analysis of the common characteristics of the range of case studies examined in the project. This provides essential background information to anyone engaging in SoSE. See Section 2 of [D.2 203] for further details. 2

13 D2.3 Initial Report on Guidelines for Systems 3. The COMPASS Approach The COMPASS approach to SoSE is summarised in Figure. bdd [Package] COMPASS Approach [Main Elements of the COMPASS Approach] Perspective can be used to realise SysML collects together can be used to realise COMPASS Architectural Framework supports Enabling Pattern uses elements from can be used to realise Ontology can be used to realise CML produces COMPASS Process Library Process Figure - Overview of the COMPASS Approach The COMPASS approach consists of two key parts, the COMPASS Architectural Framework and the COMPASS Process Library. The COMPASS Architectural Framework consists of an Ontology and one or more. The Ontology defines the concepts relevant to the approach, along with the relationships between these concepts. Each uses elements from the Ontology to define a standard View that can be produced as the visualisation of part of the Architecture of a System. One or more Perspective collect together one or more related. The Ontology is further discussed in Section 4 and the s in Section 5. The COMPASS Process Library is composed of one or more Process. Each Process addresses an aspect of SoSE and produces one or more (or, more correctly, one or more Views that conform to s). The Processes that make up the COMPASS approach are discussed further in Section 6. Each of the COMPASS Architectural Framework is supported by zero or more Enabling Pattern. For information on Enabling Patterns, see [D ]. Finally, the systems modelling language (SysML) and COMPASS modelling language (CML) can be used to realise the Enabling Patterns and the s. An example of this can be seen in [D ] where both SysML and CML are used to realise Integration s. 3

14 D2.3 Initial Report on Guidelines for Systems 4. The COMPASS Ontology The COMPASS Ontology identifies and defines all of the terms and concepts that are used in the project and is a basis for the definition of the various Frameworks and supporting Processes that have been produced. In the Guidelines produced so far the Ontology Elements relevant to the subject under consideration, such as Requirements or Architectures, have been presented as a partial Ontology, albeit related one to another across deliverables. In this section, each of these Ontologies is brought together into a whole overarching COMPASS SoSE Ontology. In Section 4. each of the existing Ontologies is presented, with little or no comment, for reference, before being brought together as a whole in Section 4.2. Any inconsistencies discovered in the material presented in previous deliverables have been corrected in the full Ontology presented here. Some additional content relating to Competence has also been added to support the material presented in Section 8. This full Ontology is intended to form a useful source of information for anyone engaged in SoSE, showing how the various areas covered by COMPASS relate one to another. It also ensures the consistency of the various Frameworks covered by the COMPASS Guidelines. These Frameworks are themselves brought together into a whole in Section 5.2. It should be noted here that the full COMPASS SoSE Ontology presented in Section 4.2 will be revisited and expanded in the final version of this deliverable, D2.6 Final Report on Guidelines for SoS Engineering. 4.. The Existing COMPASS Ontologies This section contains the existing COMPASS Ontologies that are found in a number of other COMPASS documents. An Ontology Definition View (one of the s defined in the COMPASS Architectural Framework Framework (CAFF), see [D ]) is given for each of the existing Ontologies. Each Ontology is presented without comment, except where changes have been made to the original version in order to address either consistency issues or in order to bring the Ontologies in line with research conclusions developed since publication of the originals. Figure 2 shows the Ontology developed for SoS Requirements. Full details can be found in [D2. 202]. 4

15 D2.3 Initial Report on Guidelines for Systems ODV [Package] Ontology Definition View [SoS Requirements] Formal Scenario Rule constrains describes the context of validates Scenario Source Element Need Use Case Semi-formal Scenario is elicited from Context Goal Capability Requirement System Context Stakeholder Context System represents the need for Constituent System System of Systems Virtual Acknowledged Collaborative Directed Figure 2 - Ontology Definition View focussing of SoS Requirements Figure 3 shows the Ontology developed for Processes and Competency. This is based on the one found in Appendix I of [D2. 202]. It has been expanded here to cover more concepts relating to Competency, namely Competence, Competency Area, Competency, Level (and its types) and Indicator. For a discussion of these concepts see Section 8. ODV [Package] Ontology Definition View [Process & Competency Concepts] interacts with Life Cycle Interaction Point System describes the evolution of Life Cycle is executed during Stage assesses the execution of Gate Process Execution Group describes measured abilities of exhibits describes measured is executed during holds Person Competency Profile Competence Competency Area Process describes desired classifies is assessed against Artefact Stakeholder Role Resource Competency Scope Level is held at Competency produces/consumes Activity is responsible for consumes requires Awareness Level Lead Level Indicator Support Level Expert Level Figure 3 - Ontology Definition View focussing on Processes and Competency Figure 4 shows the Ontology developed for Architectures and Architectural Frameworks. Full details can be found in [D ]. One small change has been made to the Ontology. The multiplicity on the association between the Perspective and blocks has been changed from to at the 5

16 D2.3 Initial Report on Guidelines for Systems Perspective end. This has been done to reflect the re-use of s in multiple Perspectives, which will be discussed in Section 5.2 below. ODV [Package] Ontology Definition View [AFs & Architectures] Architectural Framework describes structure of Architecture describes is related to constrains Rule complies with Architectural Framework represents need for Concern System Standard represents need for is derived from Concern provides provenance for is related to Ontology uses elements from conforms to View is related to {via} collects together Perspective collects together Ontology Element corresponds to Element visualises View Element is related to Figure 4 - Ontology Definition View focussing on Architectures and Architectural Frameworks Figure 5 shows the Ontology developed for SoS Integration. Full details can be found in [D ]. ODV [Package] Ontology Definition View [Integration] System Context Flow Type System Element System represents the need for uses owns Interface Definition describes exposes Port Constituent System System of Systems is connected to Interface conforms to Protocol is connected to Port Connection Virtual Acknowledged conforms to Collaborative Directed Service-based Interface Flow-based Interface Interface Connection takes place across Figure 5 - Ontology Definition View focussing on Integration Figure 6 shows the Ontology developed for traceability. It is taken from the traceability pattern, one of the enabling patterns found in [D ]. Although not presented as a separate Framework in [D ], the pattern nevertheless defines a set of concepts that can (and should) be applied across all the other Frameworks. 6

17 D2.3 Initial Report on Guidelines for Systems ODV [Package] Ontology Definition View [Traceability] Traceability Relationship Relationship Type Traceable Element {Abstract} defines the type of Traceable Type {Abstract} is traceable to can be traced to View Element View View Type Element Type defines the type of defines the type of Figure 6 - Ontology Definition View focussing on traceability The references for these Ontologies are summarised below: Ontology Original Deliverable SoS Requirements [D2. 202] Report on Guidelines for Process and Competency SoS Requirements Architectures and Architectural [D ] Initial Report on Frameworks Guidelines for Architectural Level SoS Modelling SoS Integration [D ] Report on Guidelines for System Integration for SoS Traceability [D ] Report on Modelling Patterns for SoS Architecture Table 3 - Original sources for Ontologies 4.2. The Full COMPASS SoSE Ontology The five separate Ontologies presented in Section 4. are pulled together into a single Ontology in Figure 7 below. The diagram in Figure 7 is reproduced in Appendix I, which also contains a glossary of the Ontology Elements found on the diagram. 7

18 D2.3 Initial Report on Guidelines for Systems ODV [Package] Ontology Definition View [Full Ontology] is related to Rule constrains Source Element is elicited from constrains Goal Architectural Framework describes structure of Architecture complies with Architectural Framework Concern represents need for Standard is derived from provides provenance for Concern represents need for is related to Ontology uses elements from View conforms to collects together Perspective collects together Ontology Element Element visualises View Element is related to corresponds to is related to Traceability Relationship Relationship Type Traceable Element Traceable Type {Abstract} defines the type of {Abstract} is traceable to can be traced to View Element View View Type Element Type defines the type of defines the type of Formal Scenario describes the context of validates Scenario Semi-formal Scenario Need Use Case Context interacts with Requirement Capability Life Cycle represents the need for System Context Stakeholder Context Life Cycle Interaction Point describes System describes the evolution of is executed during Stage Gate assesses the execution of exhibits Process Execution Group describes measured abilities of describes measured holds is executed during Person Competency Profile Constituent System System of Systems Process describes desired Competence is assessed against Artefact Stakeholder Role Resource Virtual Acknowledged Competency Scope Level is held at produces/consumes Collaborative Directed Activity is responsible for requires consumes Awareness Level Lead Level Note that View and View Element used here are the System Element Flow Type Support Level Expert Level same as those used below as types of Traceable Element. owns uses Port Interface Definition is connected to exposes describes conforms to Port Connection Protocol Interface conforms to is connected to Service-based Interface Flow-based Interface takes place across Interface Connection Competency Area classifies Competency Indicator Figure 7 - The full COMPASS SoSE Ontology 8

19 D2.3 Initial Report on Guidelines for Systems 5. The COMPASS Architectural Framework In the Guidelines produced so far the Frameworks relevant to the subject under consideration, such as Requirements or Architectures, have been presented as separate Frameworks, albeit related one to another across deliverables. In this section, each of these Frameworks is brought together into a whole over-arching COMPASS Architectural Framework (COMPASS-AF). Note that this is different from the CAFF. The latter is an Architectural Framework (AF) for defining AFs; the former is an AF that has been developed using the CAFF. In Section 5. each of the existing Frameworks is presented, with little or no comment, for reference, before in Section 5.2, being brought together as a whole. Any inconsistencies discovered in the material presented in previous deliverables have been corrected in the full COMPASS-AF presented here. It should be noted here that the COMPASS-AF presented in Section 5.2 will be revisited and expanded in the final version of this deliverable, D2.6 Final Report on Guidelines for SoS Engineering. Additional material expected to be included will include s and Perspectives to cover Competence, refinement, evolution and testing. 5.. The Existing COMPASS Frameworks This section contains the existing COMPASS Frameworks that are found in a number of other COMPASS documents and that are based on the Ontologies presented in Section 4.. A Relationships View (one of the s defined in the CAFF, see [D ]) is given for each of the existing Frameworks, with the Framework represented as a Perspective through the use of a SysML package. Each Framework is presented without comment, except where changes have been made to the original version in order to address either consistency issues that have been discovered since the original documents were issued or in order to bring the Frameworks in line with research conclusions developed since publication of the originals. Figure 8 shows the Framework developed for SoS Requirements. Full details can be found in [D2. 202]. Note that in [D2. 202] each of the s are named as Views. For example, in [D2. 202] the Validation is named the Validation View. The renaming from View to has been done here to bring the concepts in line with those found in the CAFF where a represents the definition and a View represents an instance of a. As can be seen in Figure 4 (and Figure 7) an Architectural Framework is made up of s, whereas an Architecture which conforms to an Architectural Framework is made up of Views. 9

20 D2.3 Initial Report on Guidelines for Systems VRV [Package] Relationships View [Requirements Perspective] Requirements Perspective Validation Interaction satisfies Context Interaction Source Element combines expands identifies sources of needs on Context Definition Requirement Context Requirement Description defines context for validates use case on defines needs in context from defines constraints on descriptions of needs on combines Validation Definition Rule Set Figure 8 - Relationships View for the COMPASS SoS-ACRE Requirements Framework Figure 9 shows the Framework developed for Process modelling. This is based on the one found in Appendix I of [D2. 202]. Again, to bring terminology in line with the CAFF, all the Views found in [D2. 202] have been renamed as s. Note also that although the Ontology on which this Framework is based (Figure 3) includes some concepts relating to Competency, no s that cover these concepts are found in [D2. 202]. A Competency Perspective will be developed and presented in the final version of this deliverable, D2.6 Final Report on Guidelines for SoS Engineering. VRV [Package] Relationships View [Process Perspective] Process Perspective Process Instance shows validation of processes from Requirement Context identifies processes that meet the requirements from defines ontology for Process Structure Process Content identifies stakeholder oles for processes from identifies artefacts for processes from Stakeholder Information defines behaviour of processes from Process Behaviour Figure 9 - Relationships View for the Seven Views Process Framework Figure 0 shows the Framework developed for Architectures and Architectural Frameworks the CAFF, based on the Ontology in Figure 4. Full details can be found in [D ]. 20

21 D2.3 Initial Report on Guidelines for Systems VRV [Package] Relationships View [AF & Architectures Perspective] AF & Architectures Perspective AF Context is derived from Ontology Definition Rules Definition is derived from Context defines viewpoint using elements from Definition is derived from {The Rules Definition is related to ALL the other s and defines the Rules that constrain the Architectural Framework. Relationships to the other s are omitted from this diagram for clarity.} Relationships defines viewpoint to meet needs from defines relationships between viewpoints defined in Figure 0 - Relationships View for the COMPASS Architectural Framework Framework (CAFF) Figure shows the Framework developed for SoS Integration. Full details can be found in [D ]. VRV [Package] Relationships View [Integration Perspective] Integration Perspective is used to validate Validation Interaction Context Definition Process Instance combines contexts of CSs from satisfies defines context for shows validation of processes from Interface Behaviour Context Interaction combines Requirement Context Process Content expands identifies processes that meet the requirements from shows interaction of interfaces on identifies interfaces between CSs from shows connections between interfaces on Interface Identification shows protocols for interfaces and ports on defines interfaces shown on Interface Connectivity Interface Definition Protocol Definition Figure - Relationships View for the Integration Framework Figure 2 shows the Framework developed for traceability. It is taken from the traceability pattern, one of the enabling patterns found in [D ]. Although not presented as a separate Framework in [D ], the pattern nevertheless defines a set of concepts that can (and should) be applied across all the other Frameworks. 2

22 D2.3 Initial Report on Guidelines for Systems VRV [Package] Relationships View [Traceability Perspective] Traceability Perspective Relationship Identification identifies relationships used on Traceability Traceability Identification identifies elements and relationships used on shows traceability tree from Impact Figure 2 - Relationships View for the Traceability Framework Again, to bring terminology in line with the CAFF, all the traceability Views found in [D ] have been renamed as s. The references for these Frameworks are summarised below: Framework Original Deliverable SoS Requirements [D2. 202] Report on Guidelines for Process modelling SoS Requirements Architectures and Architectural [D ] Initial Report on Frameworks Guidelines for Architectural Level SoS Modelling SoS Integration [D ] Report on Guidelines for System Integration for SoS Traceability [D ] Report on Modelling Patterns for SoS Architecture Table 4 - Original sources for Frameworks 5.2. The Combined Framework The five separate Frameworks presented in Section 5. are pulled together into a single Framework, the COMPASS Architectural Framework (COMPASS-AF) in Figure 3 below. 22

23 D2.3 Initial Report on Guidelines for Systems VRV [Package] Relationships View [Full Framework - Non-overlapping] Requirements Perspective Validation Interaction satisfies Context Interaction Source Element combines expands identifies sources of needs on Context Definition Requirement Context Requirement Description defines context for validates use case on defines needs in context from defines constraints on descriptions of needs on combines Validation Definition Rule Set Both the AF Context and the Context can make use of the full Requirements Perspective if required. AF & Architectures Perspective AF Context is derived from Ontology Definition Rules Definition is derived from Context is derived from {The Rules Definition is related to ALL the other s and defines the Rules that constrain the Architectural Framework. Relationships to the other s are omitted defines viewpoint using elements from from this diagram for clarity.} Definition Relationships defines viewpoint to meet needs from defines relationships between viewpoints defined in Process Perspective Process Instance shows validation of processes from Requirement Context identifies processes that meet the requirements from defines ontology for Process Structure Process Content identifies stakeholder oles for processes from identifies artefacts for processes from Stakeholder Information defines behaviour of processes from Process Behaviour Integration Perspective is used to validate Validation Interaction Context Definition Process Instance combines contexts of CSs from satisfies defines context for shows validation of processes from Interface Behaviour combines Context Interaction Requirement Context Process Content shows interaction of interfaces on expands identifies interfaces between CSs from identifies processes that meet the requirements from shows connections between interfaces on Interface Identification shows protocols for interfaces and ports on defines interfaces shown on Interface Connectivity Interface Definition Protocol Definition Traceability Perspective identifies relationships used on Relationship Identification The Traceability Perspective can be applied across all the other Perspectives. Traceability Traceability Identification identifies elements and relationships used on shows traceability tree from Impact Figure 3 - Relationships View for the COMPASS Architectural Framework 23

24 D2.3 Initial Report on Guidelines for Systems In Figure 3, each of the Perspectives representing the individual Frameworks are shown. There are four points to note: What were presented as individual Frameworks in previous deliverables are here represented as Perspectives of the combined COMPASS-AF. The Traceability Perspective can be applied across all the other Perspectives as shown by the attached comment. In the AF & Architectures Perspective, both the AF Context and the Context can make use of the full Requirement Perspective if required. There are a number of s that are used in more than one Perspective. These are duplicated in each Perspective were they are used and highlighted in grey. In order to show the reuse of the s more clearly, the COMPASS-AF is presented in Figure 4 with the packages representing each Perspective overlapped and the shared s shown only once. VRV [Package] Relationships View [Full Framework] AF & Architectures Perspective Both the AF Context and the Context can make use of the full Requirements Perspective if required. AF Context Ontology Definition Rules Definition is derived from is derived from {The Rules Definition is related to ALL the other s and defines the Rules that is derived from constrain the Architectural Framework. Relationships to the other s are omitted defines viewpoint using elements from from this diagram for clarity.} Context Definition Relationships defines viewpoint to meet needs from defines relationships between viewpoints defined in Traceability Perspective Relationship Identification identifies relationships used on identifies elements and relationships used on Traceability Traceability Identification shows traceability tree from Impact Requirements Perspective The Traceability Perspective can be applied across all the other Perspectives. Validation validates use case on Source Element identifies sources of needs on Definition Rule Set defines constraints on descriptions of needs on Requirement Description combines defines needs in context from Process Perspective Integration Perspective combines Validation Interaction satisfies Context Interaction expands Requirement Context Context Definition defines context for Process Structure Process Behaviour is used to validate combines contexts of CSs from Interface Behaviour identifies interfaces between CSs from shows interaction of interfaces on shows connections between interfaces on shows protocols for interfaces and ports on Interface Identification identifies processes that meet the requirements from defines ontology for Process Content defines behaviour of processes from identifies stakeholder oles for processes from identifies artefacts for processes from shows validation of processes from Process Instance Information Stakeholder defines interfaces shown on Interface Connectivity Interface Definition Protocol Definition Figure 4 - Relationships View for the COMPASS Architectural Framework showing overlapping packages to highlight shared s As can be seen in Figure 4: The Requirement Context is used in three Perspectives: the Requirements Perspective, the Process Perspective and the Integration Perspective. In fact, it can be considered to be used in the AF & Architectures Perspective too, given that the AF Context and 24

25 D2.3 Initial Report on Guidelines for Systems Context are themselves types of Requirement Context. The Process Content and the Process Instance are used in two Perspectives: the Process Perspective and the Integration Perspective. The Validation Interaction, Context Interaction and Context Definition are used in two Perspectives: the Requirements Perspective and the Integration Perspective. What Figure 4 makes clear is the importance of understanding Needs (Goals, Capabilities and Requirements) in Context, a point emphasised by the reuse of the Requirement Context across all of the Perspectives. This should not be surprising, given the prominence given to Requirements engineering and analysis in Standards such as ISO 5288 [ISO5288:2008] and associated commentaries such as [INCOSE 20] and Competency Frameworks such as [INCOSE 200]. The diagram in Figure 4 is reproduced in Appendix II, which also contains a glossary of the s found on the diagram. 25

26 D2.3 Initial Report on Guidelines for Systems 6. The COMPASS Processes and Guidelines This section summarises the Processes and Guidelines that form the COMPASS Process Library. These Processes form a number of Process groups (groupings of related Processes, such as those to do with System Integration, Architectural Frameworks etc.), as shown in Figure 5. PCV [Package] COMPASS Process Library [Process Groups] COMPASS Process Library System of Systems Requirement Process Group Architecture Guidelines Group Architectural Framework Process Group Systems Integration Process Group System of Systems Requirements Engineering Process Group System of Systems Requirements Management Process Group Figure 5 - Process Content View showing COMPASS Process Library Process Groups The Processes in each of the Process groups shown in Figure 5 are shown in the following sub-sections, together with a summary of each Process or guideline and references to the original deliverable documents where detailed information on each Process can be found. There are three points to note here regarding the areas covered by the COMPASS Process Library and the manner in which the Processes are defined: Although deliverable D2. Report on Guidelines for SoS Requirements includes Processes for the definition and construction of Architectural Frameworks (the Architectural Framework Processes Group in Figure 5), it does not contain Processes for the production of an Architecture for a SoS. Rather, it presents such information more informally as a set of Guidelines. This has been represented on Figure 5 as the Architecture Guidelines Group. Processes that cover the definition of Competency Frameworks and the carrying out of Competency assessments will be defined in the final version of this deliverable, D2.6 Final Report on Guidelines for SoS Engineering. Although the seven views approach to modelling Processes is used widely in COMPASS and has the relevant Ontology Elements and s defined (see Sections 4. and 5.), there are no associated 26

27 D2.3 Initial Report on Guidelines for Systems Processes defined for modelling Processes. It is intended that these are included in D SoS Requirements Processes The COMPASS SoS Requirements Processes comprise two Process groups that cover both Requirements engineering (the System of Systems Requirements Engineering Process Group) and the management of Requirements, including monitoring and reacting to change (the System of Systems Requirements Management Process Group). The Process Content Views 2 for both Process groups are shown in Figure 6 and Figure 7 below and are summarised in Table 4. PCV [Package] System of Systems Requirements Engineering Process Group [SoS Requirements Engineering Processes] System of Systems Requirements Engineering Process Group «process» SoS Requirements Development «artefact» Source «artefact» Context definition view «artefact» Requirement model «artefact» Context interaction view «artefact» Validation interaction view «artefact» Review record «activity» identify SoS stakeholder contexts «activity» identify SoS constituent system contexts «activity» select constituent systems «activity» invoke 'context' process for SoS «activity» invoke 'context' process for CS «activity» review «activity» identify interactions between SoS and CS «activity» baseline «activity» identify source elements «activity» invoke 'requirements elicitation' process «process» Context Process «artefact» Source element view «artefact» Requirement description view «artefact» Context definition view «artefact» Requirement context view «artefact» Validation view «artefact» Review record «activity» select context «activity» define context «activity» analyse context «activity» resolve problems «activity» review context «activity» define validation «activity» review validation «activity» baseline «process» Verification and Validation Definition Process «artefact» Context definition view «artefact» Requirement context view «artefact» Validation view «artefact» Test coverage view «artefact» Review record «activity» select context «activity» select use case «activity» define level of rigour «activity» define semi-formal scenarios «activity» define formal scenarios «activity» review «activity» trace to model «activity» review coverage «activity» baseline «process» Requirements Elicitation Process «artefact» Source element view «artefact» Requirement description... «artefact» Review record «activity» identify needs «activity» elicit requirements «activity» review «activity» baseline Figure 6 - Process Content View for System of Systems Requirements Engineering Process Group Processes 2 See [D2. 202] for a description of Process Content Views 27

28 D2.3 Initial Report on Guidelines for Systems PCV [Package] System of Systems Requirements Management Process Group [SoS Requirements ManagementProcesses] System of Systems Requirements Management Process Group «process» Requirements Change Process «process» Requirement Control Process «process» Traceability Process «artefact» Change request «artefact» Change record «artefact» Requirement element «artefact» Review record «artefact» Requirement model «activity» identify change(s) «activity» assess internal/external impact «activity» evaluate internal change(s) «activity» evaluate external change(s) «activity» change review «activity» take action «activity» resolution review «activity» baseline «process» CS Process Analysis «artefact» Requirement model «artefact» Review record «activity» communicate information «activity» stakeholder review «activity» baseline «activity» obtain commitment «process» Requirements Monitor Process «artefact» Process model «artefact» Exception «activity» identify traceable elements «activity» identify traceability paths «activity» verify with model «activity» set up traceability «activity» baseline «activity» raise exception «artefact» Source process «artefact» CS process model «artefact» SoS process model «artefact» Control point «artefact» Exception «artefact» Review record «activity» identify CS requirement processes «activity» model process «activity» map to SoS processes «activity» evaluate «activity» set up control points «activity» review «activity» baseline «activity» raise exception «artefact» Requirement element «artefact» Control point «artefact» Requirement model «activity» monitor SoS requirements «activity» monitor CS control points Figure 7 - Process Content View for System of Systems Requirements Management Process Group Processes Table 5 summarises the Processes shown in Figure 6 and Figure 7. For full details of each Process, refer to the original deliverable document. This table is repeated in Appendix III for ease of reference. Process Description (Summary) SoS Requirements Processes Original Deliverable [D2. 202] Report on Guidelines for SoS Requirements System of Systems Requirements Engineering Process Group SoS Requirements The main aim of the SoS Requirements Development Development Process Process is to perform most of the Requirements engineering at the SoS level. This involves defining the Contexts at SoS and Constituent System (CS) level and identifying the relationships and interactions between them. 28

29 D2.3 Initial Report on Guidelines for Systems Process Requirements Elicitation Process Context Process Verification and Validation Definition Process Description (Summary) SoS Requirements Processes This Process uses the Requirements Elicitation Process, the Context Process (at both SoS and CS levels), the Traceability Process and the Verification and Validation Definition Process (via the Context Process). The main aim of the Requirements Elicitation Process is to take the Source Element Views and, from them, elicit the parts that are relevant and create the Requirement Description View. The main aim of the Context Process is to define a Context based on the Context Definition View. This is a generic Process that may be invoked from the SoS Requirements Development Process and may be applied at both the SoS and the CS level. The main aim of the Verification and Validation Definition Process is to define a number of Scenarios for each Use Case in a specific Context. These Scenarios may be either semi-formal (diagram-based) or formal (mathematical-based) and form the basis of the testing of the SoS. These Scenarios are defined for both verification (it works) and validation (it does what it is supposed to do) for the Use Cases. System of Systems Requirements Management Process Group Traceability Process The overall aim of the Traceability Process is to enable traceability to be established between any elements in the model. This may be used for the Requirements model but may also trace to any elements in the wider SoS model or its CS models. CS Process Analysis Process The overall aim of the CS Process Analysis Process is to understand the Requirement management Process of the Constituent Systems (CSs) that make up the SoS. It is important to monitor the Requirements of the CSs so that any changes can be identified and evaluated. In order to do this there needs to be an understanding of the Requirement management Process of each of the CSs. This will be achieved by modelling each Requirement management Process and then mapping to the SoS Requirement management Process. Once this understanding has been achieved and mapped to the SoS Requirement management Process, then a number of control points can be set up that allow Requirements changes to be identified periodically. In the event that the Requirement management Processes of the SoS and its CSs are not compatible, then 29

30 D2.3 Initial Report on Guidelines for Systems Process Requirement Control Process Requirements Change Process Requirements Monitor Process Description (Summary) SoS Requirements Processes an exception is raised. This would then require action be taken to address the incompatibility between the Processes. The overall aim of the Requirement Control Process is: To ensure that all information contained in the Requirement model is communicated to the relevant Stakeholder Roles. To ensure that the Requirements model is reviewed and that a consensus is achieved between the relevant Stakeholder Roles. To obtain commitment from the Stakeholder Roles that the consensus is the most appropriate way forward and to allocate suitable resources to ensure that the Requirements are satisfied. The main aim of the Requirements Change Process is to identify any changes to Requirements, assess the impact and take appropriate actions. This process may be applied at both the SoS and the CSs level and can invoke another instance of itself. The aim of the Requirements Monitor Process is: To allow Requirements from the CSs that make up the SoS to be monitored for change via Control Points. To allow Requirements from the SoS to be monitored. Should any change occur in either the SoS or any of its CSs, then the Requirements Change Process will be invoked. Table 5 - Summary of the COMPASS SoS Requirements Processes 6.2. Architectural Framework Processes The COMPASS Architectural Framework Processes comprise a single Process group that covers the definition and construction of an Architectural Framework, the Architectural Framework Group. The Process Content View is shown in Figure 8 and is summarised in Table 6. 30