Agree on S-Core v0.5 "must have" process requirements #1782
Description
Following list of requirements was generated by sphinx-needs, based on the following filter: :tags: done_automation, prio_1_automation, manual. As agreed with process community, this is the minimal set of process requirements, that should be fulfilled for S-Core v0.5
Following should be done:
- Review the list and ensure, that
- all requirements are really important for S-Core v0.5
- all requirements, marked as manual, can not be automated
- Plan that all of these requirements are fulfilled by S-Core v0.5 software & establish tracking accordingly.
| ID | Status | Tags | Content | Comments |
|---|---|---|---|---|
| gd_req__arch_hierarchical_structure | valid | done_automation; architecture_design | The architectural elements shall be hierarchically structured on two levels: * Feature Level (=Logical Level) * Component Level | |
| gd_req__arch_build_blocks | valid | done_automation; architecture_design | Following architectural elements shall be defined on the respective hierarchical level: * Logical Level * Feature (feature_arc_sta) * Logical Interface (logic_arc_int) * Logical Interface Operation (logic_arc_int_op) * Component Level * Component (comp_arc_sta) * Interface (real_arc_int) * Interface Operation (real_arc_int_op) | |
| gd_req__arch_build_blocks_corr | valid | done_automation; architecture_design | For modeling the viewpoints following relations shall be used: .. figure:: ../_assets/metamodel_architectural_design.drawio.svg :width: 100% :align: center :alt: Definition of the Metamodel for Architectural Design | |
| gd_req__arch_build_blocks_dynamic | valid | done_automation; architecture_design | It shall be possible to provide the required architectural building blocks inside the dynamic architecture. | |
| gd_req__change_attr_uid | valid | done_automation; attribute; mandatory; change_management | Each Change Request shall have a unique ID. It shall be in an integer number. | |
| gd_req__change_attr_status | valid | done_automation; attribute; mandatory; change_management | Each Change Request shall have a status: * draft * in review * accepted * rejected | |
| gd_req__change_attr_milestone | valid | done_automation; attribute; mandatory; change_management | Milestone until the Change Request must be implemented (used for prioritization) | |
| gd_req__saf_attr_uid | valid | done_automation; attribute; mandatory; safety_analysis | Each Safety Analysis shall have a unique ID. It shall be in a format which is also human readable and consists of * type of Safety Analysis (DFA or FMEA) * name of analysed structural element (e.g. Persistency, FEO, etc.) * element descriptor (e.g. KVS__Open KVS or KVS__GetKeyValue) The naming convention shall be defined in the project and shall be used consistently. | |
| gd_req__req_desc_weak | valid | done_automation; check; requirements_engineering | It shall be ensured that no weak words are contained in the requirement description for: * Stakeholder Requirements * Feature Requirements * Component Requirements * Tool Requirements List of these weak words: just, about, really, some, thing, absolutely (to be extended) | |
| gd_req__req_linkage_fulfill | valid | done_automation; check; requirements_engineering | Every feature- and component requirement shall be linked to at least one parent requirement according to the defined traceability scheme: :ref:traceability concept for requirements |
|
| gd_req__configuration_uid | valid | done_automation; config_mgt | The doc-as-code tool shall check that the Id's of the configuration items (documented in doc-as-code) are unique. Note: For definition of configuration items see :need:doc_concept__configuration_process |
|
| gd_req__problem_attr_uid | valid | done_automation; problem_resolution; attribute; mandatory | Each Problem shall have a unique ID. It shall be in an integer number. | |
| gd_req__saf_structure | valid | done_automation; safety_analysis | Safety Analysis (FMEA and DFA) shall be hierarchically grouped into different levels. Following levels are defined: * Platform DFA * Feature DFA/FMEA * Component DFA/FMEA | |
| gd_req__safety_doc_status | valid | done_automation; safety_mgt | Safety plans shall contain documents references where the status is derived automatically. Note: This can be done by defining the document as a sphinx-need and using sphinx mechanisms. | |
| gd_req__req_structure | valid | done_automation; structure; requirements_engineering | Requirements shall be hierarchically grouped into three levels. Following levels are defined: * Stakeholder requirement * Feature requirement * Component requirement Additionally there shall be the following logical groups of requirements: * Assumption of use requirement * Process requirement * Tool requirement | |
| gd_req__tool_attr_uid | valid | done_automation; tool_management; attribute; mandatory | Each Tool Verification Report shall have a unique ID. | |
| gd_req__verification_independence | valid | done_automation; verification | The approver of a pull request shall differ from the author(s) of the pull request in all pull requests. | |
| gd_req__arch_model | valid | manual; architecture_design | For architecture design a model based approach should be used. The model shall consist of different architectural elements. | |
| gd_req__arch_viewpoints | valid | manual; architecture_design | The architecture shall be shown on following views on each architectural level: * Package Diagram (feat_arc_sta, comp_arc_sta) * Sequence Diagram (feat_arc_dyn, comp_arc_dyn) * Interface View (logic_arc_int, real_arc_int) Only an additional view shall be created on module level. | nmbmn |
| gd_req__arch_traceability | valid | manual; architecture_design | Requirements shall be fulfilled by an architectural element on the corresponding level. | |
| gd_req__arch_attribute_uid | valid | manual; attribute; mandatory; architecture_design | Each architectural element shall have a unique ID. It shall be in a format which is also human readable and consists of * type of architectural element * structural element (e.g. some part of the feature tree, component acronym) * keyword describing the content of the architectural element Check your project's naming conventions (should be called "doc__naming_conventions") | |
| gd_req__arch_attr_security | valid | manual; attribute; mandatory; architecture_design | Each architectural element shall have a security relevance identifier: * Yes * No | |
| gd_req__arch_attr_safety | valid | manual; attribute; mandatory; architecture_design | Each architectural element shall have a automotive safety integrity level (ASIL) identifier: * QM * ASIL_B | |
| gd_req__arch_attr_status | valid | manual; attribute; mandatory; architecture_design | Each architectural element shall have a status: * valid * invalid | |
| gd_req__arch_attr_fulfils | valid | manual; attribute; mandatory; architecture_design | Each architectural element shall be linked to a requirement. | |
| gd_req__change_attr_title | valid | manual; attribute; mandatory; change_management | Reason for the Change Request | |
| gd_req__change_attr_impact_description | valid | manual; attribute; mandatory; change_management | Exact description of the Change Request, including impact analysis on functional safety, security, implementation (schedule, risks, resources) verification (measures defined). | |
| gd_req__req_attr_uid | valid | manual; attribute; mandatory; requirements_engineering | Each requirement shall have a unique ID. It shall consist of three parts: * type of requirement * structural element (e.g. some part of the feature tree, component acronym) * keyword describing the content of the requirement. Consider the project's naming convention. | |
| gd_req__req_attr_title | valid | manual; attribute; mandatory; requirements_engineering | The title of the requirement shall provide a short summary of the description, but is not an "additional" requirement. This means for example that the word "shall" is not allowed in the title for all requirements. | |
| gd_req__req_attr_description | valid | manual; attribute; mandatory; requirements_engineering | Each requirement shall have a description. .. note:: ISO/IEC/IEEE/29148 - Systems and software engineering — Life cycle processes — Requirements engineering defines general concepts including terms and examples for functional requirements syntax. The concepts shall apply. | |
| gd_req__req_attr_type | valid | manual; attribute; mandatory; requirements_engineering | Each requirement, apart from process and tool requirements, shall have a type of one of following options: * Functional * Interface * Process * Non-Functional | |
| gd_req__req_attr_security | valid | manual; attribute; mandatory; requirements_engineering | Each requirement, apart from process and tool requirements, shall have a security relevance identifier: * Yes * No | |
| gd_req__req_attr_safety | valid | manual; attribute; mandatory; requirements_engineering | Each requirement, apart from process and tool requirements, shall have a automotive safety integrity level (ASIL) identifier: * QM * ASIL_B | |
| gd_req__req_attr_status | valid | manual; attribute; mandatory; requirements_engineering | Each requirement, apart from process and tool requirements, shall have a status: * valid * invalid | |
| gd_req__req_attr_rationale | valid | manual; attribute; mandatory; requirements_engineering | Each stakeholder requirement shall provide an attribute called rationale. The rationale shall contain the reason why the requirement is needed. | |
| gd_req__saf_attr_title | valid | manual; attribute; mandatory; safety_analysis | The title of the Safety Analysis shall provide a short summary of the description | |
| gd_req__req_attr_valid_from | valid | manual; attribute; requirements_engineering | Stakeholder and feature requirements can have a validity attribute that tells from which milestone onwards the requirement is part of a feature. | |
| gd_req__req_attr_valid_until | valid | manual; attribute; requirements_engineering | Stakeholder and feature requirements can have a validity attribute that tells until which milestone the requirement is part of a feature. | |
| gd_req__req_linkage | valid | manual; attribute; requirements_engineering | Requirements shall be linked to its adjacent level via the attribute satisfies. * stakeholder requirements <- feature requirements * feature requirements <- component requirements * workflow <- process requirements * process requirements or stakeholder requirements <- tool requirements | |
| gd_req__req_attr_req_cov | valid | manual; attribute; requirements_engineering | It shall be possible to specify the requirement coverage, meaning the requirement is covered fully by its linked children. * Yes * No | |
| gd_req__req_attr_test_covered | valid | manual; attribute; requirements_engineering | It shall be possible to specify if requirements are completely covered by the linked test cases. * Yes * No | |
| gd_req__doc_types | valid | manual; doc_mgt | There are the following document types: * document * doc_tool .. note:: The type "document" is the GENERIC type, which can be used for realizing concrete work products, with the exception of the tool verification report (which uses the "doc_tool" type). The "doc_tool" type is described in :ref:tlm_process_requirements. .. note:: Process documents are not documents realizing work products, types for that shall only used for process definition, as defined * gd_chklst * gd_guidl * gd_req * gd_temp * doc_concept * doc_getstrt * workproduct * workflow * role |
|
| gd_req__doc_attributes_manual | valid | manual; doc_mgt | Generic documents shall have the following mandatory manual attributes: * id * status and the following optional ones: * security * safety * realizes Compare also :need:gd_temp__documentation |
|
| gd_req__impl_static_diagram | valid | manual; mandatory; implementation | The static diagram shall represent the unit and their relationships using UML notations. | |
| gd_req__impl_dynamic_diagram | valid | manual; mandatory; implementation | The dynamic diagram shall represent the unit and their relationships using UML notations. | |
| gd_req__problem_attr_status | valid | manual; problem_resolution; attribute; mandatory | Each Problem shall have a status: * open * in review * in implementation * closed * rejected | |
| gd_req__problem_attr_title | valid | manual; problem_resolution; attribute; mandatory | Reason for Problem Report | |
| gd_req__problem_attr_impact_description | valid | manual; problem_resolution; attribute; mandatory | Exact description of the Problem, including potential cause and impact of the problem. Record especially, if functional safety or cybersecurity may affected here. Record potential affected parties, and if it may required to notify them about the potential problem. | |
| gd_req__problem_attr_anaylsis_results | valid | manual; problem_resolution; attribute; mandatory | Record analysis results (e.g. reason for rejection, safety, security, quality impact) as comments. | |
| gd_req__problem_attr_milestone | valid | manual; problem_resolution; attribute; mandatory | Milestone until the Problem must be implemented (used for prioritization) | |
| gd_req__tool_attr_version | valid | manual; tool_management; attribute; mandatory | Each Tool Verification Report shall have a version: * v.X.Y.Z (major, minor, patch) | |
| gd_req__tool_attr_tcl | valid | manual; tool_management; attribute; mandatory | Each Tool Verification Report shall have a tool confidence level: * LOW * HIGH | |
| gd_req__tool_attr_safety_affected | valid | manual; tool_management; attribute; mandatory | Each Tool Verification Report shall have a safety relevance identifier: * YES * NO | |
| gd_req__tool_attr_security_affected | valid | manual; tool_management; attribute; mandatory | Each Tool Verification Report shall have a security relevance identifier: * YES * NO | |
| gd_req__saf_linkage_check | valid | prio_1_automation; attribute; automated; safety_analysis | Safety Analysis shall be linked to the architecture view on the corresponding level via the attribute violates. | |
| gd_req__saf_attr_requirements_check | valid | prio_1_automation; attribute; automated; safety_analysis | Safety Analysis shall be linked to a requirement on the corresponding level via the attribute "mitigated by". | |
| gd_req__saf_attr_aou | valid | prio_1_automation; attribute; automated; safety_analysis | It shall be possible to link Aou. | |
| gd_req__arch_attr_mandatory | valid | prio_1_automation; attribute; check; architecture_design | It shall be checked if all mandatory attributes for each architectural element are provided by the user. For all elements following attributes shall be mandatory: .. needtable:: Overview mandatory requirement attributes :filter: "mandatory" in tags and "attribute" in tags and "architecture_design" in tags and type == "gd_req" and is_external == False :style: table :columns: title :colwidths: 30 | |
| gd_req__arch_linkage_safety | valid | prio_1_automation; attribute; check; architecture_design | It shall be checked that every valid safety architectural element is linked according to the defined model :need:gd_req__arch_build_blocks_corr. |
|
| gd_req__arch_linkage_safety_trace | valid | prio_1_automation; attribute; check; architecture_design | It shall be checked that valid safety architectural elements (Safety != QM) can only be linked against valid safety architectural elements. | |
| gd_req__arch_linkage_requirement | valid | prio_1_automation; attribute; check; architecture_design | It shall be checked that each architectural element (safety!=QM) is linked against at least one safety requirement (safety!=QM). It shall be checked that architectural elements with safety=QM are not linked against safety requirements (safety!=QM). | |
| gd_req__saf_attr_mandatory | valid | prio_1_automation; attribute; check; safety_analysis | It shall be checked if all mandatory attributes for each Safety Analysis are provided by the user. For all Safety Analysis following attributes shall be mandatory: .. needtable:: Overview mandatory Safety Analysis attributes :filter: "mandatory" in tags and "attribute" in tags and "safety_analysis" in tags and type == "gd_req" :style: table :columns: title :colwidths: 30 | |
| gd_req__change_attr_impact_safety | valid | prio_1_automation; attribute; mandatory; change_management | Each Change Request shall have a automotive safety integrity level (ASIL) identifier: * QM * ASIL_B | |
| gd_req__change_attr_types | valid | prio_1_automation; attribute; mandatory; change_management | * Feature * Feature Modification * Component * Component Modification Feature/Component means new Feature/Component | |
| gd_req__saf_attr_sufficient | valid | prio_1_automation; attribute; mandatory; safety_analysis | The mitigation(s) (e.g. prevention, detection or mitigation) shall be rated as sufficient with or . A mitigation can only be sufficient if a mitigation is linked via the attribute mitigation. | |
| gd_req__saf_argument | valid | prio_1_automation; attribute; mandatory; safety_analysis | The argument shall describe why the mitigation (e.g. prevention, detection or mitigation) is sufficient or not. If it is not sufficient, the argument shall describe how the mitigation can be improved to achieve sufficiency. The argument shall be written in the content. | |
| gd_req__saf_attr_status | valid | prio_1_automation; attribute; mandatory; safety_analysis | Each safety analysis shall have the status invalid until the analysis is finished. The status shall be set to valid if the analysis is finished and all issues are closed. | |
| gd_req__saf_attr_feffect | valid | prio_1_automation; attribute; mandatory; safety_analysis | Every Safety Analysis shall have a short description of the failure effect (e.g. failure lead to an unintended actuation of the analysed element) | |
| gd_req__saf_attr_failure_id | valid | prio_1_automation; attribute; mandatory; safety_analysis | Each DFA shall have a failure ID. The failure ID is used to identify the related fault <:need:gd_guidl__dfa_failure_initiators>. The failure ID links to the corresponding failure initiator which describes how a potential violation can occur. |
|
| gd_req__saf_attr_fault_id | valid | prio_1_automation; attribute; mandatory; safety_analysis | Each FMEA shall have a fault ID. The fault ID is used to identify the related fault <:need:gd_guidl__fault_models>. The fault ID links to the corresponding fault which describes how a potential violation can occur. |
|
| gd_req__saf_attr_mitigated_by | valid | prio_1_automation; attribute; optional; safety_analysis | Each violation shall have an associated mitigation (e.g. prevention, detection or mitigation) or AoU. If mitigation has not yet been implemented, do not use this option. If status == valid then mitigated_by is mandatory. | |
| gd_req__saf_attr_mitigation_issue | valid | prio_1_automation; attribute; optional; safety_analysis | If a new mitigation (e.g. prevention, detection or mitigation) is needed link to the issue and keep status invalid until mitigation is sufficient. | |
| gd_req__req_traceability | valid | prio_1_automation; attribute; requirements_engineering | Bi-directional traceability shall be provided by adding a "back-link" via attribute satisfied by (i.e. make a <-> out of the <- in :need:gd_req__req_linkage). |
|
| gd_req__req_attr_testlink | valid | prio_1_automation; attribute; requirements_engineering | It shall be possible to link requirements to tests and automatically include a link to the test case in the attribute testlink. | |
| gd_req__req_attr_version | valid | prio_1_automation; attribute; requirements_engineering | A versioning for requirements shall be provided. For this all mandatory attributes shall be taken into account: see :need:gd_req__req_check_mandatory |
|
| gd_req__req_check_mandatory | valid | prio_1_automation; check; requirements_engineering | It shall be checked if all mandatory attributes for each requirement is provided by the user. For all requirements following attributes shall be mandatory: .. needtable:: Overview mandatory requirement attributes :filter: "mandatory" in tags and "attribute" in tags and "requirements_engineering" in tags and type == "gd_req" and is_external == False :style: table :columns: title :colwidths: 30 | |
| gd_req__req_linkage_safety | valid | prio_1_automation; check; requirements_engineering | It shall be checked that (child) QM requirements (Safety == QM) can not be linked against a (parent) safety requirement (Safety != QM). Note: This ensures that safety requirements are properly derived into their children. Also a mix of safe and QM aspects in a parent is avoided by this. | |
| gd_req__doc_reviewer | valid | prio_1_automation; doc_mgt | The version management tool shall document and report (be able to show) the authorship of a document. I.e. for each change of a document the author of the changes is stored. | |
| gd_req__doc_author | valid | prio_1_automation; doc_mgt | The version management tool shall document and report (be able to show) the reviewers of a document. I.e. for each change of a document the reviewers of the change are stored. | |
| gd_req__doc_approver | valid | prio_1_automation; doc_mgt | The version management tool shall document and report (be able to show) the approver of a document. I.e. for each change of a document the approver of the change is stored, which is usually the person with "write-rights" on the document approving the merge of a Pull Request (this may also be more than one person). Note that every approver is also reviewer. | |
| gd_req__general_requirements_version | valid | prio_1_automation; general | The version of a requirement shall not change by an inspection. This means: In case the status of the requirement (see :need:gd_req__req_attr_status) is used to notify if a requirement is inspected (or another attribute is introduced), this shall be ignored for versioning. |
|
| gd_req__impl_design_code_link | valid | prio_1_automation; mandatory; implementation | The detailed design (units and interfaces in DD document) shall be linked to the source code which implements the units and interfaces in the DD. Note: Not every code element must have such a link (i.e. is represented in the detailed design), these elements are implementation detail. | |
| gd_req__problem_check_closing | valid | prio_1_automation; problem_resolution; attribute; check | ISSUEs related to Problem Reports shall not automatically closed, if linked ISSUEs or PRs are closed or merged and these ISSUEs shall be closed only manually from the :need:Committer <rl__committer>. |
|
| gd_req__problem_attr_stakeholder | valid | prio_1_automation; problem_resolution; attribute; mandatory | Assign responsible stakeholder for analyzing the problem Assign responsible stakeholder to resolve the problem | |
| gd_req__problem_attr_classification | valid | prio_1_automation; problem_resolution; attribute; mandatory | Each Problem shall have a classification identifier: * minor * major * critical * blocker | |
| gd_req__problem_attr_safety_affected | valid | prio_1_automation; problem_resolution; attribute; mandatory | Each Problem shall have a safety relevance identifier: * Yes * No Note: If neither security or safety relevance is set the bug is always quality relevant. | |
| gd_req__problem_attr_security_affected | valid | prio_1_automation; problem_resolution; attribute; mandatory | Each Problem shall have a security relevance identifier: * Yes * No Note: If neither security or safety relevance is set the bug is always quality relevant. | |
| gd_req__safety_wp_status | valid | prio_1_automation; safety_mgt | Safety plans shall contain work product references where the accumulated status is derived automatically. Note: This can be done as for documents if the work product is a single sphinx-need. For work products collections (e.g. all requirements of a component) an accumulated status is needed (e.g. like "% valid state") | |
| gd_req__tool_check_mandatory | valid | prio_1_automation; tool_management; attribute; check | It shall be checked if all mandatory attributes for each Tool Verification Report is provided by the user. For all requirements following attributes shall be mandatory: .. needtable:: Overview mandatory problem attributes :filter: "mandatory" in tags and "attribute" and "tool_management" in tags and is_external == False :style: table :columns: title :colwidths: 30 | |
| gd_req__tool_attr_status | valid | prio_1_automation; tool_management; attribute; mandatory | Each Tool Verification Report shall have a status. * draft * evaluated * qualified * released * rejected | |
| gd_req__verification_link_tests | valid | prio_1_automation; verification | For linking test suites to requirements following metadata shall be used: * Verifies * PartiallyVerifies * FullyVerifies * Description * TestType * Fault Injection (fault-injection) * Interface Test (interface-test) * Requirements-based Test (requirements-based) * Resource Usage Evaluation (resource-usage) * DerivationTechnique * Analysis of requirements (requirements-analysis) * Analysis of design (design-analysis) * Analysis of boundary values (boundary-values) * Analysis of equivalence classes (equivalence-classes) * Fuzzy testing (fuzz-testing) * Error guessing based on knowledge or experience (error-guessing) * Explorative testing (explorative-testing) More information can be found in the :need:gd_guidl__verification_guide, :need:doc_concept__verification_process, and :need:gd_guidl__verification_specification. |
|
| gd_req__verification_link_tests_cpp | valid | prio_1_automation; verification | For linking C++ test suites to requirements record properties shall be used. Attributes which are common for all test cases can be specified in the Setup Function (SetUp()), the other attributes which are specific for each test case need to be specified within the test case: .. code-block:: cpp class TestSuite : public ::testing::Test{ public: void SetUp() override { RecordProperty("TestType", ""); RecordProperty("DerivationTechnique", ""); ... } }; TEST_F(TestSuite, ) { RecordProperty("PartiallyVerifies", "ID_2, ID_3, ..."); RecordProperty("FullyVerifies", "ID_4, ID_5, ..."); RecordProperty("Description", ""); ASSERT ... } | |
| gd_req__verification_link_tests_python | valid | prio_1_automation; verification | For linking python tests to requirements metadata shall be used. For this the 'add_test_properties' decorator has been provided. You need to add it to the test and fill out: * partially_verifies OR fully_verifies * test_type * derivation_technique For allowed values for test_type & derivation_technique please check :need:gd_req__verification_link_tests Further more, this decorator will also check if your test has a docstring which should act as the description of the test. .. code-block:: python @add_test_properties( partially_verifies=["tool_req__docs_dd_link_source_code_link"], test_type="requirements-based", derivation_technique="requirements-analysis", ) def test_group_by_need_empty_list(): """Test grouping empty list of needlinks.""" ... |
|
| gd_req__verification_link_tests_rust | valid | prio_1_automation; verification | For linking Rust tests to requirements #[record_property] shall be used: .. code-block:: rust use test_properties::record_property; #[record_property("PartiallyVerifies", "ID_2, ID_3, ...")] #[record_property("FullyVerifies", "ID_4, ID_5, ...")] #[record_property("Description", "")] #[record_property("TestType", "")] #[record_property("DerivationTechnique", "")] #[test] fn test_case_function() { ... } | |
| gd_req__verification_reporting | valid | prio_1_automation; verification | The tool automation shall automatically generate the Verification reports. These may be independent documents (i.e. not integrated into sphinx documentation). The content of the reports is specified in :need:gd_temp__platform_ver_report and :need:gd_temp__mod_ver_report. |
|
| gd_req__verification_report_archiving | valid | prio_1_automation; verification | The tool automation shall automatically archive the Verification reports for releases. The reports are generated according to :need:gd_req__verification_reporting. |
|
| gd_req__verification_checks | valid | prio_1_automation; verification | The following checks shall be implemented on test metadata: - TestType and DerivationTechnique shall be set - Description shall not be empty - In a Platform Test Partially/FullyVerifies shall be set to a Platform Requirement - If Partially/FullyVerifies are set in Feature Integration Test these shall link to Feature Requirements - If Partially/FullyVerifies are set in Component Integration Test these shall link to Component Requirements - If Partially/FullyVerifies are set in Unit Test these shall link to Component Requirements |
Metadata
Metadata
Labels
No labels
Projects
Status