docs: initial draft of requirement process #377
Conversation
Requirements Process description including: - contept - getting startet - process requirements - checklists - templates fixed #308 Also-by: aschemmel-tech
|
The created documentation from the pull request is available at: docu-html |
| # ******************************************************************************* | ||
|
|
||
| Workproducts Requirements Engineering | ||
| ##################################### |
There was a problem hiding this comment.
Work Product View in Sphinx shows input and output, complies with is that intended?
| Workflow Requirements Engineering | ||
| ################################# | ||
|
|
||
| .. workflow:: Create/Maintain Stakeholder requirements |
There was a problem hiding this comment.
Sphinx Docs does not show the attribute as expected, Policies shall be has input, but is is input to, need to rework metamodel
| ################################# | ||
|
|
||
| .. workflow:: Create/Maintain Stakeholder requirements | ||
| :id: WF__req__stkh_req |
There was a problem hiding this comment.
WF__ --> wf__ for all, see wp__
| :supported_by: RL_safety_manager | ||
| :input: WP_POLICIES, WP_ISSUE_TRACK_SYSTEM | ||
| :output: wp__requirements__stkh | ||
| :contains: GD_TEMP__req__stkh_req, GD_TEMP__req__formulation, GD_REQ__req__linkage, GD_REQ__req__attr_impl, GD_REQ__req__attr_testlink, GD_REQ__req__attr_hash, GD_REQ__req__linkage_fulfill, GD_REQ__req__linkage_architecture, GD_REQ__req__linkage_safety, GD_REQ__req__attr_mandatory |
| :contains: GD_TEMP__req__comp_req, GD_TEMP__req__formulation, GD_REQ__req__linkage, GD_REQ__req__attr_impl, GD_REQ__req__attr_testlink, GD_REQ__req__attr_hash, GD_REQ__req__linkage_fulfill, GD_REQ__req__linkage_architecture, GD_REQ__req__linkage_safety, GD_REQ__req__attr_mandatory | ||
| :has: DOC_CONCEPT__req__process, DOC_GETSTRT__req__process | ||
|
|
||
| On the lowest level the component requirements are created and maintained. This can be done by any contributor and will be approved by a committer. If needed a safety manager can provide support. |
There was a problem hiding this comment.
Safety and/or Security Manager?
| ASPICE Requirements | ||
| =================== | ||
|
|
||
| .. needtable:: Overview of SWE1 ASPICE Requirements |
There was a problem hiding this comment.
ASPICE standard is now available in another PR
| Requirement Levels | ||
| ****************** | ||
|
|
||
| Based on the inputs of the previous chapter the types of requirements which need to be implemented in the project can be derived. The defined levels are shown in the *Building Blocks Meta Model* <TBD> |
There was a problem hiding this comment.
You can link also to General Concept, another PR
| * Verify that the specification is fulfilled by the elements under test | ||
| * Consider AoUs for test case specification | ||
|
|
||
| #. :need:`Safety Architect <RL_safety_manager>` |
There was a problem hiding this comment.
Security Architect,
Trust Boundary Analysis, Defense in Depth Analysis
Qualitative Security Analysis (TARA or at least Attack Potential Analysis with impact category Safety)
| * - Attribute | ||
| - Description | ||
| * - Status | ||
| - The status for a requirement can either be valid or invalid. The reasoning for this is that the goal is to only have valid requirements in the main branch. So a status *draft* is not required. It is obvious that the requirement is in the status draft as long as the PR is not merged. |
There was a problem hiding this comment.
Is valid, invalid still in sync with our metamodel?
| * or by containing those in Platform Safety Manual, if AoU cannot be fulfilled by platform but need to be satisfied by the user of the platform | ||
|
|
||
|
|
||
| .. _aou_traceability: |
There was a problem hiding this comment.
Can be linked to general_concept, part of another PR
|
|
||
| process_areas/requirements_engineering/index.rst | ||
|
|
||
|
|
||
| Process Role definition |
There was a problem hiding this comment.
No additional Roles + List of contributing roles + Link to table in getting started
|
|
||
| * Requirements for Integration | ||
|
|
||
| ISO26262 Requirements |
There was a problem hiding this comment.
Remove List of Standard Requirements
|
|
||
| More details about the generation of the automated attributes are explained in the following chapter where the general workflow for generating requirements including their status is shown. | ||
|
|
||
| For creating requirements templates are available for each specific type: :ref:`requirement templates` |
There was a problem hiding this comment.
Remove Link to Templates, not required for concept
| Reviews of the Requirements | ||
| *************************** | ||
|
|
||
| Some of the checks cannot be performed automatically. Therefore a manual inspection of the requirements is needed. The requirement review itself is triggered when a contributor wants to trigger a requirement review. For this review a checklist is available: :need:`GD_CHKLST__req__inspection`. |
There was a problem hiding this comment.
Remove Link to Templates + Add Link to General Review Guide
|
|
||
| The standards require that a requirement can be traced throughout the complete hierarchy levels including its implementation and verification <TBD: Link>. In this project it is implemented the following way: | ||
|
|
||
| In general the traceability is visualized is in main development work product traceability model (:numref:`wp_traceability_model`). |
There was a problem hiding this comment.
| In general the traceability is visualized is in main development work product traceability model (:numref:`wp_traceability_model`). | |
| In general the traceability is visualized in main development work product traceability model (:numref:`wp_traceability_model`). |
|
|
||
| The component shall provide API calls to read and interpret every field of a JSON body in C++ | ||
|
|
||
| AoU Requirements |
There was a problem hiding this comment.
| AoU Requirements | |
| Assumption of Use Requirements |
| Feature Requirements | ||
| ==================== | ||
|
|
||
| The next level of requirements addresses mainly the integration level of SW modules and components. On this level the behavior of the feature on platform level shall be described including the correlations of the integrated components. It serves mainly as an input for (SW + Safety) Architects, Testers, Integrators. Those so called *Feature Requirements* are derived from the *Stakeholder Requirements*. To provide an example |
There was a problem hiding this comment.
| The next level of requirements addresses mainly the integration level of SW modules and components. On this level the behavior of the feature on platform level shall be described including the correlations of the integrated components. It serves mainly as an input for (SW + Safety) Architects, Testers, Integrators. Those so called *Feature Requirements* are derived from the *Stakeholder Requirements*. To provide an example | |
| The *Feature Requirements* addresses mainly the integration level of SW modules and components. These shall describe the behavior of the feature on platform level including the correlations of the integrated components. These serves mainly as an input for (SW + Safety) Architects, Testers, Integrators. Those so called *Feature Requirements* are derived from the *Stakeholder Requirements*. To provide an example |
| * Stakeholder requirements | ||
| * Feature requirements | ||
| * Component requirement | ||
| * Assumption of use |
There was a problem hiding this comment.
| * Assumption of use | |
| * Assumption of use requirement |
|
|
||
| Following levels are defined: | ||
|
|
||
| * Stakeholder requirements |
There was a problem hiding this comment.
| * Stakeholder requirements | |
| * Stakeholder requirement |
| Following levels are defined: | ||
|
|
||
| * Stakeholder requirements | ||
| * Feature requirements |
There was a problem hiding this comment.
| * Feature requirements | |
| * Feature requirement |
| * last part of the feature tree | ||
| * keyword describing the content of the requirement. | ||
|
|
||
| The naming convention is defined here: TBD |
| :status: valid | ||
| :tags: attribute, mandatory | ||
|
|
||
| Each requirement shall have a type of one of following options: |
There was a problem hiding this comment.
Do we have to support multi selection. E.g. A legal requirement can request a Non-Functional requirement. What shall be selected here?
Requirements Process description including:
fixed #308
Also-by: aschemmel-tech