Overview about the relationships between concepts used in the SAF Operational Domain and the SAF Functional Domain

ConceptDocumentation
System Of InterestAn abstract element representing a SOI. Base class for specific kinds of SOIs.
System Use CaseThe 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).
SUCenablingOSYSpecifies the fact that a System Use Case enables the realization of an Operational Story.
Conceptual Context ElementRepresents an abstract element in the given System Context on Conceptual Level, outside the SOI scope, interacting with the SOI.
Conceptual System ContextSpecifies the fact that a System Context for a System of Interest is defined on Conceptual Level.
Logical Context SOI_ DeprecatedRepresents the Logical SOI in the System Context on Logical Level.
Operational StoryThe 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.
Conceptual Exchange TypeSpecification for any type of conceptual item (energy, material, information, etc.) to be exchanged on Conceptual (Functional Architecture and Logical Architecture) Level. The Conceptual Exchange Type is agnostic to any realization on Physical Level.
Operational ContextAn 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
allowingSpecifies the fact that a Conceptual Item Exchange is allowed on the Conceptual Connection.
typingSpecifies the fact that a Conceptual Exchange Type defines the type of a Logical Item Exchange.
Conceptual Interaction PointSpecifies the existence of an interaction point on Conceptual Level.
Conceptual Item ExchangeSpecifies the exchange that is to take place on a connection of two interaction points on Conceptual Level.
applyingToSpecifies the fact that a Conceptual Interaction Point applies to a Conceptual Context Element.
Conceptual ConnectionSpecifies the connection of two interaction points on Logical Level. Note: Connections between logical components indicate that item flows are passed from one output of a source component to one or more inputs of target components.
Operational PerformerAn 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
System Context ElementAn abstract element representing a System Context Element. Base class for specific kinds of Context Elements.
SHRrefiningOCYSpecifies the fact that an Operational Capability is refined by Stakeholder Requirements.
Operational Context RoleAn 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.
SRrefiningSUCSpecifies the fact that a System Use Case is refined by System Requirements.
SCEactingForOPRSpecifies the fact that a System Context Element is acting for the benefit of an Operational Performer.
SOIactingForOPRSpecifies the fact that a SOI is acting for the benefit of an Operational Performer.
SSHrepresentingOPRSpecifies the fact that a SOI Stakeholder is representing an Operational Performer.
SCErepresentedBySSHSpecifies the fact that a System Context Element is represented by a SOI Stakeholder.
LCEactingInSUCSpecifies the fact that a Logical Context Element acts in one or more System Use Cases.
System of Interest StakeholderAn 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
Stakeholder RequirementA 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.
System RequirementSystem Requirements specify System Functions, non-functional properties, or constraints of the System.
SHRimposedBYSpecifies the fact that a Stakeholder Requirement is provided by Stakeholders.
SRderivingFromSTKRSpecifies 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].
Conceptual Context Element RoleSpecifies the fact that a Conceptual Context Element acts in a given Conceptual System Context.
OPRactingInOSYSpecifies the fact that an Operational Performer acts in an Operational Story.
Operational ConnectionSpecifies the connection between Operational Context Roles in an Operational Context allowing Operational Item Exchange. Aliases: UAF::OperationalConnector
Operational Item ExchangeSpecifies the Operational Item Exchange that is to take place on an Operational Connection. Aliases: UAF::OperationalExchange
allowingSpecifies the fact that an Operational Item Exchange is allowed on the Operational Connection.
OCYsupportingOSYSpecifies the fact that an Operational Story is supported by Operational Capabilities.
Operational Exchange TypeSpecifies the type of Operational Item Exchange between Operational Context Roles or Operational Processes.
characterisingSpecifies the fact that an Operational Exchange Type characterises an Operational Item Exchange.
SHRrefiningOSYSpecifies the fact that an Operational Story is refined by Stakeholder Requirements.
OPRexhibitingOCYSpecifies the fact that an Operational Performer exhibits an Operational Capability under specific environmental conditions.
Operational CapabilityA 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
deriving fromSpecifies the fact that a Conceptual Exchange Type on system level is derived from an Operational Exchange Type.
System Capability1) 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
SCYsupportingSUCSpecifies the fact that a System UseCase is supported by System Capabilities.
SCYenablingOCYSpecifies the fact that an Operational Capability integrates System Capabilities to produce a specific outcome to achieve a mission objective.
SUCtakingPlaceInLSCSpecifies the fact that a System Use Case takes place in a Logical System Context.
SUCrefiningSHRSpecifies the fact that a Stakeholder Requirement is refined by System Use Cases.
SRrefiningSCYSpecifies the fact that a System Capability is refined by System Requirements.
SCYsatisfyingSHRSpecifies the fact that a System Capability satisfies one or more Stakeholder Requirements.
LIEimplementsOIEspecifies that this exchange in the FD implements (possibly partly) that exchange in the OD