Requirements classification by ramceb · Pull Request #3068 · eclipse-score/score

ramceb · 2026-07-08T07:21:04Z

Classification of requirements into feature and component requirements

Several lifecycle requirements used the .. comp_req:: directive but kept copy-pasted feat_req__ IDs and derived_from links to stakeholder requirements (stkh_req__), violating score_metamodel rules: - comp_req IDs must match ^comp_req__[0-9a-z_]+$ - comp_req must derive_from a feat_req, not a stkh_req Rename the 64 affected IDs to comp_req__lifecycle__* and point derived_from at the appropriate parent feat_req, updating all cross-references in the lifecycle architecture docs accordingly. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

github-actions · 2026-07-08T09:39:56Z

The created documentation from the pull request is available at: docu-html

FScholPer

I think we should not only reclassify but also move them out to lifecycle repo and link them to feature requirements

SimonKozik · 2026-07-09T12:27:03Z

    :security: NO
    :safety: ASIL_B
-    :derived_from: stkh_req__execution_model__processes[version==1]
+    :derived_from: feat_req__lifecycle__waitfor_support[version==1]


Based on the linkage, should we think about renaming feat_req__lifecycle__waitfor_support requirement?

Maybe something like feat_req__lifecycle__conditional_startup represent functionality in a better way.

SimonKozik · 2026-07-09T12:34:58Z

    :security: NO
    :safety: ASIL_B
-    :derived_from: stkh_req__execution_model__processes[version==1]
+    :derived_from: feat_req__lifecycle__waitfor_support[version==1]


Maybe feat_req__lifecycle__terminationn_dependency could be a better fit here.

SimonKozik · 2026-07-09T12:43:45Z

    :security: NO
    :safety: ASIL_B
-    :derived_from: stkh_req__execution_model__processes[version==1]
+    :derived_from: feat_req__lifecycle__smart_watchdog_config[version==1]


My interpretation of this requirement tells me that we are talking about conditional startup here.

Maybe we should map this requirement to feat_req__lifecycle__waitfor_support?

SimonKozik · 2026-07-09T12:51:08Z

    :security: NO
    :safety: ASIL_B
-    :derived_from: stkh_req__execution_model__processes[version==1]
+    :derived_from: feat_req__lifecycle__smart_watchdog_config[version==1]


Are we sure that we are talking about watchdog monitoring here?

My interpretation of the requirement suggest, that we are talking more about existence / crash monitoring. In that case it could be linked to feat_req__lifecycle__running_processes or feat_req__lifecycle__process_monitoring

SimonKozik · 2026-07-09T12:52:50Z

    :security: NO
    :safety: ASIL_B
-    :derived_from: stkh_req__execution_model__processes[version==1]
+    :derived_from: feat_req__lifecycle__smart_watchdog_config[version==1]


I think a better fit will be feat_req__lifecycle__switch_run_targets

SimonKozik · 2026-07-09T13:06:36Z

    :security: NO
    :safety: ASIL_B
-    :derived_from: stkh_req__execution_model__processes[version==1]
+    :derived_from: feat_req__lifecycle__multi_instance_support[version==1]


This requirement sounds to me like feature requirement.

If we leave it at this level, then we should map feat_req__lifecycle__lm_ext_wdg_failed_test to this requirement. Additionally all requirements mapping to feat_req__lifecycle__lm_ext_wdg_failed_test should be probably mapped to this one.

SimonKozik · 2026-07-09T13:10:59Z

@@ -977,12 +983,12 @@ Monitoring, Notification and Recovery
    The :term:`Launch Manager` shall not trigger an external :term:`Watchdog`


Just checking. Are we sure that it is intended to have shall not trigger in this requirement?

SimonKozik · 2026-07-09T13:12:06Z

    :security: NO
    :safety: ASIL_B
-    :derived_from: stkh_req__dev_experience__logging_support[version==1]
+    :derived_from: feat_req__lifecycle__lm_ext_wdg_failed_test[version==1]


I'm not sure where this requirement should be mapped, but feat_req__lifecycle__lm_ext_wdg_failed_test doesn't sound like the right mapping.

Please note that we have quite few logging requirements, maybe we should create feature requirement for this and map them accordingly?

SimonKozik · 2026-07-09T13:19:53Z

-.. feat_req:: Configuration file support
-    :id: feat_req__lifecycle__modular_config_support
+.. comp_req:: Configuration file support
+    :id: comp_req__lifecycle__modular_config_support


We probably need feature level requirement for configuration.
Mapping configuration requirements to feat_req__lifecycle__lm_ext_wdg_failed_test doesn't sounds right.

SimonKozik · 2026-07-09T13:23:54Z

At the moment we have Run Targets and Components.

