-
Notifications
You must be signed in to change notification settings - Fork 5
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
make generator more robust against rename attacks
- Loading branch information
haarer
committed
Dec 8, 2023
1 parent
79b40d6
commit e6d700e
Showing
56 changed files
with
35,014 additions
and
416 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,22 @@ | ||
| # SAF Development Documentation : Concepts : SAF_argumentation_C Definition | ||
|  | ||
| |Concept|Documentation| | ||
| | --- | --- | | ||
| | AGTsupportingCLM | Specifies the fact that a claim is supported by one or more arguments via a claim-argument relation.| | ||
| | Argument | 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.| | ||
| | Argument Concretion | This argument concept is used when a claim needs to be given a more precise definition or interpretation.| | ||
| | Argument Decomposition | This argument concept is used to claim that a conclusion about the whole object or property can be deduced from the claims or facts about constituent parts. Decomposition argument blocks can also be used to incorporate defeaters into the case.| | ||
| | Argument Substitution | This argument concept is used to claim that if a property holds for one object, then it holds for an equivalent object. Similarly, if a property holds for some object, then an equivalent property will also hold for the same object. The nature of the equivalence will vary with the object and property and will need to be defined.| | ||
| | CCMcounteringCIM | Specifies the fact that any claimable item, e.g., claim, argument, and evidence, is countered by one or more claims.| | ||
| | CLMbeingMadeAboutSBC | Specifies the fact that a claim is made about an identified subject matter.| | ||
| | CLMsupportingCIM | Specifies the fact that any claimable item, e.g., claim, argument, and evidence, is supported by one or more claims.| | ||
| | CLTmakingCLM | Specifies the fact that a claim is made by a defined claimant.| | ||
| | Claim | 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.| | ||
| | Claimable 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.| | ||
| | Claimant | A party asserting claims.| | ||
| | CounterClaim | A party's claim is a counter-claim if one party asserts claims in response to the claims of another.| | ||
| | EVCreinforcingAGT | Specifies the fact that an argument is reinforced by one or more evidence via a argument-evidence relation.| | ||
| | Evidence | 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.| | ||
| | RFTmakingCCM | Specifies the fact that a counter-claim is made by a defined refuter.| | ||
| | Refuter | A party asserting counter-claims.| | ||
| | Subject 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.| |
58 changes: 29 additions & 29 deletions
58
developing-saf/concept/capability_F.md → ...af/concept/SAF_capability_F Definition.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,29 +1,29 @@ | ||
| # SAF Development Documentation : Concepts : capability_F | ||
|  | ||
| |Concept|Documentation| | ||
| | --- | --- | | ||
| | Operational 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.<br><br>Aliases:<br>UAF::Capability<br>NAF4::Capability| | ||
| | Operational 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.| | ||
| | SCYcomposedOF | Specifies the fact that a System Capability consists of other System Capabilities.| | ||
| | SCYdependingON | Specifies the fact that a System Capability requires another System Capability.<br><br>Aliases:<br>UAF::CapabilityDependency| | ||
| | SCYenablingOCY | Specifies the fact that an Operational Capability integrates System Capabilities to produce a specific outcome to achieve a mission objective.| | ||
| | SCYsatisfyingSHR | Specifies the fact that a System Capability satisfies one or more Stakeholder Requirements.| | ||
| | SCYspecializedBY | 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.<br><br>Aliases:<br>UAF::CapabilityGeneralization| | ||
| | SCYsupportingSUC | Specifies the fact that a System UseCase is supported by System Capabilities.| | ||
| | SFNsupportingSCY | Specifies the fact that a System Function supports one or more System Capabilities.| | ||
| | SHRrefiningOCY | Specifies the fact that an Operational Capability is refined by Stakeholder Requirements.| | ||
| | SPSenablingSCY | Specifies the fact that a System Process contributes to the provision of one or more System Capabilities in the field.| | ||
| | SPSrefiningSUC | Specifies the fact that a System Use Case is refined by one System Process.| | ||
| | SRderivingFromSR | Specifies the fact that System Requirements are derived from a Stakeholder Requirement. <br>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.| | ||
| | SRrefiningSCY | Specifies the fact that a System Capability is refined by System Requirements.| | ||
| | SUCenablingOSY | Specifies the fact that a System Use Case enables the realization of an Operational Story.| | ||
| | SUCincludingSUC | Specifies the fact that a System Use Case includes other System Use Cases. The included use case is then no longer a full System Use Case, but a partial System Use Case.| | ||
| | SUCrefiningSHR | Specifies the fact that a Stakeholder Requirement is refined by System Use Cases.| | ||
| | SUCsynthesizingSFN | Specifies the fact that a System Function is used in a System Use Case, e.g., as a Trigger, Action, or Task. <br>Note: This is a derived relationship.| | ||
| | Stakeholder 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.| | ||
| | System 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]<br>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]<br><br>Aliases:<br>UAF::Capability<br>NAF4::Capability| | ||
| | System Function | Specifies the fundamental action or task that have to take place in the System in accepting and processing the<br>inputs and in processing and generating the outputs.<br>A System Function<br> * accepts input from the System boundary <br> * exposes its output at the System boundary<br> * changes the System's State<br> * is dependent on System's State<br>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.| | ||
| | System Function IN System Process | Specifies the fact that a System Function is used in a System Process.| | ||
| | System 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.| | ||
| | System Requirement | System Requirements specify System Functions, non-functional properties, or constraints of the System.| | ||
| | System 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, <br>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 Development Documentation : Concepts : SAF_capability_F Definition | ||
|  | ||
| |Concept|Documentation| | ||
| | --- | --- | | ||
| | Operational 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.<br><br>Aliases:<br>UAF::Capability<br>NAF4::Capability| | ||
| | Operational 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.| | ||
| | SCYcomposedOF | Specifies the fact that a System Capability consists of other System Capabilities.| | ||
| | SCYdependingON | Specifies the fact that a System Capability requires another System Capability.<br><br>Aliases:<br>UAF::CapabilityDependency| | ||
| | SCYenablingOCY | Specifies the fact that an Operational Capability integrates System Capabilities to produce a specific outcome to achieve a mission objective.| | ||
| | SCYsatisfyingSHR | Specifies the fact that a System Capability satisfies one or more Stakeholder Requirements.| | ||
| | SCYspecializedBY | 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.<br><br>Aliases:<br>UAF::CapabilityGeneralization| | ||
| | SCYsupportingSUC | Specifies the fact that a System UseCase is supported by System Capabilities.| | ||
| | SFNsupportingSCY | Specifies the fact that a System Function supports one or more System Capabilities.| | ||
| | SHRrefiningOCY | Specifies the fact that an Operational Capability is refined by Stakeholder Requirements.| | ||
| | SPSenablingSCY | Specifies the fact that a System Process contributes to the provision of one or more System Capabilities in the field.| | ||
| | SPSrefiningSUC | Specifies the fact that a System Use Case is refined by one System Process.| | ||
| | SRderivingFromSR | Specifies the fact that System Requirements are derived from a Stakeholder Requirement. <br>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.| | ||
| | SRrefiningSCY | Specifies the fact that a System Capability is refined by System Requirements.| | ||
| | SUCenablingOSY | Specifies the fact that a System Use Case enables the realization of an Operational Story.| | ||
| | SUCincludingSUC | Specifies the fact that a System Use Case includes other System Use Cases. The included use case is then no longer a full System Use Case, but a partial System Use Case.| | ||
| | SUCrefiningSHR | Specifies the fact that a Stakeholder Requirement is refined by System Use Cases.| | ||
| | SUCsynthesizingSFN | Specifies the fact that a System Function is used in a System Use Case, e.g., as a Trigger, Action, or Task. <br>Note: This is a derived relationship.| | ||
| | Stakeholder 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.| | ||
| | System 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]<br>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]<br><br>Aliases:<br>UAF::Capability<br>NAF4::Capability| | ||
| | System Function | Specifies the fundamental action or task that have to take place in the System in accepting and processing the<br>inputs and in processing and generating the outputs.<br>A System Function<br> * accepts input from the System boundary <br> * exposes its output at the System boundary<br> * changes the System's State<br> * is dependent on System's State<br>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.| | ||
| | System Function IN System Process | Specifies the fact that a System Function is used in a System Process.| | ||
| | System 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.| | ||
| | System Requirement | System Requirements specify System Functions, non-functional properties, or constraints of the System.| | ||
| | System 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, <br>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).| |
Oops, something went wrong.