feat(report): add stakeholder requirements chapter to platform verification report - #875
Conversation
…cation report
Extend the platform_verification_report post-template with a
"Stakeholder Requirements" chapter placed before "Features".
Unlike feat_req, stkh_req is not scoped to a Feature, so the
requirements are collected once for the whole report via
needs_of_type("stkh_req") and filtered through the existing
req_in_report_version helper, giving the new chapter the same
report_version scoping as the feature requirements.
The chapter renders two pie charts (status and test coverage) and a
folded requirements table using the same columns as the per-feature
requirements table.
|
Documentation preview for this pull request is available at: |
| {#- Stakeholder requirements are not scoped to a Feature, so they are | ||
| collected once for the whole report rather than per-Feature like | ||
| ``feat_req``. -#} | ||
| {% set ns_stkh_reqs = namespace(list=[]) %} | ||
| {% for req in needs_of_type("stkh_req")|unique(attribute="id")|list %} | ||
| {% if req_in_report_version(req, report_version) %} | ||
| {% set ns_stkh_reqs.list = ns_stkh_reqs.list + [req["id"]] %} | ||
| {% endif %} | ||
| {% endfor %} | ||
| {% set stkh_req_filter = 'id in ' ~ id_filter_list(ns_stkh_reqs.list) %} |
There was a problem hiding this comment.
You are never displaying these, only building a list and filtering it, or am I reading it wrong?
Did you try this template out somewhere on a platform to see if it actually does what you want in this specific section?
There was a problem hiding this comment.
…ments report Pins score_docs_as_code to a26274882b0ff41187e502c7bcdd26bbf5858232, which adds the "Stakeholder Requirements" chapter to the platform verification report template (eclipse-score/docs-as-code#875). Regenerated bazel_common/score_modules_tooling.MODULE.bazel via scripts/known_good/update_module_from_known_good.py. MODULE.bazel.lock is unchanged: bazel mod deps --lockfile_mode=update produced no diff because the lockfile does not record git_override commits for score_docs_as_code.
…ments report Pins score_docs_as_code to a26274882b0ff41187e502c7bcdd26bbf5858232, which adds the "Stakeholder Requirements" chapter to the platform verification report template (eclipse-score/docs-as-code#875). main pins score_docs_as_code to the released version 8.3.0, but that release does not yet contain the stakeholder requirements chapter (the pinned commit is two commits ahead of v8.3.0). Until a release containing it exists, this overrides to the git commit via git_override instead of single_version_override. Regenerated bazel_common/score_modules_tooling.MODULE.bazel accordingly and updated MODULE.bazel.lock via `bazel mod tidy` to drop the score_docs_as_code 8.3.0 registry entries that no longer apply under the git_override.
|
@pahmann @masc2023 @aschemmel-tech @PandaeDo @RolandJentschETAS review please |
| :colwidths: 13,22,8,10,47 | ||
| :sort: id | ||
|
|
||
| {# ===================================================================== #} |
There was a problem hiding this comment.
Shouldn't we add how many of the stakeholder requirements are linked to valid feature requirements ? And if there is an mismatch in the state off the stakeholder versus feature requirement?
There was a problem hiding this comment.
In my perspective, I would ask, which features realizes which stakeholder requirement, The test link is already added, means if platform integrations tests are done, what is their coverage, but as a starter (initial) this PR is fine for me, rest can be done in up-coming PRs.
There was a problem hiding this comment.
Hello @RolandJentschETAS ,
none of this is requested by platform_verification_report.
It definitely makes sense to have such diagrams from my point of view, also for feature requirements.
We can discuss if we want this in the process community. But I think it is an extension to this PR, so this PR still can be merged as a first step.
AlexanderLanin
left a comment
AlexanderLanin
left a comment
There was a problem hiding this comment.
I think it is an extension to this PR, so this PR still can be merged as a first step.
agreed
5 participants
What
Extends the existing
platform_verification_reportpost-template with a Stakeholder Requirements chapter, placed before theFeatureschapter.Why
The platform verification report so far only covered feature-level requirements and architecture. Stakeholder requirements (
stkh_req) are the top of the requirement hierarchy and were not represented at all, so the report gave no view on their status or test coverage.How
Only
src/needs_templates/platform_verification_report.needis touched (no new template file, as requested):feat_req, astkh_reqis not scoped to a Feature, so the requirements are collected once for the whole report via the existingneeds_of_type("stkh_req")helper instead of per-Feature graph traversal.stkh_reqis filtered through the existingreq_in_report_versionhelper againstreport_version.stkh_reqcarriesvalid_fromdirectly (per the metamodel), so noderived_fromfallback is needed. An unsetreport_versionkeeps the chapter unscoped, matching the_latestreport behaviour.fully_verifies_back/partially_verifies_back)... dropdown::) with the same columns as the per-feature requirements table:id;title;safety;status;testlink.Validation
Rendered the template standalone with minijinja (the renderer actually used for
.needpost-templates) against a synthetic Need set, for both an unscoped report andreport_version=v1.0:v1.0: only thevalid_from: v1.0requirement appears, thev2.0one is correctly excludedA companion PR in
reference_integrationbumpsknown_good.jsonto this commit so the result can be seen in a real build.