Should we also introduce modules? If not, maybe we can adapt language to better reflect current status.

ramceb · 2026-07-13T06:58:18Z

I think we should not only reclassify but also move them out to lifecycle repo and link them to feature requirements

we agreed that we do the migration in 2 steps. 1 classification of the requirements. 2 migration of comp requirements to the new repo.

Address SimonKozik's review comments on PR #3068: - Rename feat_req__lifecycle__waitfor_support to feat_req__lifecycle__conditional_startup and comp_req__lifecycle__stop_sequence to comp_req__lifecycle__termination_dependency for clarity; update all cross-references in requirements and architecture docs. - Fix comp_req derived_from mappings that incorrectly pointed to feat_req__lifecycle__smart_watchdog_config: configurable_wait_time now maps to conditional_startup, monitoring_processes to liveliness_detection, and failure_detect to switch_run_targets. - Merge the duplicate feat_req__lifecycle__process_monitoring into feat_req__lifecycle__liveliness_detection, resolving the existing TODO; re-derive dependent comp_reqs accordingly. - Promote comp_req__lifecycle__lm_self_health_check to a feat_req, and demote feat_req__lifecycle__lm_ext_watchdog_notify and feat_req__lifecycle__lm_ext_wdg_failed_test to comp_reqs derived from it, along with lm_ext_watchdog_cfg. - Introduce feat_req__lifecycle__logging_support and feat_req__lifecycle__configuration_file_support to correctly group the logging and configuration comp_reqs that were previously (incorrectly) all derived from lm_ext_wdg_failed_test. - Reword feat_req__lifecycle__clustering_modules_supp (renamed to feat_req__lifecycle__component_group_config) to reuse existing Component/Run Target terminology instead of introducing a new 'Module' term. All requirement ID cross-references verified to resolve across the docs tree. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

ramceb · 2026-07-13T07:35:52Z

Thanks for the detailed review, @SimonKozik! I pushed a follow-up commit addressing all the points:

Renamed feat_req__lifecycle__waitfor_support → feat_req__lifecycle__conditional_startup and comp_req__lifecycle__stop_sequence → comp_req__lifecycle__termination_dependency (updated all cross-references, including the architecture docs).
Fixed the three comp_reqs that were wrongly derived from smart_watchdog_config: configurable_wait_time → conditional_startup, monitoring_processes → liveliness_detection, failure_detect → switch_run_targets.
Merged feat_req__lifecycle__process_monitoring into feat_req__lifecycle__liveliness_detection (resolving the existing TODO about the duplicate), and re-derived its dependents.
Promoted lm_self_health_check to a feat_req, and demoted lm_ext_watchdog_notify/lm_ext_wdg_failed_test (+ lm_ext_watchdog_cfg) to comp_reqs under it, as you suggested.
On the "shall not trigger" wording in lm_ext_wdg_failed_test: I believe this is intentional — it describes the safety-relevant suppression of the external watchdog feed when the internal health check fails (to allow escalation), so I kept it as-is. Let me know if you read it differently.
Introduced two new feature requirements — feat_req__lifecycle__logging_support and feat_req__lifecycle__configuration_file_support — and re-mapped the logging/configuration comp_reqs that were previously all lumped under lm_ext_wdg_failed_test.
Reworded clustering_modules_supp (renamed to feat_req__lifecycle__component_group_config) to reuse the existing Component/Run Target terminology instead of introducing a new "Module" term.

Fix two score_metamodel errors introduced by the previous commit that failed the docs-build CI check: - feat_req__lifecycle__lm_self_health_check must derive from a Stakeholder Requirement (stkh_req), not another feat_req. Changed its :derived_from: from feat_req__lifecycle__multi_instance_support to stkh_req__execution_model__processes, matching sibling requirements. - feat_req__lifecycle__configuration_file_support exceeded the 45 character id length limit (47 chars). Shortened to feat_req__lifecycle__config_file_support and updated its two dependent comp_req derived_from references. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

SimonKozik · 2026-07-14T08:41:04Z

Thanks @ramceb for fixing those issues.

As for the shall not trigger requirement I see your point now, however it took me a bit to get here...

I see that we have two requirements:

comp_req__lifecycle__lm_ext_watchdog_notify
    The :term:`Launch Manager` shall trigger a notification to an external :term:`Watchdog` for each successful self monitoring test execution.

comp_req__lifecycle__lm_ext_wdg_failed_test
    The :term:`Launch Manager` shall not trigger an external :term:`Watchdog` notification if an internal health check failed.

The comp_req__lifecycle__lm_ext_wdg_failed_test sounds to me as a negative requirement and some people says this is not a good situation.
My take on this:

