Workflows and Work Products

Workflows and Work Products

S-CORE defines six specific workflows for requirements engineering and eight formal work products. This module walks through each workflow, its inputs and outputs, its responsible parties, and how the work products satisfy the applicable standards. The module closes with the end-to-end traceability picture.

4.1 Overview of the Six Workflows

All six creation workflows can be initiated as part of a Change Request — the Change Management process is the single entry point for all content changes in S-CORE.

The Monitor/Verify Requirements workflow (wf__monitor_verify_requirements) is responsible for inspecting the full requirements set. Unlike the creation workflows it is owned by the Committer, who checks all requirement levels and safety manuals against the inspection checklist (gd_chklst__req_inspection). Its output is either an updated issue tracker entry or a completed Requirements Inspection work product.

Safety Managers (rl__safety_manager) are supported_by in the three stakeholder/feature workflows; both Safety and Security Managers (rl__security_manager) are supported_by in the two AoU workflows at feature and component level.

4.2 Workflow: Stakeholder Requirements and SW-Platform AoU

Purpose: Establish the top-level specification of what the platform must contain. This workflow produces the assumed Technical Safety Requirements for the SEooC.

Inputs: wp__policies, wp__issue_track_system

Outputs: wp__requirements_stkh, wp__requirements_sw_platform_aou

Key guidance templates available: gd_temp__req_stkh_req, gd_temp__req_formulation

4.3 Workflow: Feature Requirements

Purpose: Break down stakeholder requirements into feature-level specifications that describe integration behaviour independent of implementation.

Inputs: wp__requirements_stkh, wp__issue_track_system

Output: wp__requirements_feat

Feature requirements are the primary driver of SW Architecture work. The SW Architect reads them to derive the feature architecture that allocates behaviour to components.

4.4 Workflows: AoU Requirements

Feature AoUs and Component AoUs are managed by their own workflows because they involve additional inputs from architecture work products and feed directly into the Safety Manual artefacts:

• Feature AoU (wf__req_feat_aou):
• Extra input: wp__feature_arch

• Additional output: wp__platform_safety_manual

• Component AoU (wf__req_comp_aou):

• Extra input: wp__component_arch
• Additional output: wp__module_safety_manual

4.5 Work Products and Their Compliance Tags

Each work product carries compliance tags that map it to the specific standard clauses it satisfies. Understanding these tags is important for auditors and safety managers.

The Requirements Inspection work product is based on a structured checklist and may be integrated into requirements or version management tooling. It addresses the ISO 26262 requirement for formal review of SW requirements.

4.6 End-to-End Traceability

The S-CORE traceability model connects every requirement from its origin at stakeholder level down to the implementation artefacts and verification evidence:

Stakeholder Requirements
      │ derived_from
      ▼
Feature Requirements ──────────────────────► Feature AoU
      │ derived_from
      ▼
Component Requirements ────────────────────► Component AoU
      │ implemented_by (auto)   │ verified_by (auto)
      ▼                         ▼
   Source code              Test cases

4.7 Using the Tooling

The S-CORE Docs-as-Code tool provides:

1. Requirement templates — pre-formatted stubs for each requirement type that enforce the mandatory attribute set.
2. Build-time validation — attribute completeness, version link consistency, linkage rule enforcement, and safety attribute propagation checks.
3. Coverage reports — automatically generated views showing which requirements lack implemented_by or verified_by links (coverage gaps).
4. PR-based review workflow — all requirement changes go through a pull request; the Committer or Project Lead review is recorded in git history.