diff --git a/.vscode/settings.json b/.vscode/settings.json index a3c7371a85..dca4be6a4a 100644 --- a/.vscode/settings.json +++ b/.vscode/settings.json @@ -32,5 +32,14 @@ "python.testing.unittestEnabled": false, "python.testing.pytestEnabled": true, "bazel.lsp.command": "bazel", - "bazel.lsp.args": ["run", "//:starpls_server"] + "bazel.lsp.args": [ + "run", + "//:starpls_server" + ], + "cSpell.words": [ + "docname", + "needarch", + "toctree", + "workproduct" + ] } diff --git a/process/folder_templates/features/feature_name/architecture/chklst_arc_inspection.rst b/process/folder_templates/features/feature_name/architecture/chklst_arc_inspection.rst index 28a7b6b9ca..5dcb72506a 100644 --- a/process/folder_templates/features/feature_name/architecture/chklst_arc_inspection.rst +++ b/process/folder_templates/features/feature_name/architecture/chklst_arc_inspection.rst @@ -105,7 +105,7 @@ Please note that it is mandatory to fill in the "passed" column with "yes" or "n * - ARC_02_04 - Are the interfaces between the software architectural element and other architectural elements well defined? - manual - - Check if the interface handles undefined behavior or errors; can established protocols be used; are the interfaces for inputs, outputs, and error codes documented; is loose coupling considered and only limited exposure; can unit or integration tests be written against the interface; data amount transferred; ensure no sensitive data is exposed; + - Check if the interface handles undefined behaviour or errors; can established protocols be used; are the interfaces for inputs, outputs, and error codes documented; is loose coupling considered and only limited exposure; can unit or integration tests be written against the interface; data amount transferred; ensure no sensitive data is exposed; - - - diff --git a/process/folder_templates/features/feature_name/index.rst b/process/folder_templates/features/feature_name/index.rst index 35e3f88d62..4171a1d9d1 100644 --- a/process/folder_templates/features/feature_name/index.rst +++ b/process/folder_templates/features/feature_name/index.rst @@ -149,7 +149,7 @@ How to Teach This [How to teach users, new and experienced, how to apply the CR to their work.] .. note:: - For a CR that adds new functionality or changes behavior, it is helpful to include a section on how to teach users, new and experienced, how to apply the CR to their work. + For a CR that adds new functionality or changes behaviour, it is helpful to include a section on how to teach users, new and experienced, how to apply the CR to their work. diff --git a/process/folder_templates/features/feature_name/safety_planning/index.rst b/process/folder_templates/features/feature_name/safety_planning/index.rst index c815a87537..50b6df2985 100644 --- a/process/folder_templates/features/feature_name/safety_planning/index.rst +++ b/process/folder_templates/features/feature_name/safety_planning/index.rst @@ -102,7 +102,7 @@ Safety Work products List .. attention:: The above table must be updated according to your feature safety planning. - - Fill the work producs links + - Fill the work products links Feature Safety Package ====================== diff --git a/process/folder_templates/modules/module_name/component_name/docs/architecture/chklst_arc_inspection.rst b/process/folder_templates/modules/module_name/component_name/docs/architecture/chklst_arc_inspection.rst index 653a976fc0..a72c28f84d 100644 --- a/process/folder_templates/modules/module_name/component_name/docs/architecture/chklst_arc_inspection.rst +++ b/process/folder_templates/modules/module_name/component_name/docs/architecture/chklst_arc_inspection.rst @@ -107,7 +107,7 @@ Please note that it is mandatory to fill in the "passed" column with "yes" or "n * - ARC_02_04 - Are the interfaces between the software architectural element and other architectural elements well-defined? - manual - - Check if the interface reacts on non-defined behavior or errors; can established protocols be used; are the + - Check if the interface reacts on non-defined behaviour or errors; can established protocols be used; are the interfaces for inputs, outputs, error codes documented; is loose coupling considered and only limited exposure; can unit or integration test be written against the interface; data amount transferred; no sensitive data exposure; diff --git a/process/folder_templates/modules/module_name/component_name/docs/index.rst b/process/folder_templates/modules/module_name/component_name/docs/index.rst index 6316594fd7..0128aefb13 100644 --- a/process/folder_templates/modules/module_name/component_name/docs/index.rst +++ b/process/folder_templates/modules/module_name/component_name/docs/index.rst @@ -135,7 +135,7 @@ How to Teach This [How to teach users, new and experienced, how to apply the CR to their work.] .. note:: - For a CR that adds new functionality or changes behavior, it is helpful to include a section on how to teach users, new and experienced, how to apply the CR to their work. + For a CR that adds new functionality or changes behaviour, it is helpful to include a section on how to teach users, new and experienced, how to apply the CR to their work. Rejected Ideas ============== diff --git a/process/process_areas/architecture_design/architecture_concept.rst b/process/process_areas/architecture_design/architecture_concept.rst index c0bac46111..3ecfc456d5 100644 --- a/process/process_areas/architecture_design/architecture_concept.rst +++ b/process/process_areas/architecture_design/architecture_concept.rst @@ -147,7 +147,7 @@ See :ref:`uml_diagram_selection` in guideline for further information about the Dynamic View ------------ -This view shows the *dynamic behavior* of the feature including the interaction of its components with the user. Following scenarios should be included: +This view shows the *dynamic behaviour* of the feature including the interaction of its components with the user. Following scenarios should be included: * important use cases or features: how do components execute them? * interactions at critical external interfaces: how do components cooperate with users and neighboring components? @@ -309,9 +309,9 @@ To represent the CI build tool module (for example a `Bazel Modules //! //! This implements the .... - diff --git a/process/process_areas/problem_resolution/guidance/problem_resolution_reqs.rst b/process/process_areas/problem_resolution/guidance/problem_resolution_reqs.rst index 2e6c54eb32..a770206e02 100644 --- a/process/process_areas/problem_resolution/guidance/problem_resolution_reqs.rst +++ b/process/process_areas/problem_resolution/guidance/problem_resolution_reqs.rst @@ -70,7 +70,7 @@ Problem Attributes problem. .. gd_req:: Problem attribute: analysis results - :id: gd_req__problem_attr_anaylsis_results + :id: gd_req__problem_attr_analysis_results :status: valid :tags: manual_prio_1, problem_resolution, attribute, mandatory :satisfies: wf__problem_create_pr, wf__problem_analyze_pr, wf__problem_initiate_monitor_pr, wf__problem_close_pr diff --git a/process/process_areas/problem_resolution/problem_resolution_workflow.rst b/process/process_areas/problem_resolution/problem_resolution_workflow.rst index c3ea2fdc1f..9d6eda8c8f 100644 --- a/process/process_areas/problem_resolution/problem_resolution_workflow.rst +++ b/process/process_areas/problem_resolution/problem_resolution_workflow.rst @@ -70,11 +70,11 @@ For a detailed explanation of workflows and their role within the process model, The Problem Resolution is implemented and monitored. - This may require Change Requests or other activities, inlcuding creating ISSUEs and PRs. + This may require Change Requests or other activities, including creating ISSUEs and PRs. These are linked to the Problem and monitored until closure. The Problem Resolution is done, if all linked activities has been closed and confirmed. - Before closing the Problem Resoultion, :need:`Committer ` must check the + Before closing the Problem Resolution, :need:`Committer ` must check the correctness. The :need:`Committer ` may still reject it, thus the status is set to "rejected". diff --git a/process/process_areas/requirements_engineering/requirements_concept.rst b/process/process_areas/requirements_engineering/requirements_concept.rst index 261ae4a7f8..3242dcbe20 100644 --- a/process/process_areas/requirements_engineering/requirements_concept.rst +++ b/process/process_areas/requirements_engineering/requirements_concept.rst @@ -113,7 +113,7 @@ i.e. the assumption on what content is needed, which shall be matched by the use Feature Requirements ==================== -The *Feature Requirements* derived from stakeholder requirements address mainly the integration level of SW modules and components. These shall describe the behavior of the feature on platform level shall be described including the correlations of the integrated components. They serves mainly as an input for (SW + Safety) Architects, Testers, Integrators and are derived from the *Stakeholder Requirements*. To provide an example +The *Feature Requirements* derived from stakeholder requirements address mainly the integration level of SW modules and components. These shall describe the behaviour of the feature on platform level shall be described including the correlations of the integrated components. They serves mainly as an input for (SW + Safety) Architects, Testers, Integrators and are derived from the *Stakeholder Requirements*. To provide an example .. code-block:: text @@ -124,7 +124,7 @@ However the detailed interaction of the underlying components itself which is re Component Requirements ====================== -The lowest abstraction level is represented by the *component requirements*. They are derived from *feature requirements* and describe component specific implementation details. It is described which behavior a component itself needs to fulfil in the context of the feature, e.g. +The lowest abstraction level is represented by the *component requirements*. They are derived from *feature requirements* and describe component specific implementation details. It is described which behaviour a component itself needs to fulfil in the context of the feature, e.g. .. code-block:: text diff --git a/process/process_areas/safety_analysis/safety_analysis_concept.rst b/process/process_areas/safety_analysis/safety_analysis_concept.rst index e94281bb59..a200bc741c 100644 --- a/process/process_areas/safety_analysis/safety_analysis_concept.rst +++ b/process/process_areas/safety_analysis/safety_analysis_concept.rst @@ -144,7 +144,7 @@ The Safety Analysis (DFA and FMEA) shall consider the architectural elements on 1. **Platform Level**: At this level, the focus is on the overall feature architecture to analyse if there are failures that effects more than one feature. - | **Example DFA:** Dependencies between features shall be analysed. This could be the usage of modules by different features, shared libraries or shared services. A common cause failure could be a erroneous signal that effects the behavior of several functions. + | **Example DFA:** Dependencies between features shall be analysed. This could be the usage of modules by different features, shared libraries or shared services. A common cause failure could be a erroneous signal that effects the behaviour of several functions. 2. **Feature Level**: This level involves a more detailed analysis of individual components within the feature. The analysis shall consider the internal structure of components and their interactions with other components in the feature. diff --git a/process/process_areas/safety_management/safety_management_concept.rst b/process/process_areas/safety_management/safety_management_concept.rst index 6de327cf19..87c76e0d97 100644 --- a/process/process_areas/safety_management/safety_management_concept.rst +++ b/process/process_areas/safety_management/safety_management_concept.rst @@ -43,11 +43,11 @@ Stakeholders * Main responsible to ensure ISO 26262 compliance in the project * Create/Maintain Safety Plan - * Perform Formal Reviews (for safety work products not in his resposibility area) + * Perform Formal Reviews (for safety work products not in his responsibility area) * Approve Component Classification * Approve Safety Package * Approve Safety Audit - * Approve Formal Reviews (for safety work products in his resposibility area) + * Approve Formal Reviews (for safety work products in his responsibility area) * Approve Safety Manual * Monitor/Verify Safety * Impact Analysis of Change Request diff --git a/process/process_areas/verification/guidance/verification_methods.rst b/process/process_areas/verification/guidance/verification_methods.rst index 6779cd4b51..44cd5aee71 100644 --- a/process/process_areas/verification/guidance/verification_methods.rst +++ b/process/process_areas/verification/guidance/verification_methods.rst @@ -261,7 +261,7 @@ The following perspectives are included in ``equivalence-classes``: - **Improve Test Coverage** By testing at least one value from each partition, you ensure that you've covered all the - different behaviors of the software. + different behaviours of the software. - **Address Different Input Types** EP is applicable to various input types, including numerical ranges, enumerated values, @@ -298,7 +298,7 @@ How to perform the analysis: Classes that contain invalid input values (out of range, incorrect data type, etc.). - **Special Cases** - Classes representing specific or unusual input values that might trigger special behavior + Classes representing specific or unusual input values that might trigger special behaviour in the software. **3. Define Test Values** @@ -324,7 +324,7 @@ Fuzzy Testing Fuzzy Testing, often called Fuzz Testing, is a software testing technique that involves providing invalid, unexpected, or random data as inputs to a component or system to detect defects. The goal of fuzzy testing is to expose unhandled exceptions, memory leaks, assertion failures, and other -critical issues by generating semi-random inputs and observing the system's behavior. +critical issues by generating semi-random inputs and observing the system's behaviour. The following perspectives are included in ``fuzz-testing``: @@ -359,8 +359,8 @@ How to perform fuzzy testing: **3. Generate Fuzzy Inputs** Create inputs that are slightly malformed or unexpected, either through complete randomization or by mutating valid inputs. - **4. Monitor System Behavior** Execute the system with fuzzy inputs and monitor for crashes, - hangs, memory leaks, or other unexpected behaviors. + **4. Monitor System behaviour** Execute the system with fuzzy inputs and monitor for crashes, + hangs, memory leaks, or other unexpected behaviours. **5. Analyze and Fix Issues** When a problem is detected, analyze the input that caused it and fix the underlying issue in the code. diff --git a/process/process_areas/verification/verification_concept.rst b/process/process_areas/verification/verification_concept.rst index 541f13321c..1643dc639a 100644 --- a/process/process_areas/verification/verification_concept.rst +++ b/process/process_areas/verification/verification_concept.rst @@ -160,10 +160,10 @@ tests or component tests. This linking is done using metatags. This is also true integration tests linking to the component requirements and architecture. Traceability of feature integration tests shall be established through linking those test cases to -feature requirements and architecture as features describe the integrated behavior of all components. +feature requirements and architecture as features describe the integrated behaviour of all components. Traceability of platform integration tests shall be established through linking those test cases to -stakeholder requirements as stakeholder requirements describe the platform behavior. +stakeholder requirements as stakeholder requirements describe the platform behaviour. Note that all the above tests shall only link to requirements of type "Functional" and "Interface". The verification of requirements of types "Process" and "Non-Functional" will be done via Analysis, diff --git a/process/standards/aspice_40/iic/iic-17.rst b/process/standards/aspice_40/iic/iic-17.rst index 42411be9d6..41a3505615 100644 --- a/process/standards/aspice_40/iic/iic-17.rst +++ b/process/standards/aspice_40/iic/iic-17.rst @@ -114,5 +114,5 @@ Needs are derived from Work Breakdown structure and schedule -.. needextend:: "c.this_doc()" - :+tags: aspice40_iic17 +.. needextend:: "c.this_doc()" + :+tags: aspice40_iic17 diff --git a/process/standards/aspice_40/swe/swe.2.rst b/process/standards/aspice_40/swe/swe.2.rst index 1e2283417c..c70b19a3c0 100644 --- a/process/standards/aspice_40/swe/swe.2.rst +++ b/process/standards/aspice_40/swe/swe.2.rst @@ -137,5 +137,5 @@ Base practices architecture to all affected parties. -.. needextend:: "c.this_doc()" - :+tags: aspice40_swe2 +.. needextend:: "c.this_doc()" + :+tags: aspice40_swe2 diff --git a/process/standards/iso26262/iso26262.rst b/process/standards/iso26262/iso26262.rst index 6e5a4293bf..6ca57c7288 100644 --- a/process/standards/iso26262/iso26262.rst +++ b/process/standards/iso26262/iso26262.rst @@ -1351,7 +1351,7 @@ Part 8: Supporting processes :status: valid - .. std_wp:: support_8522 + .. std_wp:: support_852 :id: std_wp__iso26262__support_852 :status: valid