As we have comp_req__lifecycle__lm_ext_watchdog_notify which only triggers notification if tests passed, we may not need comp_req__lifecycle__lm_ext_wdg_failed_test to address the negative case.

We can maybe slightly reword the comp_req__lifecycle__lm_ext_watchdog_notify if we want:

The :term:`Launch Manager` shall send an alive message to the external :term:`Watchdog` after each successful self-monitoring test execution.

If we want to keep comp_req__lifecycle__lm_ext_wdg_failed_test then maybe this wording can be better:

The :term:`Launch Manager` shall cause an external :term:`Watchdog` reset if an internal health check failed.

IMHO we don't need comp_req__lifecycle__lm_ext_wdg_failed_test, but this is not a strong opinion. I will be happy with whatever you decide.

aschemmel-tech

Inline comments plus:
There are no feature and component requirements documented for the "Health Monitor" which should be derived from stkh_req__dependability__safety_features_1 - this will be solved in another PR by @pawelrutkaq.

aschemmel-tech · 2026-07-14T11:05:59Z

    :status: invalid
    :version: 1

    The :term:`Launch Manager` shall provide support for ordering the launching of


Please change this and the other feature requirements below to "The :term:Lifecycle Feature shall"

aschemmel-tech · 2026-07-14T11:08:37Z

    :security: NO
    :safety: ASIL_B
    :derived_from: stkh_req__execution_model__processes[version==1]
    :status: invalid


recommend to set the status of the requirements to "valid" (after this review), maybe with the exception of the ones which have a "TBD"?

aschemmel-tech · 2026-07-14T11:11:11Z

    :status: invalid
    :version: 1

    The Launch Manager shall be able to validate the pre-start conditions of the executable using the conditions.


for consistency please also use :term:Launch Manager as above (also in other component requirements)

aschemmel-tech · 2026-07-14T11:14:37Z

    :status: invalid
    :version: 1

    The time to wait, before SIGKILL is sent shall be configurable. In case "0" is


To be consistent with other requirements better: " The :term:Launch Manager shall offer a configuration of ..."

aschemmel-tech · 2026-07-14T11:28:52Z

    :reqtype: Functional
    :security: NO
    :safety: ASIL_B
    :derived_from: stkh_req__execution_model__processes[version==1]


I think this could also be derived from stkh_req__dependability__safety_features_1

Signed-off-by: ramceb <89037993+ramceb@users.noreply.github.com>

ramceb requested review from FScholPer, antonkri, arsibo, johannes-esr and qor-lb as code owners July 8, 2026 07:21

github-project-automation Bot added this to TLC - Technical Lead Circle and S-CORE Roadmap Jul 8, 2026

github-project-automation Bot moved this to Backlog in S-CORE Roadmap Jul 8, 2026

ramceb force-pushed the mb_review_requirements branch from 4419e4e to 2f86d5f Compare July 8, 2026 07:27

ramceb requested review from a team, AlexanderLanin, HartmannNico, MaximilianSoerenPollak, PandaeDo, aschemmel-tech, dcalavrezo-qorix, grandyholger, masc2023, pahmann, skappel29 and thilo-schmitt as code owners July 8, 2026 07:27

Requirement classification

9dc2535

Classification of requirements into feature and component requirements

ramceb force-pushed the mb_review_requirements branch from 2f86d5f to 9dc2535 Compare July 8, 2026 07:32

ramceb changed the title ~~Mb review requirements~~ Requirements classification Jul 8, 2026

S-MOHAMD mentioned this pull request Jul 8, 2026

Set valid_from attribute for all features #3064

Merged

ramceb force-pushed the mb_review_requirements branch from 4446a98 to 11cf564 Compare July 8, 2026 09:35

FScholPer reviewed Jul 8, 2026

View reviewed changes

SimonKozik reviewed Jul 9, 2026

View reviewed changes

anmittag removed request for HartmannNico, grandyholger, skappel29 and thilo-schmitt July 10, 2026 12:40

aschemmel-tech requested changes Jul 14, 2026

View reviewed changes

Merge branch 'main' into mb_review_requirements

b88aa9b

Signed-off-by: ramceb <89037993+ramceb@users.noreply.github.com>

		@@ -977,12 +983,12 @@ Monitoring, Notification and Recovery
		The :term:`Launch Manager` shall not trigger an external :term:`Watchdog`

Uh oh!

Conversation

ramceb commented Jul 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Jul 8, 2026

Uh oh!

FScholPer left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ramceb commented Jul 13, 2026

Uh oh!

ramceb commented Jul 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

SimonKozik commented Jul 14, 2026

Uh oh!

aschemmel-tech left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

ramceb commented Jul 8, 2026 •

edited

Loading

ramceb commented Jul 13, 2026 •

edited

Loading

aschemmel-tech left a comment •

edited

Loading