Stereotypes
Stereotypes of the SAF Profile
The stereotypes of the SAF Profile are used system models.
SAF_Argument
Implementation of SAF Concept ArgumentArgument: An argument is a rule that provides the bridge between what we know or are assuming (sub-claims, evidence) and the claim we are investigating. The argument used depends on the type, trustworthiness and extent of available evidence and the nature of the claim.
SAF_ArgumentClaimSupport
Implementation of SAF Concept AGTsupportingCLMAGTsupportingCLM: Specifies the fact that a claim is supported by one or more arguments via a claim-argument relation.
SAF_C2_ARAS
The Argumentation Assurance Viewpoint presents claims backed up by arguments that are supported by evidence, together with the possibility to counter such claims in a similar manner.
Representation:
A block definition diagram (BDD) featuring a claim-argument-evidence pattern (CAE).
SAF_C2_CSTD
The Standards Definition Viewpoint supports the definition of applicable standards, and their relationships, e.g., for format and protocol specifications, regulations, and engineering documents that are used throughout the system life cycle. It provides the meta-data for the applied standards, guidance and policy, e.g., issue, version, issue date, and publisher. The Viewpoint helps to keep track of changes to the set of applicable documents and of new versions of applied standards. Links should be used to refer to documents external to the architecture description.
Representation:
A block definition diagram (BDD) featuring the taxonomy of types of standards, applicable to the system of interest, or parts of the system of interest. The Standards are represented by packages which allows to use them in model libraries and put e.g. reusable interface definitions, or terms complying to the standard into the package
A table format listing standards, applicable to the system of interest or parts of it, their relationships and the relation to which parts of the system the standards apply
SAF_C2_CSTD_Table
The Standards Definition Viewpoint supports the definition of applicable standards, and their relationships, e.g., for format and protocol specifications, regulations, and engineering documents that are used throughout the system life cycle. It provides the meta-data for the applied standards, guidance and policy, e.g., issue, version, issue date, and publisher. The Viewpoint helps to keep track of changes to the set of applicable documents and of new versions of applied standards. Links should be used to refer to documents external to the architecture description.
Representation:
A block definition diagram (BDD) featuring the taxonomy of types of standards, applicable to the system of interest, or parts of the system of interest. The Standards are represented by packages which allows to use them in model libraries and put e.g. reusable interface definitions, or terms complying to the standard into the package
A table format listing standards, applicable to the system of interest or parts of it, their relationships and the relation to which parts of the system the standards apply
SAF_C2_GRID
SAF_C2_GRID_Table
The Grid Definition Viewpoint serves as overview about the of the Views present in a System Model.
Representation:
A content diagram featuring a matrix view for the SAF Viewpoint conceptual model: Rows represent Domains, and columns represent Aspects, and the cells manage the Views.
A table featuring the saf viewpoints, the views (diagrams, tables, ..) of the system model conforming to those viewpoints, domain and aspect information
SAF_C2_TRMD_Table
The Common Terms Definition Viewpoint supports the definition of applicable terms used in standards or defined during the systems engineering activities.
Representation:
A table format listing terms included in glossaries, or standards if applicable.
A table format listing abbreviations included in glossaries, orstandards if applicable.
SAF_C7_PRND_Table
The Protection GoalDefinition Viewpoint supports the definition of protection goals used to assign to Assets.
Representation:
A table format listing protection goals and subcategories.
SAF_Claim
Implementation of SAF Concept ClaimClaim: A claim is a true/false statement about a property of a particular object. A claim is just what you might consider it to be from common usage of the term; an idea that someone is trying to convince somebody else is true. An example claim could be made on a train, e.g., the train is safe.
SAF_ClaimAboutSubjectMaking
Implementation of SAF Concept CLMbeingMadeAboutSBCCLMbeingMadeAboutSBC: Specifies the fact that a claim is made about an identified subject matter.
SAF_ClaimClaimableItemSupport
Implementation of SAF Concept CLMsupportingCIMCLMsupportingCIM: Specifies the fact that any claimable item, e.g., claim, argument, and evidence, is supported by one or more claims.
SAF_ClaimSubject
Implementation of SAF Concept Subject of ClaimSubject of Claim: Note: A claim cannot be generic, it has to be about something, it has to have a defined subject, e.g., system safety.
SAF_ClaimableItem
Implementation of SAF Concept Claimable ItemClaimable Item: A claim, argument, and evidence are all types of the abstract concept of a claimable item. This allows a counter-claim to be made about any type of claimable item and a claim to support any type of claimable item.
SAF_Claimant
Implementation of SAF Concept ClaimantClaimant: A party asserting claims.
SAF_ClaimantClaimMaking
Implementation of SAF Concept CLTmakingCLMCLTmakingCLM: Specifies the fact that a claim is made by a defined claimant.
SAF_ConceptualInterfaceDefinition
Implementation of SAF Concept Logical Interaction Point DefinitionLogical Interaction Point Definition: Specifies the exchange capabilities of an interaction point on Logical Level.
SAF_ConformsStandard
Implementation of SAF Concept ASFconformToSTDASFconformToSTD: Specifies, that a SAF Element may be conform to one or more Standards.
SAF_ContextAction
none
SAF_ContextElementRepresentation
Implementation of SAF Concept SCErepresentedBySSHSCErepresentedBySSH: Specifies the fact that a System Context Element is represented by a SOI Stakeholder.
SAF_ContextFunction
Implementation of SAF Concept Context FunctionContext Function: Specifies the fact that a fundamental action or task is expected to be carried out by an External Entity. Note: The intention is to capture the expectations and to explicitly dissect the functionality. This must not be interpreted as an attempt for a behavior specification of an External Entity. Capturing this valuable information is the basis to reach agreement on the functionality at the System boundary by clarifying the expectations about what is performed by Context Elements.
SAF_CounterClaim
Implementation of SAF Concept CounterClaimCounterClaim: A party's claim is a counter-claim if one party asserts claims in response to the claims of another.
SAF_CounterClaimClaimableItemMaking
Implementation of SAF Concept CCMcounteringCIMCCMcounteringCIM: Specifies the fact that any claimable item, e.g., claim, argument, and evidence, is countered by one or more claims.
SAF_Diagram
none
SAF_DocumentReference
none
SAF_DomainKind
Implementation of SAF Concept System Domain KindSystem Domain Kind: Specification for any kind of conceptual item (energy, material, information, etc.) to be exchanged on Functional or Logical Level. The System Domain Kind is agnostic to any realization on Physical Level.
SAF_DomainKindComposition
Implementation of SAF Concept SDKcomposedOFSDKcomposedOF: Specifies the fact that a System Domain Kind consists of one or more System Domain Kinds.
SAF_DomainKindDerivation
Implementation of SAF Concept SDKderivingFromODKSDKderivingFromODK: Specifies the fact that a System Domain Kind on system level is derived from an Operational Domain Kind.
SAF_Evidence
Implementation of SAF Concept EvidenceEvidence: An evidence is an artifact that establishes facts that can be trusted and lead directly to a claim. In projects there can many sources of information, but what makes this evidence is the support or rebuttal it gives to a claim.
SAF_EvidenceArgumentReinforcement
Implementation of SAF Concept EVCreinforcingAGTEVCreinforcingAGT: Specifies the fact that an argument is reinforced by one or more evidence via a argument-evidence relation.
SAF_Example
Used to mark diagrams serving as example for a viewpoint
SAF_F1_SCXD
The System Context Definition Viewpoint defines how the SOI is embedded in its environment, i.e., where the boundary of the SOI is and who the external entities are the SOI interacts with (e.g., users, other external systems, environmental conditions, etc.). In addition, the System Context Definition Viewpoint serves as architecture concept to demonstrate how the architecture description defined in the Operational Context Definition Viewpoint is realized.
Representation:
A block definition diagram (BDD) featuring the following elements
- a Logical element block representing SOI in the logical domain
- a Logical context block representing the addressed context in the logical domain
- Logical context element blocks for each relevant context element
- a composition relationship from context block to each context element used in the context
- a composition relationship from context block to the SOI
A tabular format listing context roles, context elements, and respective descriptions.
SAF_F1_SCXD_Table
The System Context Definition Viewpoint defines how the SOI is embedded in its environment, i.e., where the boundary of the SOI is and who the external entities are the SOI interacts with (e.g., users, other external systems, environmental conditions, etc.). In addition, the System Context Definition Viewpoint serves as architecture concept to demonstrate how the architecture description defined in the Operational Context Definition Viewpoint is realized.
Representation:
A block definition diagram (BDD) featuring the following elements
- a Logical element block representing SOI in the logical domain
- a Logical context block representing the addressed context in the logical domain
- Logical context element blocks for each relevant context element
- a composition relationship from context block to each context element used in the context
- a composition relationship from context block to the SOI
A tabular format listing context roles, context elements, and respective descriptions.
SAF_F1_SCXE
The System Context Exchange Viewpoint serves for the identification and definition of external interfaces of the SOI that are used to interact, e.g., users, external systems, and other external entities defined in the given context of the SOI. The System Context Exchange Viewpoint
- identifies system interfaces on a functional level,
- states to which external entities the system interfaces are connected to,
- and defines the usage of interfaces, e.g., when only a subset of the interface is used.
Representation:
An internal block diagram (IBD) - associated to a system context - featuring the SOI, the system context elements, and the connectors for each identified interface from SOI to the respective context elements. An interface is an interaction point for interaction of the SOI to with context elements. Item flows are defined for each exchange on the identified interface. Connectors/ports may contain reference to the interface documents if applicable. Ports may be structured as appropriate to manage and structure the information. Note: more than one IBD focused on different areas of interest may be used in oder to keep the view comprehensive. Depending on the Stakeholder concerns the item exchange information might be suppressed.
A tabular format listing the identified interfaces of the soi (ports), referencing interface definitions (port types) ,connections (connector) to system context elements, and information exchange (item flows) conveyed over these connections. It is advised to have multiple tables focusing on certain aspects to keep the view comprehensive, e.g. table focusing on contexts or on certain interface partners.
SAF_F1_SCXE_Table
The System Context Exchange Viewpoint serves for the identification and definition of external interfaces of the SOI that are used to interact, e.g., users, external systems, and other external entities defined in the given context of the SOI. The System Context Exchange Viewpoint
- identifies system interfaces on a functional level,
- states to which external entities the system interfaces are connected to,
- and defines the usage of interfaces, e.g., when only a subset of the interface is used.
Representation:
An internal block diagram (IBD) - associated to a system context - featuring the SOI, the system context elements, and the connectors for each identified interface from SOI to the respective context elements. An interface is an interaction point for interaction of the SOI to with context elements. Item flows are defined for each exchange on the identified interface. Connectors/ports may contain reference to the interface documents if applicable. Ports may be structured as appropriate to manage and structure the information. Note: more than one IBD focused on different areas of interest may be used in oder to keep the view comprehensive. Depending on the Stakeholder concerns the item exchange information might be suppressed.
A tabular format listing the identified interfaces of the soi (ports), referencing interface definitions (port types) ,connections (connector) to system context elements, and information exchange (item flows) conveyed over these connections. It is advised to have multiple tables focusing on certain aspects to keep the view comprehensive, e.g. table focusing on contexts or on certain interface partners.
SAF_F1_SUCD
The System Use Case Viewpoint provides an outside view on the system functionality from the perspective of the system users and contributes to the definition of system requirements and system usage. The intended system use may be captured as free-text use case description, as well as storytelling approach on a coarse level of detail. The main system exchange partners participating in the intended system use are identified. System use cases are related to a specific system context. System use cases are derived from operational scenarios elaborated during mission analysis.
Representation:
A use case diagram featuring model elements representing System Use Cases, System Context, and System Context Elements. The System Context shall be used as subject of the use case. The System Context Elements playing a Role in the Use Case shall be connected to the Use Case by associations. Note: System Use Case pre- and postconditions shall be represented either by callout or compartment notation. Relationship to operational stories can be related to the use case in order trace to mission analysis.
A tabular format listing the System Use Cases, the System Use Case pre- and postconditions, the System Context, and the System Context Elements. Additionaly, the relationship to operational stories, if applicable.
SAF_F1_SUCD_Table
The System Use Case Viewpoint provides an outside view on the system functionality from the perspective of the system users and contributes to the definition of system requirements and system usage. The intended system use may be captured as free-text use case description, as well as storytelling approach on a coarse level of detail. The main system exchange partners participating in the intended system use are identified. System use cases are related to a specific system context. System use cases are derived from operational scenarios elaborated during mission analysis.
Representation:
A use case diagram featuring model elements representing System Use Cases, System Context, and System Context Elements. The System Context shall be used as subject of the use case. The System Context Elements playing a Role in the Use Case shall be connected to the Use Case by associations. Note: System Use Case pre- and postconditions shall be represented either by callout or compartment notation. Relationship to operational stories can be related to the use case in order trace to mission analysis.
A tabular format listing the System Use Cases, the System Use Case pre- and postconditions, the System Context, and the System Context Elements. Additionaly, the relationship to operational stories, if applicable.
SAF_F2_SCYD
The System Capability Definition Viewpoint defines a taxonomy of Capabilities including composition, specialization, and dependency relationships between System Capabilities. Note: Connecting capabilities to requirements creates a linkage between two different types of conceptual problem description that helps manage the complexity of the system. At a high level of abstraction, capabilities allow an system architect to plan phases of the system evolution without the need to bear details in mind. Those details will not be lost if they are captured as requirements and traced to a corresponding capability. There is one key difference between capabilities and requirements: Requirements come from different sources, sponsored by different stakeholders, and are usually captured at different levels of abstraction. In contrast, capabilities should always represent a coherent and consolidated view of the system.
Representation:
A block definition diagram (BDD) featuring System Capabilities, their composition, specialization, and dependency relationships. Note: The relationship to operational capabilities shall be shown if applicable.
A tabular format listing System Capabilities, their composition, specialisation, and dependency relationships, as well as relations to operational capabilities.
SAF_F2_SCYD_Table
The System Capability Definition Viewpoint defines a taxonomy of Capabilities including composition, specialization, and dependency relationships between System Capabilities. Note: Connecting capabilities to requirements creates a linkage between two different types of conceptual problem description that helps manage the complexity of the system. At a high level of abstraction, capabilities allow an system architect to plan phases of the system evolution without the need to bear details in mind. Those details will not be lost if they are captured as requirements and traced to a corresponding capability. There is one key difference between capabilities and requirements: Requirements come from different sources, sponsored by different stakeholders, and are usually captured at different levels of abstraction. In contrast, capabilities should always represent a coherent and consolidated view of the system.
Representation:
A block definition diagram (BDD) featuring System Capabilities, their composition, specialization, and dependency relationships. Note: The relationship to operational capabilities shall be shown if applicable.
A tabular format listing System Capabilities, their composition, specialisation, and dependency relationships, as well as relations to operational capabilities.
SAF_F2_SDIK
The System Domain Item Kind Viewpoint captures system wide concepts and collects type definitions for any exchanged item, e.g., information, material, or energy, of the Functional and Logical domain. Its purpose is to define these item types and their relationships. Furthermore, the System Domain Item Kind Viewpoint specifies the data types, entity types, related value types, and units that are used by the SOI. Note: Domain Item Kinds are used as types of function input and output in the Functional Domain, and for types of interfaces in the Logical Domain. They specify what is to be exchanged but not how.
Representation:
A block definition diagram (BDD) featuring Domain Item Kinds and their relationships in terms of generalization, composition, or general association. Note: Domain Item Kinds are managed in the domain knowledge package of the SOI, the Domain Item Kinds are visible and usable to all sub elements of the SOI. Domain Item Kinds shall be value types or blocks.
A tabular format listing the Domain Item Kinds, and their relationships.
SAF_F2_SDIK_Table
The System Domain Item Kind Viewpoint captures system wide concepts and collects type definitions for any exchanged item, e.g., information, material, or energy, of the Functional and Logical domain. Its purpose is to define these item types and their relationships. Furthermore, the System Domain Item Kind Viewpoint specifies the data types, entity types, related value types, and units that are used by the SOI. Note: Domain Item Kinds are used as types of function input and output in the Functional Domain, and for types of interfaces in the Logical Domain. They specify what is to be exchanged but not how.
Representation:
A block definition diagram (BDD) featuring Domain Item Kinds and their relationships in terms of generalization, composition, or general association. Note: Domain Item Kinds are managed in the domain knowledge package of the SOI, the Domain Item Kinds are visible and usable to all sub elements of the SOI. Domain Item Kinds shall be value types or blocks.
A tabular format listing the Domain Item Kinds, and their relationships.
SAF_F2_SFBS
The System Functional Breakdown Structure Viewpoint defines the structured, modular functional breakdown of the SOI beginning with System Processes, over identified System Functions further refined down to System Partial Functions. The reuse of System Functions, and System Partial Functions over Function Trees of the SOI is facilitated.
Representation:
One or more more block definition diagrams (BDD) featuring activities representing System Processes, System Functions, System Partial Functions, and their aggregation composing the functional breakdown structure.
Tool specific analysis diagram featuring the relationships between System Processes, System Functions, and System Partial Functions.
SAF_F3_SFRE
The System Functional Refinement Viewpoint analyses decomposition of System Functions into System Partial Functions in order achieve understanding and agreement about the System functions sufficient to derive system requirements.
Representation:
Activity Diagram featuring System Partial Functions, functional exchange between partial functions. There are explicitely no Swimlanes and no allocations to structure.
SAF_F3_SPRO
The System Process Viewpoint provides the functional representation of the system using a black-box approach
- the representation of the SOI and all Context Elements
- the System Functions the SOI shall be able to perform
- the Context Functions the Context Elements are expected to perform
- the exchange between SOI System Functions and Context Functions of Context Elements
- the functional flows crossing the boundary between SOI and Context Elements
Representation:
An activity diagram featuring the ordered execution of System Process Actions. The activity diagram swim lanes are typed with Context Element usage and SOI usage from the same System Context. Note: In order to improve the clarity of presentation it may be appropriate to use several activity diagrams for one System Process.
A tabular format listing all identified System Functions, the System Processes in which they appear, and the Comtext Exchange with the Context Functions.
SAF_F3_SPRO_Table
The System Process Viewpoint provides the functional representation of the system using a black-box approach
- the representation of the SOI and all Context Elements
- the System Functions the SOI shall be able to perform
- the Context Functions the Context Elements are expected to perform
- the exchange between SOI System Functions and Context Functions of Context Elements
- the functional flows crossing the boundary between SOI and Context Elements
Representation:
An activity diagram featuring the ordered execution of System Process Actions. The activity diagram swim lanes are typed with Context Element usage and SOI usage from the same System Context. Note: In order to improve the clarity of presentation it may be appropriate to use several activity diagrams for one System Process.
A tabular format listing all identified System Functions, the System Processes in which they appear, and the Comtext Exchange with the Context Functions.
SAF_F3_SSTA
The System State Viewpoint defines the conditions of the SOI or parts of thereof that constrain the execution of System Functions. System States are used as pre- or post-condition of System Use Cases, and as constraints within the definition of System Functions to specifying valid transitions. Valid transitions between System States and the conditions for transitioning are specified in system wide concepts captured in System Requirements.
Representation:
A block definition diagram (BDD) featuring states, and state transitions. Note: References to model elements that are dependent of states, or transitions shall be shown as callout, or compartment notation.
A tabular format listing states, state transitions, and the conditons to be fullfilled before the transition will occur. References to model elements that are dependent of states (Domain Item Kinds, System Functions, System Use Cases, etc.), or transitions shall be shown in the table.
SAF_F3_SSTA_Table
The System State Viewpoint defines the conditions of the SOI or parts of thereof that constrain the execution of System Functions. System States are used as pre- or post-condition of System Use Cases, and as constraints within the definition of System Functions to specifying valid transitions. Valid transitions between System States and the conditions for transitioning are specified in system wide concepts captured in System Requirements.
Representation:
A block definition diagram (BDD) featuring states, and state transitions. Note: References to model elements that are dependent of states, or transitions shall be shown as callout, or compartment notation.
A tabular format listing states, state transitions, and the conditons to be fullfilled before the transition will occur. References to model elements that are dependent of states (Domain Item Kinds, System Functions, System Use Cases, etc.), or transitions shall be shown in the table.
SAF_F4_SCXI
The System Context Interaction Viewpoint describes the System external behavior based on the exchange between Logical SOI and Logical Context Elements Usage in a given System Context. It depicts the sequence of interactions between the Logical SOI, the Context Elements and the exchanged Domain Item Kinds needed to accomplish a given System Process. Note: The System Context Interaction Viewpoint may refine a System Use Case.
Representation:
A sequence diagram featuring the flow of control between SOI and Context Elements Roles of a System Context to achieve one outcome of a System Use Case. Note: This diagram depicts the sending and receiving of messages between the interacting entities called lifelines, where time is represented along the vertical axis. The lifelines representatives are part properties typed by a System Context Elements.
SAF_F5_SIFD
The System Interface Definition Viewpoint captures system wide concepts defining interfaces. It allows to adopt long-lived standards and to harmonize conceptual interface definitions to improve interchangeability, interoperability, and portability.
Representation:
A block definition diagram (BDD) featuring Conceptual Interface blocks with ports, and flow properties.
A tabular format listing Conceptual Interface blocks, their ports, and flow properties.
SAF_F6_SRQD_Table
The System Requirement Definition Viewpoint specifies functions, non-functional properties, or constraints of the System. System Requirements are captured, the interrelationships between Functional and Non-Functional Requirements on the same level of abstraction and the traceability to Stakeholder Requirements are depicted.
Representation:
A tabular format listing
- unique requirement ID, text, and attributes,
- traceability reference to Stakeholder Requirements,
- traceability reference to depended Requirements on the same level of abstraction.
SAF_F8_SCYM_Table
The System Capability Mapping Viewpoint describes the relationships of System Capabilities. The reasoning for System Capabilities as support for System Use Cases and the contribution of System Processes to Capabilities are described. Furthermore, the mapping of System Capabilities to Operational Capabilities are identified.
Representation:
A tabular format listing the relationships of System Capabilities to Operational Capabilities, System Use Cases, System Process Activities, and System Requirements.
SAF_F8_SRQT_Matrix
The System Requirement Traceability Viewpoint specifies for every System Requirement the traceability to the functional domain level
- System Use Case
- System Capability
- System Context Definition
- System Context Exchange
- System Context Interaction
- System Process
- System State
Representation:
A dependency matrix featuring relationships for every System Requirement to the functional domain level
- System Use Case
- System Capability
- System Context Definition
- System Context Exchange
- System Context Interaction
- System Process
- System State
SAF_FunctionAction
Implementation of SAF Concept General Functional UsageGeneral Functional Usage: Specifies a General Usage of a General Function within one or more other General Functions.
SAF_Glossary
Implementation of SAF Concept GlossaryGlossary: specifies a coherent set of terms.
SAF_InterfaceLayerRelationship
Stereotype realizes multiple Concepts:- Implementation of SAF Concept PCPOverPCP
PCPOverPCP: Specifies the fact that a physical interaction point communicates / transfers / flows / over an other physical interaction point. Used to define layered physical interfaces, and show layer relationships between interfaces. - Implementation of SAF Concept PCPPOverPCPP
PCPPOverPCPP: Specifies the fact that a physical interaction point property communicates / transfers / flows / over an other physical interaction point property. Used to define layered physical interfaces, and show layer relationships between interface details.
SAF_IssuedBy
Implementation of SAF Concept STDissuedBySTOSTDissuedBySTO: Specifies the fact that a standard is issued by an organization of standardization.
SAF_L2_LSTD
The Logical Structure Definition Viewpoint describes how the system is decomposed into a hierarchical structure of logical elements responsible for different system functions (divide & conquer principle). It covers related logical concepts and principles that support the logical operation of the system and is widely reusable among similar systems like product families, or product generations.
Representation:
A block definition diagram (BDD) featuring the logical system block and logical blocks for any kind of logical element the system is composed of. These elements are connected to the system block by means of aggregation relationships. Note: Multiple relationships to a kind of element are allowed meaning, that this kind of element is used in several roles.
SAF_L4_LIEX
The Logical Internal Exchange Viewpoint serves for the identification and definition of interfaces of elements of the logical system. also, the delegation of system element interfaces to the logical system boundary interfaces is covered. The Logical Internal Exchange Viewpoint
- identifies system element interfaces on a logical level
- states to which other logical elements the interfaces are connected to
- assigns conceptual interface definitions to interfaces
- defines the usage of interfaces, e.g., if only a subset of the interfaces is used
- defines the delegation of logical system element interfaces to the logical system boundary interfaces
Representation:
One or more IBDs featuring the SOI boundary, the logical elements of the SOI, as well as the connectors for each identified SOI interface delegation to logical SOI elements. An interface is a connection resource for hooking on the logical SOI elements to other logical SOI elements. Item flows are defined for each exchange on the identified interface. Note: Please use more than one IBD focused on different areas of interest to keep the view comprehensive.
SAF_L4_LITI
The Logical Internal Interaction Viewpoint describes System internal behavior based on the exchange between the Logical SOI Elements Usage. It depicts the sequence of interactions between the Logical SOI Elements and the exchanged Domain Item Kinds needed to accomplish a System Partial Function.
Representation:
A sequence diagram featuring the flow of control between Internal Logical Elements of the SOI. Note: This diagram depicts the sending and receiving of messages between the interacting entities called lifelines where time is represented along the vertical axis. The lifeline representatives are part properties typed by Logical System Elements.
SAF_L8_LFUM_Matrix
The Logical Functional Mapping Viewpoint supports the definition of assignment of system functions and system partial functions to logical system elements.
Representation:
A FBS to LBS mapping matrix featuring
- Functional Breakdown Structure (FBS)
- Logical Breakdown Structure (LBS)
- Allocation from system functions and system partial functions to logical system elements
SAF_LogicalContext
Implementation of SAF Concept Logical System ContextLogical System Context: Specifies the fact that a System Context for a System of Interest is defined on Logical Level.
SAF_LogicalContextElementActing
Implementation of SAF Concept LCEactingInSUCLCEactingInSUC: Specifies the fact that a Logical Context Element acts in one or more System Use Cases.
SAF_LogicalContextRole
Stereotype realizes multiple Concepts:- Implementation of SAF Concept Logical Context Element Role
Logical Context Element Role: Specifies the fact that a Logical Context Element exists in a given Logical System Context. - Implementation of SAF Concept Logical SOI Role
Logical SOI Role: Specifies the fact that a Logical Context SOI exists in a given Logical System Context.
SAF_LogicalElement
Implementation of SAF Concept Logical ElementLogical Element: Describes a conceptual Logical Element as specification for an implementation of a system, or system element.
SAF_LogicalEnvironment
Implementation of SAF Concept Logical EnvironmentLogical Environment: A Logical Environment in the Logical Domain, outside the SOI scope, interacting with the SOI. E.g., air, dirt, sun, road.
SAF_LogicalExternalSystem
Implementation of SAF Concept Logical External SystemLogical External System: A Logical External System in the Logical Domain, outside the SOI scope, interacting with the SOI. E.g., power grid, mobile network, fresh water system (in a house).
SAF_LogicalInternalRole
none
SAF_LogicalSOI
Implementation of SAF Concept Logical Context SOILogical Context SOI: Represents the Logical SOI in the System Context on Logical Level.
SAF_LogicalUser
Implementation of SAF Concept Logical UserLogical User: The Logical User is the representation for a human in the Logical Domain, outside the SOI scope, interacting with the SOI.
SAF_O1_OCXD
The Operational Context Definition Viewpoint provides the operational contexts and the involved operational performers necessary to support a specific set of operational capabilities.
Representation:
A block definition diagram (BDD) featuring the identified Operational Performers playing a role in the Operational Context being addressed.
SAF_O1_OCXE
The Operational Context Exchange Viewpoint provides the operational exchange of systems, personnel, information, material, energy, etc. between operational performers.
Representation:
An internal block diagram (IBD) - associated to the operational context - featuring the interconnected operational performers in their respective operational role, and the operational item exchange per operational connection.
A tabular format listing [tbd].
SAF_O1_OSTY
The Operational Story Viewpoint
- captures operational stories within operational contexts and their relation to operational performers, thus enables storytelling
- illustrates the operational background from the Stakeholder perspective
- serves as starting point to identify Stakeholders and/or context elements
- fosters the communication among different Stakeholders
Representation:
A use case diagram featuring model elements representing operational stories, the context in they’re taking place and operational performers involved. Note: Illustrations, drawings, sketches, etc., and/or descriptions in free text may provide a comprehensive understanding of the operational mission.
SAF_O2_OCYD
The Operational Capability Definition Viewpoint defines a taxonomy of Capabilities from a Stakeholder’s perspective including composition, specialization, and dependency relationships between Operational Capabilities.
Representation:
A block definition diagram (BDD) featuring Operational Capabilities, their composition, specialization, and dependency relationships.
SAF_O2_ODIK
The Operational Domain Item Kind Viewpoint captures enterprise wide concepts and collects type definitions for any exchanged item of the Operational Domain. Its purpose is to define these item types and their relationships.
Representation:
A block definition diagram (BDD) featuring Operational Domain Item Kinds and their relationships.
A Table featuring Operational Domain Item Kinds, their relationships and their Documentation
SAF_O2_ODIK_Table
The Operational Domain Item Kind Viewpoint captures enterprise wide concepts and collects type definitions for any exchanged item of the Operational Domain. Its purpose is to define these item types and their relationships.
Representation:
A block definition diagram (BDD) featuring Operational Domain Item Kinds and their relationships.
A Table featuring Operational Domain Item Kinds, their relationships and their Documentation
SAF_O2_OPRF
The Operational Performer Viewpoint represents the taxonomy of the identified Operational Performers, if existing and relevant for the understanding of the operation of the intended solution.
Representation:
A block definition diagram (BDD) featuring Operational Performers. and their relations in terms of decomposition or generalization at a level of detail required for problem understanding and analysis. Note: Identified Stakeholders are related to Operational Performers if appropriate.
A table containing operational performers, their inter relations and relations to stakeholders
SAF_O2_OPRF_Table
The Operational Performer Viewpoint represents the taxonomy of the identified Operational Performers, if existing and relevant for the understanding of the operation of the intended solution.
Representation:
A block definition diagram (BDD) featuring Operational Performers. and their relations in terms of decomposition or generalization at a level of detail required for problem understanding and analysis. Note: Identified Stakeholders are related to Operational Performers if appropriate.
A table containing operational performers, their inter relations and relations to stakeholders
SAF_O2_STID
The Stakeholder Identification Viewpoint of the operational domain strives to identify Stakeholders, who’s concerns shall be considered, and adequatley adressed by the intended solution. Relations
Representation:
A block definition diagram (BDD) depicting the identified, analysed, and classified Stakeholders, their interrelaions and their relations to the Intended Solution. Relations to represented Operational Performers shall also be shown.
SAF_O3_OPRO
The Operational Process Viewpoint describes the Operational Processes related to a specific Operational Story, the sequence of execution, and their Operational Exchanges, including information, materials, natural resources, etc. The assignment of Operational Processes to Operational Performers is captured.
Representation:
An activity diagram featuring the ordered execution of Operational Process Actions. Operational Processes may be linked in terms of control flow and/or data flow visualizing the Operational Exchanges needed. Note: Operational Process Actions are assigned to Operational Roles and therefore in a more general manner to Operational Performers.
SAF_O4_OCXI
The Operational Context Interaction Viewpoint describes single threads of interaction between Operational Performers in an Operational Context on an operational domain level. Note: The Operational Interaction Viewpoint may refine an Operational Story.
Representation:
A sequence diagram featuring the flow of control between Operational Performers of an Operational Context to achieve one outcome of an Operational Story. Note: This diagram depicts the sending and receiving of messages between the interacting entities called lifelines where time is represented along the vertical axis. The lifelines representatives are part properties typed by Operational Performers.
SAF_O6_SKRD_Table
The Stakeholder Requirement Definition Viewpoint specifies all capabilities, functions and properties, that the intended solution shall possess or expose from the perspective of the Stakeholders. The Stakeholder Requirement Definition Viewpoint also captures constraints for the system to be developed from stakeholders perspective.
Representation:
A tabular format lisiting
- unique requirement ID, text, and attributes,
- traceability reference to justifying model artefacts, e.g. operational stories, operational capabilities, identified concerns of stakeholders, and compliance statements Note: Stakeholder Requirements are to be structured in a way that the Stakeholder behind the Requirement is identifiable. When appropriate, the relationships between identified Stakeholder Requirements are and the justifying model artefacts, Operational Story, Operational Capability, Operational Performer, Operational Process, and Operational Exchange are presented.
- “One Requirement Package for each Stakeholder” is a best-practice modeling rule. A package contains the Requirements specific for one Stakeholder.
- Even if different Stakeholders may have intersecting interests and / or concerns resulting in a similar set of Requirements, each Stakeholder shall have its own set managed in a dedicated Requirement Package. Requirements must not be shared due to their different life cycles. Resolving duplications and conflicts is subject of the requirement analysis resulting in an agreed and consolidated set of System Requirements.
SAF_O8_OCYM_Table
The Operational Capability Mapping Viewpoint describes the relationships of Operational Capabilities. The reasoning for Operational Capabilities as support for Operational Stories and the contribution of Operational Processes to Capabilities are described. Operational Capabilities encoded in Stakeholder Requirements are identified.
Representation:
A tabular format listing the relationships of Operational Capabilities to Stakeholder Requirements, Operational Stories, and Operational Process Activities.
SAF_O8_OPRM_Table
The Operational Process Mapping Viewpoint describes the relationships of Operational Processes. The reasoning for Operational Processes from Operational Stories and their contribution to Capabilities is described. The assignment of Operational Processes to Operational Performers is captured.
Representation:
A tabular format listing the relationships of Operational Process Activities to Operational Capabilities, Operational Stories, and Operational Performers.
SAF_OperationalCapability
Implementation of SAF Concept Operational CapabilityOperational Capability: A Operational Capability is a high-level description or specification of an organizational unit's ability to execute a specified course of action, to implement a business process or to provide a service. Operational Capabilities typically require people, processes, infrastructure, technology and supporting systems to be implemented. A Operational Capability is an enduring element, its implementation may change over time. A necessary or desired change of a Operational Capability triggers the updated of involved systems or the integration new systems. Aliases: UAF::Capability NAF4::Capability
SAF_OperationalCapabilityComposition
Implementation of SAF Concept OCYcomposedOFOCYcomposedOF: Specifies the fact that an Operational Capability consists of other Operational Capabilites.
SAF_OperationalCapabilityDependency
Implementation of SAF Concept OCYdependingONOCYdependingON: Specifies the fact that an Operational Capability depends on another Operational Capability. Aliases: UAF::CapabilityDependency
SAF_OperationalCapabilityGeneralization
Implementation of SAF Concept OCYspecializedBYOCYspecializedBY: Specifies the fact that an Operational Capability is specialized by other Operational Capability. Aliases: UAF::CapabilityGeneralization
SAF_OperationalCapabilitySupport
Implementation of SAF Concept OCYsupportingOSYOCYsupportingOSY: Specifies the fact that an Operational Story is supported by Operational Capabilities.
SAF_OperationalContext
Implementation of SAF Concept Operational ContextOperational Context: An Operational Context is representing a separate Usage Scenario with a specific configuration of Operational Performers, these are interacting in the Scenario exhibiting a specific identified Operational Capability. One or more Operational Contexts meaningful for the Operational Domain are to be identified. Aliases: UAF::HighLevelOperationalConcept
SAF_OperationalContextRole
Implementation of SAF Concept Operational Context RoleOperational Context Role: An Operational Context Role represents a participant in an Operational context. It is interacting with other roles of the given Operational Context. Specific characteristics and features or, in case of persons or organizational units, knowledge and skills are assigned to a role necessary for the execution of the performed Operational Processes.
SAF_OperationalDomainKind
Implementation of SAF Concept Operational Domain KindOperational Domain Kind: Specifies the kind of Operational Item Exchange between Operational Context Roles or Operational Processes.
SAF_OperationalDomainKindComposition
Implementation of SAF Concept ODKcomposedOFODKcomposedOF: Specifies the fact that an Operational Domain Kind consists of one or more Operational Domain Kinds.
SAF_OperationalPerformer
Implementation of SAF Concept Operational PerformerOperational Performer: An Operational Performer is an element of the Operational Context that is capable to perform Operational Process Activities contributing to a specific identified Operational Capability. An Operational Performer may be any kind of organization, person, or even a system playing a role in one or more Operational Contexts. Aliases: UAF::OperationalPerformer
SAF_OperationalPerformerActing
Implementation of SAF Concept OPRactingInOSYOPRactingInOSY: Specifies the fact that an Operational Performer acts in an Operational Story.
SAF_OperationalPerformerComposition
Implementation of SAF Concept OPRcomposedOFOPRcomposedOF: Specifies the fact that an Operational Performer consists of one or more Operational Performers.
SAF_OperationalPerformerExhibit
Implementation of SAF Concept OPRexhibitingOCYOPRexhibitingOCY: Specifies the fact that an Operational Performer exhibits an Operational Capability under specific environmental conditions.
SAF_OperationalProcess
Implementation of SAF Concept Operational ProcessOperational Process: An Operational Process captures activity-based operational behavior including scenarios, activity actions, and operational exchange flows, e.g., including information, materials, natural resources, etc. Aliases: UAF::Operational Activity NAF::Logical Activity
SAF_OperationalProcessAction
Implementation of SAF Concept Operational Process UsageOperational Process Usage: Specifies the fact that an Operational Process is used in context of another Operational Process. Aliases: UAF::OperationalAction
SAF_OperationalProcessEnabling
Implementation of SAF Concept OPSenablingOCYOPSenablingOCY: Specifies the fact that an Operational Process contributes to the provision of one or more Operational Capabilities in the field. Aliases: UAF::MapsToCapability
SAF_OperationalProcessRefinement
Implementation of SAF Concept OPSrefiningOSYOPSrefiningOSY: Specifies the fact that an Operational Story is refined by one or more Operational Processes.
SAF_OperationalSketch
Implementation of SAF Concept Operational SketchOperational Sketch: Specifies a free form sketch depicting a concept.
SAF_OperationalStory
Implementation of SAF Concept Operational StoryOperational Story: The Operational Story represents one or more Operational Use Cases in the Usage Scenario identified by the Operational Context. The Operational Story is described as narrative story-telling.
SAF_P1_PCXD
The Physical Context Definition Viewpoint identifies the various contexts the SOI is used in, along with the associated external entities sharing a physical interface with the system. For each context, the applicable environmental conditions shall be defined. The physical context helps identify the interface requirements needed to integrate a system into its environment in a given context.
Representation:
A block definition diagram (BDD) depicting the elements available in a specific context. At least one BDD is used per identified context featuring
- one block representing the Physical System, i.e., the system of interest
- one block representing the specific Physical System Context
- several blocks representing Physical Context Elements such as Physical User, Physical External System, and Physical Environment that are present in the Physical System Context
- composition relationships attaching the Physical Context Elements and the Physical System to the Physical System Context block
SAF_P1_PCXE
The Physical Context Exchange Viewpoint focuses on the identification of the physical interfaces with external entities and relevant documentation. It is used to capture interface design requirements, applicable standards, protocols and format specifications, that are agreed upon the interfaces.
Representation:
A) For each given context, an internal block diagram (IBD is used to identify the physical interfaces, the item flows, that are exchanged on that interfaces, and related documentation. Note: To understand the interfaces, a mapping of protocol layers may be depicted.
B) A tabular format providing a list of all the defined external interfaces and the applicable documentation
- context element kind (environment, external entity, physical user, etc.)
- context element role name
- port name and reference to port type
- reference to context element type
C) A tabular format listing the applicable standards, protocols and formats for the item flows exchanged via the identified interfaces.
SAF_P1_PCXE_Table
The Physical Context Exchange Viewpoint focuses on the identification of the physical interfaces with external entities and relevant documentation. It is used to capture interface design requirements, applicable standards, protocols and format specifications, that are agreed upon the interfaces.
Representation:
A) For each given context, an internal block diagram (IBD is used to identify the physical interfaces, the item flows, that are exchanged on that interfaces, and related documentation. Note: To understand the interfaces, a mapping of protocol layers may be depicted.
B) A tabular format providing a list of all the defined external interfaces and the applicable documentation
- context element kind (environment, external entity, physical user, etc.)
- context element role name
- port name and reference to port type
- reference to context element type
C) A tabular format listing the applicable standards, protocols and formats for the item flows exchanged via the identified interfaces.
SAF_P2_PSTD
The Physical Structure Viewpoint is used to model the internal structure of the SOI and to identify the internal system elements making up the SOI. The SOI breakdown structure identifies system elements and finally at the implementation level hardware, software, and mechanics. The SOI breakdown structure determines items that are reused and make-or-buy (COTS) items. The Physical Structure Viewpoint is elaborated for each candidate physical SOI architecture. It provides the basis for further assessment of the architecture candidates by identifying the system elements in each candidate solution.
Representation:
A block definition diagram (BDD) featuring the physical system block and physical blocks for any kind of physical element, HW or SW elements, the system is composed of. These elements are connected to the system block by means of aggregation relationships. Note: Multiple relationships to a kind of element are allowed meaning, that this kind of element is used in several roles.
SAF_P4_PIEX
The Physical Internal Exchange Viewpoint serves for the identification and definition of interfaces of elements of the physical system. also, the delegation of system element interfaces to the physical system boundary interfaces is covered. The Physical Internal Exchange Viewpoint
- identifies system element interfaces on a physical level
- states to which other physical elements the interfaces are connected to
- assigns physical interface definitions to interfaces
- defines the usage of interfaces, e.g., if only a subset of the interfaces is used
- defines the delegation of physical system element interfaces to physical system boundary interfaces
Representation:
One or more IBDs featuring the SOI boundary, the parts representing physical elements of the SOI. At the SOI boundary, the interfaces of the SOI represented as proxy ports. At the parts, proxy ports representing the SOI parts interfaces. Binding Connectors for each identified SOI interface delegated to physical SOI elements interfaces. connectors representing connections between interfaces of SOI parts. Item flows are defined for each planned exchange on the identified interfaces. Note: Please use more than one IBD focused on different areas of interest to keep the view comprehensive. Note: Ports may be nested to organize interfaces, but it is recommended to use only only one level.
A Table representing the content or part of the ibd content.
SAF_P4_PIEX_Table
The Physical Internal Exchange Viewpoint serves for the identification and definition of interfaces of elements of the physical system. also, the delegation of system element interfaces to the physical system boundary interfaces is covered. The Physical Internal Exchange Viewpoint
- identifies system element interfaces on a physical level
- states to which other physical elements the interfaces are connected to
- assigns physical interface definitions to interfaces
- defines the usage of interfaces, e.g., if only a subset of the interfaces is used
- defines the delegation of physical system element interfaces to physical system boundary interfaces
Representation:
One or more IBDs featuring the SOI boundary, the parts representing physical elements of the SOI. At the SOI boundary, the interfaces of the SOI represented as proxy ports. At the parts, proxy ports representing the SOI parts interfaces. Binding Connectors for each identified SOI interface delegated to physical SOI elements interfaces. connectors representing connections between interfaces of SOI parts. Item flows are defined for each planned exchange on the identified interfaces. Note: Please use more than one IBD focused on different areas of interest to keep the view comprehensive. Note: Ports may be nested to organize interfaces, but it is recommended to use only only one level.
A Table representing the content or part of the ibd content.
SAF_P5_PIFD
The Physical Interface Definition Viewpoint captures definitions for physical interfaces. It allows to adopt long-lived standards and to harmonize physical interface definitions to improve interchangeability, interoperability, and portability.
Representation:
A block definition diagram (BDD) featuring Physical Interface blocks with ports, and flow properties. Compatibility between Physical Interface blocks is expressed by associations and association blocks. Physical Interface blocks may be specialisations of others (use of generalisation). Note: When ports are used these shall be proxy ports and be typed by interface blocks.
A tabular format listing Physical Interface blocks, their ports, and flow properties.
SAF_P8_PFUM_Matrix
The Physical Functional Mapping Viewpoint supports the analysis of the assigment of system functions and system partial functions to physical system elements. The result shall be computed from the assigment of functions to logial system elements and the assignment of logical system elements to physical system elements
Representation:
A FBS_to_PBS mapping matrix featuring
- Functional Breakdown Structure (FBS)
- Physical Breakdown Structure (PBS)
- mapping (it is a derived relationship) from system functions and system partial functions to physical SOI elements
SAF_P8_PLOM_Matrix
The Physical Logical Mapping Viewpoint supports the definition of the assignment of conceptual logical system elements to physical system elements comprising the SOI.
Following the identification of physical system elements capable of performing the system functions of logical elements, the Physical Logical Mapping Viewpoint provides feedback to the System Architecture Definition process to consolidate or confirm the allocation, partitioning, and alignment of logical elements to physical elements that comprise the SOI.
Representation:
A assignment matrix featuring
- Logical Element Breakdown Structure showing Logical Element Roles and Logical Elements
- Physical Element Breakdown Structure showing physical element roles and physical elements
- Allocation relationship from logical system element roles to physical system element roles
SAF_PhysicalContext
Implementation of SAF Concept Physical System ContextPhysical System Context: Specifies the fact that a context for a System of Interest is defined on Physical Level.
SAF_PhysicalContextRole
Stereotype realizes multiple Concepts:- Implementation of SAF Concept Physical SOI Role
Physical SOI Role: Specifies the fact that a Physical SOI exists in a given Physical System Context. - Implementation of SAF Concept Physical Context Element Role
Physical Context Element Role: Specifies the fact that a Physical Context Element exists in a given Physical System Context.
SAF_PhysicalElement
Implementation of SAF Concept Physical ElementPhysical Element: A composition of Hardware and Software Elements. Similarity with the V-Model segments and system. See [VXT].
SAF_PhysicalEnvironment
Implementation of SAF Concept Physical EnvironmentPhysical Environment: The Physical Environment in the Physical Domain, outside the SOI scope, interacting with the SOI. E.g. air, dirt, sun, road.
SAF_PhysicalExchangeType
Implementation of SAF Concept Physical Exchange KindPhysical Exchange Kind: Specification for any kind of physical item (energy, material, information, etc.) to be exchanged on Physical Level. This is the realization of the specification made by System Domain Kinds.
SAF_PhysicalExternalSystem
Implementation of SAF Concept Physical External SystemPhysical External System: The Physical External System in the Physical Domain, outside the SOI scope, interacting with the SOI. E.g. power grid, mobile network, fresh water system (in a house).
SAF_PhysicalHardwareElement
Implementation of SAF Concept Hardware ElementHardware Element: Pure Hardware Elements. Similarity with the V-Model "hardware unit".
SAF_PhysicalInterfaceDefinition
Implementation of SAF Concept Physical Interaction Point DefinitionPhysical Interaction Point Definition: Specifies the exchange capabilities of an interaction point on Physical Level.
SAF_PhysicalInternalRole
Stereotype realizes multiple Concepts:- Implementation of SAF Concept General Physical Role
General Physical Role: General concept of usage of system elements in the context of other system elements on physical level. - Implementation of SAF Concept Hardware Element Role
Hardware Element Role: Specifies the fact that a hardware structure comprises hardware elements. - Implementation of SAF Concept Physical Software Role
Physical Software Role: Specifies the fact that a physical structure comprises software elements. - Implementation of SAF Concept Software Element Role
Software Element Role: Specifies the fact that a software structure comprises software elements. - Implementation of SAF Concept Physical Element Role
Physical Element Role: Specifies the fact that a physical structure comprises physical elements. - Implementation of SAF Concept Physical Hardware Role
Physical Hardware Role: Specifies the fact that a physical structure comprises hardware elements.
SAF_PhysicalItem
none
SAF_PhysicalSoftwareElement
Implementation of SAF Concept Software ElementSoftware Element: Pure Software Elements. Similarity with the V-Model "software unit".
SAF_PhysicalSystem
Implementation of SAF Concept Physical SOIPhysical SOI: Represents the Physical SOI on Physical Level.
SAF_PhysicalUser
Implementation of SAF Concept Physical UserPhysical User: The Physical User is the representation for a human in the physical domain, outside the SOI scope, interacting with the SOI.
SAF_Process
Implementation of SAF Concept ProcessProcess: Unit of Work in Systems Engineering.
SAF_ProtectionNeed
none
SAF_Refuter
Implementation of SAF Concept RefuterRefuter: A party asserting counter-claims.
SAF_RefuterCounterClaimMaking
Implementation of SAF Concept RFTmakingCCMRFTmakingCCM: Specifies the fact that a counter-claim is made by a defined refuter.
SAF_Stakeholder
Implementation of SAF Concept System of Interest StakeholderSystem of Interest Stakeholder: An individual, team, or organization (or classes thereof) with interests in, or concerns relative to, a system. It may be involved in any life cycle phase of the System. The Stakeholder represents a class or kind of Stakeholders. Stakeholders have a certain involvement: Stakeholder Involvement captures the influence of a project specific Stakeholder on the System. Stakeholder Involvement is characterized by * Contact Person * Kind of involvement * Life Cycle Phases involved * Relevance decision if and up to which degree Stakeholder is considered * Rationale for decision when Stakeholder is not considered
SAF_StakeholderRelation
Implementation of SAF Concept SSHrelatedToSSHSSHrelatedToSSH: Explains relations between the Stakeholders of the System and other relevant System parties. It helps to understand the Stakeholder community and to approach the right point of contact for clarification of project relevant issues.
SAF_StakeholderRepresenting
Implementation of SAF Concept SSHrepresentingOPRSSHrepresentingOPR: Specifies the fact that a SOI Stakeholder is representing an Operational Performer.
SAF_StakeholderRequirement
Implementation of SAF Concept Stakeholder RequirementStakeholder Requirement: A Stakeholder Requirement is a Requirement imposed by a Stakeholder. Stakeholder Concerns are refined by Stakeholder Requirements applicable for the SOI. The Stakeholder Requirements are a result of discussions and agreements of how the SOI addresses the Concerns of the respective Stakeholder.
SAF_StakeholderRequirementImposition
Implementation of SAF Concept SHRimposedBYSHRimposedBY: Specifies the fact that a Stakeholder Requirement is provided by Stakeholders.
SAF_StakeholderRequirementRefinement
Stereotype realizes multiple Concepts:- Implementation of SAF Concept SHRrefiningCRN
SHRrefiningCRN: Specifies the fact that a Stakeholder Concern is refined by Stakeholder Requirements. - Implementation of SAF Concept SHRrefiningOSY
SHRrefiningOSY: Specifies the fact that an Operational Story is refined by Stakeholder Requirements. - Implementation of SAF Concept SHRrefiningOCY
SHRrefiningOCY: Specifies the fact that an Operational Capability is refined by Stakeholder Requirements.
SAF_Standard
Implementation of SAF Concept StandardStandard: Specifies a standard which shall potentially be complied by the system or a part of the system.
SAF_StandardCategory
Implementation of SAF Concept Category Of StandardCategory Of Standard: Specifies categories in which the standard could be categorized , e.g., a data exchange format or a protocol standard, or categories as national, company or international standard.
SAF_StandardCategoryAssignment
Implementation of SAF Concept SDTcategorizedCOFSDTcategorizedCOF: Specifies the fact that a standard is categorized by one or more categories.
SAF_StandardChapter
none
SAF_StandardDependingOn
Implementation of SAF Concept STDdependsOnSTDSTDdependsOnSTD: specifies that a standard depends on an other.
SAF_StandardSuperseding
Implementation of SAF Concept SDTsupersedingSDTSDTsupersedingSDT: Specifies the fact that a standard supersedes one or more other standards.
SAF_StandardizationOrganization
Implementation of SAF Concept Standardization OrganizationStandardization Organization: An organization of standardization, e.g., International Organization for Standardization (ISO), Object Management Group (OMG), etc.
SAF_SystemCapability
Implementation of SAF Concept System CapabilitySystem Capability: 1) A System Capability is an operation or task that performs an action to produce a specific performance-based outcome. NOTE that a system capability represents the potential to perform an action. In contrast, an operational capability may integrate several physical system capabilities to produce a specific outcome to achieve a mission objective. [Wasson2006, SystemAnalysis+Design+Development] 2) System Capabilities, as system assets, characterize the mechanical, electrical, optical, or processing features that enable a system to function, process mission resources, make decisions, and achieve a required level of success based on performance. A system capability is broader in scope than simply a functional element (and performance bounding elements), especially in large, complex ecosystems. It represents a physical potential - strength, ability, endurance - to perform an outcome-based action for a given duration under a specified set of operating environment conditions. [Wasson2006, SystemAnalysis+Design+Development] Aliases: UAF::Capability NAF4::Capability
SAF_SystemCapabilityComposition
Implementation of SAF Concept SCYcomposedOFSCYcomposedOF: Specifies the fact that a System Capability consists of other System Capabilities.
SAF_SystemCapabilityDependency
Implementation of SAF Concept SCYdependingONSCYdependingON: Specifies the fact that a System Capability requires another System Capability. Aliases: UAF::CapabilityDependency
SAF_SystemCapabilityEnabling
Implementation of SAF Concept SCYenablingOCYSCYenablingOCY: Specifies the fact that an Operational Capability integrates System Capabilities to produce a specific outcome to achieve a mission objective.
SAF_SystemCapabilityGeneralization
Implementation of SAF Concept SCYspecializedBYSCYspecializedBY: Specifies the fact that a System Capability is specialized by another System Capability. A CapabilityGeneralization is a taxonomic relationship between a more general Capability and a more specific Capability. Aliases: UAF::CapabilityGeneralization
SAF_SystemCapabilitySatisfaction
Implementation of SAF Concept SCYsatisfyingSHRSCYsatisfyingSHR: Specifies the fact that a System Capability satisfies one or more Stakeholder Requirements.
SAF_SystemCapabilitySupport
Implementation of SAF Concept SCYsupportingSUCSCYsupportingSUC: Specifies the fact that a System UseCase is supported by System Capabilities.
SAF_SystemFunction
Implementation of SAF Concept System FunctionSystem Function: Specifies the fundamental action or task that have to take place in the System in accepting and processing the inputs and in processing and generating the outputs. A System Function * accepts input from the System boundary * exposes its output at the System boundary * changes the System's State * is dependent on System's State Note: A System Function does not need to expose observable output, when it changes the System's state in a way that is observable by other system functions. Furthermore, a System Function does not need to accept any input from the system boundary, when it is dependent on the System State, which in turn is changeable by other System Functions.
SAF_SystemFunctionSupport
Implementation of SAF Concept SFNsupportingSCYSFNsupportingSCY: Specifies the fact that a System Function supports one or more System Capabilities.
SAF_SystemFunctionalRequirement
Implementation of SAF Concept Functional RequirementFunctional Requirement: Functional Requirements specify System Functions of the System.
SAF_SystemFunctionalRequirementConstraint
Implementation of SAF Concept FRboundedByNFRFRboundedByNFR: Specifies the fact that a Non-Functional Requirement constrains Functional Requirements.
SAF_SystemFunctionalRequirementRefinement
Implementation of SAF Concept FRrefiningSFNFRrefiningSFN: Specifies the fact that a System Function is refined by Functional Requirements.
SAF_SystemNonFunctionalRequirement
Implementation of SAF Concept Non-functional RequirementNon-functional Requirement: Non-Functional Requirements specify the quality of System Functions, or non-functional requests like legal conformance.
SAF_SystemOfInterestConcern
Implementation of SAF Concept System of Interest ConcernSystem of Interest Concern: Any kind of interest a Stakeholder has. Note: Redundant with the meaning of "Need"?
SAF_SystemPartialFunction
Implementation of SAF Concept System Partial FunctionSystem Partial Function: Specifies the fact that a System Partial Function is a decomposed part of a System Function and defines details of the System Function it belongs to.
SAF_SystemProcess
Implementation of SAF Concept System ProcessSystem Process: Specifies the fact that a System Process captures system behavior as a specific sequence of actions or tasks, and system exchanges including information, materials, energy, etc.
SAF_SystemProcessEnabling
Implementation of SAF Concept SPSenablingSCYSPSenablingSCY: Specifies the fact that a System Process contributes to the provision of one or more System Capabilities in the field.
SAF_SystemProcessRefinement
Implementation of SAF Concept SPSrefiningSUCSPSrefiningSUC: Specifies the fact that a System Use Case is refined by one System Process.
SAF_SystemRequirement
Implementation of SAF Concept System RequirementSystem Requirement: System Requirements specify System Functions, non-functional properties, or constraints of the System.
SAF_SystemRequirementDerivation
Stereotype realizes multiple Concepts:- Implementation of SAF Concept SRderivingFromSTKR
SRderivingFromSTKR: Specifies the fact that a System Requirement is derived from a Stakeholder Requirement. Note: It may be used in a customer supplier relationship situation and supports the V Model concept of "External Unit Specification". See [VXT]. - Implementation of SAF Concept SRderivingFromSR
SRderivingFromSR: Specifies the fact that System Requirements are derived from a Stakeholder Requirement. Note: This is the relationship of requirements of different architectural levels. When the team responsible for the subsystem has direct access to the full upstream requirements set, then no subcontractor relationship needs to be established.
SAF_SystemRequirementRefinement
Stereotype realizes multiple Concepts:- Implementation of SAF Concept SRrefiningLICP
SRrefiningLICP: Specifies the fact that a Logical Interaction Point is refined by System Requirements. - Implementation of SAF Concept SRrefiningSUC
SRrefiningSUC: Specifies the fact that a System Use Case is refined by System Requirements. - Implementation of SAF Concept SRrefiningSCY
SRrefiningSCY: Specifies the fact that a System Capability is refined by System Requirements.
SAF_SystemUseCase
Implementation of SAF Concept System Use CaseSystem Use Case: The System Use Cases are a table of content of the services provided by the System of Interest to its System Actors. A System Use Case is only the abstract of the depicted System behavior and represents the purpose. While the main System of Interest interaction actors participating in this Use Case are identified, the behavior itself is specified by a Use Case Activity, Note: The intended use (and also misuse in so called "black use cases") of the System of Interest is captured in free text; story telling at a coarse level of detail which is understandable to Customers (non engineering stakeholders in general).
SAF_SystemUseCaseEnabling
Implementation of SAF Concept SUCenablingOSYSUCenablingOSY: Specifies the fact that a System Use Case enables the realization of an Operational Story.
SAF_Term
Implementation of SAF Concept TermTerm: Specifies the fact that a term is usually defined by a standard, but can also be defined as part of system development work.
SAF_Viewpoint
Stereotype realizes multiple Concepts:- Implementation of SAF Concept Viewpoint
Viewpoint: A architecture viewpoint defines set of conventions for the creation, interpretation and use of an architecture view to frame one or more concerns - Implementation of SAF Concept VPbelongingToDN
VPbelongingToDN: specifies that a viewpoint belongs to one domain. - Implementation of SAF Concept VPbelongingToAT
VPbelongingToAT: specifies that a viewpoint belongs to one aspect.
SysML ActivityDiagram
Proxy Stereotype representing the Activity Diagram Kind
SysML BlockDiagram
Proxy Stereotype representing the Block Diagram Kind
SysML InternalBlockDiagram
Proxy Stereotype representing the Internal Block Diagram Kind
SysML RequirementDiagram
Proxy Stereotype representing the Requirement Diagram Kind
SysML SequenceDiagram
Proxy Stereotype representing the Sequence Diagram Kind
SysML StateMaschineDiagram
Proxy Stereotype representing the Statemachine Diagram Kind
SysML UseCaseDiagram
Proxy Stereotype representing the Use Case Diagram Kind
Stereotypes of the SCM Profile
The stereotypes of the SCM Profile are used to specify the SAF, or to extend the SAF. They are typically not used in system models.
report dev stereotypes here
SCM_AspectColumn
Columns (aspects) of the SAF viewpoint matrix Used for specifying SAF.
SCM_Attribute
Defines a relationship between attribute type and attribute owner, implementing a SAF concept. The name of the relation specifies the name of the attribute Used for specifying SAF.
SCM_ChangeRecord
used to track changes in the SAF specification
SCM_Concept
A concept used in MBSE. May be a class, an association or an association class Used for specifying SAF.
SCM_ConcernRationale
The rationale explaining why a SAF_VPStakeholder has a specific concern (which should be addressed by one or more SAF Viewpoints. Used for specifying SAF.
SCM_ContainedIn
Defines a relation where the instances of the client(sterotype or metaclass) is contained in instances of the the supplier (stereotype or metaclass). This is used to specify an inplementation of a SAF concept Used for specifying SAF.
SCM_D2_CCND
SCM_D2_COTD
SCM_D2_COTD_Table
SCM_D2_STKD_Table
SCM_D2_STYD_Table
The Stereotype Viewpoint provides an overview over all stereotypes provided by SAF.
Representation:
A table featuring the stereotypes of the SAF profile and their documentation.
SCM_D2_VPTD
SCM_D2_VPTI
SCM_D2_VPTO
SCM_D2_VPTO_Table
SCM_DerivedRelationship
a derived relationship among SAF_Concepts which is important for views and stakeholders, but not a primary information The rule of derivation must be specified and is used if the relationship is exposed in a view. This shall be always used together with SAF_Concept on relationships. Used for specifying SAF.
SCM_DocTarget
defines a path for doc generation. Experimental.
SCM_DomainLayer
Domains(rows) of the saf matrix Used for specifying SAF.
SCM_FramesConcern
The relationship between a SAF Viewpoint to a concern defining that the Viewpoint frames (adresses) this concern. Used for specifying SAF.
SCM_InformationItem
An information item required by a standard, e.g. ISO 29148
SCM_Maturity
Specifies the maturity of SCM Elements i.e. Viewpoints Used for specifying SAF.
SCM_ProcessRequirement
Requirement to specify content for an information Item.
SCM_RealizationKind
defines the kind of realization if it is not able to derive from a stereotype or metaclass
SCM_RealizeConcept
Specifies the fact that a stereotype or an UML Metaclass is used to realize a SAF concept.
SCM_TypedBy
Defines a realization where the instances of the client(sterotype or metaclass) is typed by instances of the the supplier (stereotype or metaclass). Used for specifying realizations of SAF Concepts in the SAF Specification.
SCM_VPConcern
Concern of an engineering Stakeholder, to describe their concerns adressed by SAF viewpoints. Used for specifying SAF.
SCM_VPStakeholder
A stakeholder having concerns framed by viewpoints. These stakeholders are only used in the SAF specification model to capture concerns of viewpoints. They may not be used in a system model. Used for specifying SAF.
SCM_VP_Package
Used for the root package of a viewpoint spec. Document generation and validations rely on this.
SCM_View
Used to mediate between SCM_Concepts and SCM_Viewpoints. Concepts are exposed by the SCM_View, specifying the conceptual content of the Viewpoint. Used for specifying SAF.
SCM_Viewpoint
Extends SysML Viewpoint by attributes needed by SAF Documentation. Used for specifying SAF.
SCM defined Patterns
report patterns like attribute_of, type_of, contained_in
Used SysML Stereotypes
report used SysML and UML objects