Add artifacts for requirements analysis#467
Conversation
Resolves: eclipse-score/score#577 Signed-off-by: Philipp Ahmann <Philipp.Ahmann@de.bosch.com>
pahmann
requested review from
PandaeDo,
PhilipPartsch,
aschemmel-tech and
masc2023
as code owners
|
The created documentation from the pull request is available at: docu-html |
| :tags: verification | ||
| :responsible: rl__contributor | ||
| :approved_by: rl__committer, rl__testing_community | ||
| :supported_by: rl__safety_manager, rl__testing_community |
There was a problem hiding this comment.
rl_testing_community is supporter and approver? Why not supported bs Security Manager?
There was a problem hiding this comment.
Thanks for spotting this. I will change it.
| .. workproduct:: Requirement Analysis | ||
| :id: wp__verification_req_analysis | ||
| :status: valid | ||
| :complies: std_wp__iso26262__software_951 |
There was a problem hiding this comment.
Is that no the requirement specification as WP? Should that not part of the verification report?
|
|
||
| Tag: **Covered-by-design-review.** | ||
| The fulfillment of this requirement shall be verified as part of feature/component design reviews | ||
| (for feature/component requirements) respective software architectural design or software detailed design reviews. |
There was a problem hiding this comment.
for architecture we have already other analysis and also for dd we have checklists?
There was a problem hiding this comment.
Are these analysis types ending up in a traceable artifact which gets linked to requirements and has a status which says that it is properly implemented?
There was a problem hiding this comment.
Compare meta model, the safety analysis are traceably to architecture to requirements, but in general, you asking for non-functional requirements, architectures and detailed design are not non-functional requirements, and there are always derived from requirements and tested by integration tests. Nevertheless code inspection, review is additionally required
There was a problem hiding this comment.
Why introducing new documents, and do not add it to they requirements checklists?
There was a problem hiding this comment.
Do you mean something like: Are all requirements which were not able to be tested with reasonable efforts confirmed by a design and code review? I can add this to the checklist as an alternative to my proposal.
There was a problem hiding this comment.
No, all requirements needs to be inspected as defined here, https://eclipse-score.github.io/process_description/main/general_concepts/score_review_concept.html, using requirements checklist, which is already part of template folder and rolled out already, why not use this and add rationale to add, what you are requiring, instead of introducing new templates in addition
| - Adjust ``safety`` and ``tags`` according to your needs | ||
|
|
||
|
|
||
| Rational |
There was a problem hiding this comment.
I think it might be helpful to give some advice here. Some guys as me might start to copy all templates into a new feature description. I would have to look into the processes description what I have to do here. A short summary of the description that's there would be very helpful.
Signed-off-by: Philipp Ahmann <philipp.ahmann@de.bosch.com>
This reverts commit 65ab6c5. Signed-off-by: Philipp Ahmann <philipp.ahmann@de.bosch.com>
Signed-off-by: Philipp Ahmann <philipp.ahmann@de.bosch.com>
Signed-off-by: Philipp Ahmann <philipp.ahmann@de.bosch.com>
3 participants
Requirement analysis is added as a manual process workflow to verify "non functional" requirements which cannot be checked by test. For this an "analysis specification" template
doc__<component|feature>_name_req_analysisis defined and added to the folder template. Alternative is to add this to the requirement inspection template.Resolves: eclipse-score/score#577