Concerns in SAF Domain descriptions to be removed?

[haarer]

Currently the Domains have concern descriptions which are partly redundant with the concerns of viewpoints, see below for an example.

We should remove them, at least don't call them concerns. The purpose/objective should be sufficient.

Functional Domain Concerns

• Defining the System Boundary
  • Identification of interaction partners and system interfaces
• Consolidating Functional Requirements:
  • formally specifying the requirements of the system behavior using a black box approach
• Mastering functional dependency:
  • detection and resolution of inconsistencies within the Functional Requirements (known as feature interaction)
• Reducing functional complexity:
  • structuring the functionality from the System's point of view
• Understanding functional interrelationships:
  • collecting and analyzing the exchange between different functionalities

[haarer]

christian hat's erledigt 👍

[clalitsc]

Die Aussage ist nur teilweise zutreffend. "Gelöscht" wurden die Domain Concerns auf der GitHub SAF Spezifikationsseite, main branch, vgl. https://github.com/GfSE/SAF-Specification/
Nicht "Gelöscht" wurden die Domain Concerns im SAF_Cameo_Profile Modell, dort sind diese weiterhin in den Beschreibungstexten der Grid Domain Attribute O-F-L-P zu finden. Und gerade dort stören mich die Concern Beschreibung, da diese eine Inkonsistenz zu dem SAF VP-Concern-Rational-VP.Stakeholder Ansatz darstellen. Wer nun Wert auf diese Concerns legt, möge diese zeitnah zu VP-Concern-Rational-VP.Stakeholder umwandeln.
@GfSE/saf

[haarer]

Jetzt ist es auch aus der Grid Domain raus.

[clalitsc]

The SAF Operational Domain supports the model-based development of a CONOPS - as well as an OPSCON and related life cycle concepts - for an organization or operational entity seeking for an improvement of existing capabilities or in establishing new ones. The SAF Operational Domain therefore aims to get an understanding of required organizational or operational entity capabilities.
The viewpoint-oriented approach of the SAF Operational Domain assist the "Business or Mission Analysis Process" and the "Stakeholder Needs and Requirements Definition Process" activities of the INCOSE SYSTEMS ENGINEERING HANDBOOK 2015 [§ 4.1, § 4.2]. By identifying Stakeholders and their Needs the SAF Operational Domain supports the derivation of a complete and consolidated set of Stakeholder Requirements based on operational activities and exchanges.

Concerns

• Gain a comprehensive understanding of the operating environment that an intended solution needs to support
• Promote the freedom of development by preventing premature commitment to solutions
• Capture all information necessary for subsequent requirement and system architecture definition activities

[clalitsc]

The Functional Domain Viewpoints translate Operational Domain (intended solution) usage into the notion of System Functions defining the demanded system behavior and quality attributes - performance, safety, security, etc.; the demanded system behavior as it is perceived by the User or other Entities at the System Boundary (known as usage behavior). The result of the Functional Domain viewpoint-oriented elaboration approach is a comprehensive System Specification.

Concerns

• Consolidating functional requirements: formally specifying the requirements of the system behavior using a black box approach
• Mastering functional dependency: detection and resolution of inconsistencies within the Functional Requirements (known as feature interaction)
• Reducing functional complexity: structuring the functionality from the System's point of view
• Addressing cross-cutting concerns
• Understanding functional interrelationships: collecting and analyzing the exchange between different functionalities

[clalitsc]

The Logical Domain Viewpoints describe the SOI Logical Structure and the distribution of responsibilities for the functionality of the SOI by means of a network of interacting Logical Elements that are responsible for a set of desired Functions. These Logical Elements and their Interactions are arranged in the Logical Architecture of the SOI. The structure of the Logical Architecture is in general influenced by Non-functional criteria, e.g., maintainability, reliability, safety, and security.

Concerns

• Describing the Internal Logical Structure of the SOI by partitioning the SOI into communicating Logical Elements
• Describing the Logical Interfaces & Data Exchanges between the interacting Logical Elements in a way that the Logical Interfaces are independent from their implementation
• Allocating desired System Functions to cohesive Logical Elements
• Supporting the reuse of already existent Logical Elements and designing Logical Elements such that a future reuse is facilitated
• Defining the emerging behavior of the SOI (in contrast to the partial behavior specified in the of Functional Domain Viewpoints) and enabling a complete simulation of the entire SOI

[clalitsc]

The SAF Physical Domain supports the representation of the Product Breakdown Structure, the identification of external and internal physical interfaces, the provision of viewpoints for the system overview, the integration planning, production planning, and the features and variations implied in the system. The physical architecture typically is a combination of re-use elements, COTS elements and make-items for HW as well as for SW. The properties of the selected physical components and their provided resources are identified and modeled. A major concern of the SAF Physical Domain are the physical interfaces, their identification and definition. For that purpose, the SAF Physical Domain provides the viewpoints to model interface with different level of detail considering the actual needs for the point of time in the project life cycle. For traceability the SAF Physical Domain defines viewpoints showing the mapping of the physical items and their interfaces to physical items and their interfaces as well as to applicable requirements.

Concerns

Structure

• Show the decomposition of the system into system elements down the hierarch and provide configuration meta data.

Interfaces

• Identify external interfaces and the information and data items that are exchanged or transferred via an interface together with related documentation.
• Identify applicable interface standards and allocate the standards to physical interfaces.
• Provide an overview on all physical interfaces of a given element with detailed information on the interfaces.
• Provide an overview on all physical interconnections between the internal elements of the system.
• Provide a detailed view on the physical interfaces and the interconnection between the system elements.
• Define a physical interface type in detail including compatibility rules.

Allocations

• Show the allocation of logical elements from the logical architecture to elements of the physical architecture.
• Show the allocation of logical interfaces from the logical architecture to interfaces of the physical architecture.
• Allocate functional or non-functional requirements to the elements of the physical architecture.
• Allocate functional or non-functional requirements to the interfaces of the physical architecture.
• Allocate a safety criticality to the elements of the physical architecture.