docs: improve req process reqs for tooling#32
Conversation
Ref: closes #28
aschemmel-tech
requested review from
AlexanderLanin,
MaximilianSoerenPollak and
hoe-jo
|
The created documentation from the pull request is available at: docu-html |
| Based on the requirement versioning it shall be checked if a parent requirement was updated but not the linked child requirements. | ||
| In case an update was detected, the attribute requirement covered shall be set to "No" |
There was a problem hiding this comment.
Thanks for clarifying this. 'Requirement covered' still is a bit weird sounding for this explanation but I think this makes it clear for us what to do. 👍
There was a problem hiding this comment.
I'm not quite clear on the concept, as this sounds like we need to change the "requirement covered" automatically (and instantly) by modifying the rst files. But this is so far into the future, we don't need to clarify right now.
MaximilianSoerenPollak
left a comment
MaximilianSoerenPollak
left a comment
There was a problem hiding this comment.
Makes sense from my side now.
Thanks for adapting.
aschemmel-tech
force-pushed
the
aschemmel-tech-correct-req-process-req
branch
from
c8c4467 to
08bd11f
Compare
|
|
||
| Additionally there shall be the following logical groups of requirements: | ||
| * Assumption of use requirement | ||
| * Process requirement |
There was a problem hiding this comment.
"gd_req" is a process requirement? What about e.g. "wf__req"? Is "process requirement" an undefined group here?
There was a problem hiding this comment.
wf__req should be a workflow of the requirements process, not a requirement. Process requirement = gd_req - Let's not mention standard requirements here as those are treated differently and I would say these are described in our process metamodel.
aschemmel-tech
force-pushed
the
aschemmel-tech-correct-req-process-req
branch
from
08bd11f to
d1e4a3d
Compare
| * For the remaining attributes only predefined values can be used. A more detailed description can be found here: :ref:`attributes of the requirements` | ||
| * Note that "rationale" is only mandatory for Stakeholder Requirements ... | ||
| * and process requirements do not need security and safety because these can be derived from the standards they comply to (as well type attributes as these would all be "Non-functional") | ||
|
|
There was a problem hiding this comment.
On that thought: Do feature requirements also need the security attribute? Or is the security determined from the feature architecture. This would mean that only component requirements would contain the attribute security?
| :satisfies: wf__req__feat_req, wf__req__comp_req | ||
|
|
||
| Each requirement shall have a security relevance identifier: | ||
| Each requirement (apart from proccess req) shall have a security relevance identifier: |
There was a problem hiding this comment.
As mentioned above: do stakeholder and feature requirements also need the security attribute?
There was a problem hiding this comment.
yes, why do you think, there is a difference from safety attribute?
| :satisfies: wf__req__stkh_req, wf__req__feat_req, wf__req__comp_req | ||
|
|
||
| Each requirement shall have a automotive safety integrity level (ASIL) identifier: | ||
| Each requirement (apart from proccess req) shall have a automotive safety integrity level (ASIL) identifier: |
masc2023
left a comment
masc2023
left a comment
There was a problem hiding this comment.
Merge as it is now, continue for further improvements with another PR
5 participants
Ref: closes #28