diff --git a/process/conf.py b/process/conf.py index a5425b1780..8ca547f795 100644 --- a/process/conf.py +++ b/process/conf.py @@ -35,5 +35,93 @@ html_static_path = ["_assets"] html_css_files = ["custom.css"] +# Training portals are pre-generated into trainings/_portals/ by build.py. +# This copies the subdirectory tree (e.g. requirements_engineering/) verbatim +# into the Sphinx HTML output root so portals are served alongside the docs. +html_extra_path = ["trainings/_portals"] + +# Exclude training source files and generated portal files from Sphinx processing. +# - trainings/*/source/** : Markdown source files for the training portals +# - trainings/trainings_templates/** : Template files, not Sphinx documents +# - trainings/_portals/** : Generated portal HTML (served via html_extra_path) +exclude_patterns = [ + "trainings/*/source/**", + "trainings/trainings_templates/**", + "trainings/_portals/**", +] + # :need:`{title}` is used in the needs templates to display the title of the need needs_role_need_template = "{title}" + + +# --------------------------------------------------------------------------- +# Training portal build hook +# +# Automatically regenerates all training portals before Sphinx processes the +# documentation. build.py requires the 'markdown' package which is NOT part +# of the docs-as-code Sphinx environment, so it is run via the dedicated +# .venv virtual environment. If that venv is absent it is created +# and the required packages are installed automatically. +# --------------------------------------------------------------------------- + +def _build_training_portals(app): + """Sphinx builder-inited event handler: regenerate all training portals.""" + import os, subprocess, sys + from pathlib import Path + + conf_dir = Path(app.confdir) # …/process/ + repo_root = conf_dir.parent # …/process_description/ + venv_dir = repo_root / ".venv" + venv_python = venv_dir / "bin" / "python" + + # Locate all training source build scripts + build_scripts = sorted(conf_dir.glob( + "trainings/*/source/build.py" + )) + if not build_scripts: + return + + # Ensure the venv exists with the required packages + if not venv_python.exists(): + reqs_file = build_scripts[0].parent / "requirements.txt" + try: + subprocess.run( + [sys.executable, "-m", "venv", str(venv_dir)], + check=True, capture_output=True, + ) + if reqs_file.exists(): + subprocess.run( + [str(venv_python), "-m", "pip", "install", "-q", + "-r", str(reqs_file)], + check=True, capture_output=True, + ) + except Exception as exc: + import warnings + warnings.warn( + f"[trainings] Could not create .venv_training: {exc}\n" + " Training portals will not be regenerated. " + "Run source/build.py manually.", + stacklevel=1, + ) + return + + # Run each build script + for script in build_scripts: + try: + subprocess.run( + [str(venv_python), str(script)], + cwd=str(script.parent), + check=True, capture_output=True, + ) + print(f"[trainings] Built portal: {script.parent.parent.name}") + except subprocess.CalledProcessError as exc: + import warnings + warnings.warn( + f"[trainings] Portal build failed for {script.parent.parent.name}:\n" + f" {exc.stderr.decode(errors='replace').strip()}", + stacklevel=1, + ) + + +def setup(app): + app.connect("builder-inited", _build_training_portals) diff --git a/process/index.rst b/process/index.rst index 9f3de22805..306e20c2c8 100644 --- a/process/index.rst +++ b/process/index.rst @@ -274,6 +274,17 @@ and they include the available templates for the work products already in the ri folder_templates/index.rst +Trainings +--------- + +Interactive self-paced training portals for the S-CORE process areas: + +.. toctree:: + :maxdepth: 1 + + trainings/index.rst + + Glossary -------- diff --git a/process/trainings/_portals/requirements_engineering/app.js b/process/trainings/_portals/requirements_engineering/app.js new file mode 100644 index 0000000000..83da212d05 --- /dev/null +++ b/process/trainings/_portals/requirements_engineering/app.js @@ -0,0 +1,188 @@ +/* + * Copyright (c) 2026 Contributors to the Eclipse Foundation + * + * See the NOTICE file(s) distributed with this work for additional + * information regarding copyright ownership. + * + * This program and the accompanying materials are made available under the + * terms of the Apache License Version 2.0 which is available at + * https://www.apache.org/licenses/LICENSE-2.0 + * + * SPDX-License-Identifier: Apache-2.0 + * + * AI Disclosure: This file was largely AI-generated. The AI-generated + * portions are made available under CC0-1.0 and not subject to the + * project's license. The human contributor has reviewed and verified + * that the code is correct. + * SPDX-License-Identifier: CC0-1.0 + * Assisted-by: Claude Sonnet 4.6 + */ + +/* S-CORE Requirements Engineering Training Portal — Progress & Quiz Logic */ + +const MODULES = [ + { id: 'index', label: 'Course Overview', url: 'index.html' }, + { id: 'module-1', label: 'Why Requirements Engineering?', url: 'module-1.html' }, + { id: 'module-2', label: 'Requirement Levels and Types', url: 'module-2.html' }, + { id: 'module-3', label: 'Requirement Attributes and Quality', url: 'module-3.html' }, + { id: 'module-4', label: 'Workflows and Work Products', url: 'module-4.html' }, + { id: 'quiz-1', label: 'Checkpoint Quiz', url: 'quiz-1.html', isQuiz: true }, +]; + +function getProgress() { + const raw = localStorage.getItem('score-re-progress'); + return raw ? JSON.parse(raw) : {}; +} +function markComplete(id) { + const p = getProgress(); p[id] = true; localStorage.setItem('score-re-progress', JSON.stringify(p)); + updateProgressBar(); +} +function isComplete(id) { return !!getProgress()[id]; } + +function updateProgressBar() { + const p = getProgress(); + const total = MODULES.filter(m => m.id !== 'index').length; + const done = MODULES.filter(m => m.id !== 'index' && p[m.id]).length; + const pct = Math.round((done / total) * 100); + document.querySelectorAll('.progress-bar-inner').forEach(el => el.style.width = pct + '%'); + document.querySelectorAll('.progress-pct').forEach(el => el.textContent = pct + '%'); + document.querySelectorAll('.progress-count').forEach(el => el.textContent = done + ' / ' + total + ' complete'); + MODULES.forEach(m => { + const a = document.querySelector(`#sidebar nav a[data-id="${m.id}"]`); + if (!a) return; + const icon = a.querySelector('.nav-icon'); + if (p[m.id]) { a.classList.add('completed'); icon.textContent = '✓'; } + }); +} + +function buildSidebar(activeId) { + const p = getProgress(); + const sb = document.getElementById('sidebar'); + if (!sb) return; + + const total = MODULES.filter(m => m.id !== 'index').length; + const done = MODULES.filter(m => m.id !== 'index' && p[m.id]).length; + const pct = Math.round((done / total) * 100); + + const modules = MODULES.filter(m => m.id !== 'index'); + const navGroup = (label, items, startIdx) => ` +
${label}
+ + `; + + sb.innerHTML = ` +
+

S-CORE
Requirements
Engineering

+

Eclipse Foundation

+
+
+
+ ${done} / ${total} complete + ${pct}% +
+
+
+ + ⌂Course Overview + +
+ ${navGroup('Modules', modules, 1)} + `; +} + +/* ── Collapsible Sections ─────────────────────── */ +function initCollapsibles() { + document.querySelectorAll('.collapsible-header').forEach(header => { + header.addEventListener('click', () => { + header.classList.toggle('open'); + const body = header.nextElementSibling; + body.classList.toggle('open'); + }); + }); +} + +/* ── Quiz Engine ──────────────────────────────── */ +function initQuiz(quizId, passMark, onPass) { + const form = document.getElementById(quizId); + if (!form) return; + + const submitBtn = form.querySelector('.quiz-submit'); + const resultEl = form.querySelector('.quiz-result'); + + form.querySelectorAll('.options li').forEach(opt => { + opt.addEventListener('click', () => { + const questionBlock = opt.closest('.question-block'); + if (questionBlock.dataset.answered) return; + questionBlock.querySelectorAll('.options li').forEach(o => o.classList.remove('selected')); + opt.classList.add('selected'); + }); + }); + + if (submitBtn) { + submitBtn.addEventListener('click', () => { + let correct = 0; + let total = 0; + let unanswered = false; + + form.querySelectorAll('.question-block').forEach(qb => { + total++; + const selected = qb.querySelector('.options li.selected'); + if (!selected) { unanswered = true; return; } + qb.dataset.answered = '1'; + const isCorrect = selected.dataset.correct === 'true'; + if (isCorrect) { + correct++; + selected.classList.replace('selected', 'correct'); + } else { + selected.classList.replace('selected', 'wrong'); + qb.querySelectorAll('.options li').forEach(o => { + if (o.dataset.correct === 'true') o.classList.add('reveal-correct'); + }); + } + const fb = qb.querySelector('.feedback'); + if (fb) { + fb.style.display = 'block'; + fb.classList.add(isCorrect ? 'correct-fb' : 'wrong-fb'); + } + }); + + if (unanswered) { alert('Please answer all questions before submitting.'); return; } + + submitBtn.disabled = true; + const pct = Math.round((correct / total) * 100); + resultEl.style.display = 'block'; + if (pct >= passMark) { + resultEl.className = 'quiz-result pass'; + resultEl.innerHTML = `✓ Passed! You scored ${correct}/${total} (${pct}%). ${onPass ? 'Module marked as complete.' : ''}`; + if (onPass) { markComplete(onPass); } + } else { + resultEl.className = 'quiz-result fail'; + resultEl.innerHTML = `✗ Score: ${correct}/${total} (${pct}%). Pass mark is ${passMark}%. Review the sections above and try again.`; + } + }); + } +} + +/* ── Auto-mark module visited ─────────────────── */ +function autoMarkVisited(id) { + if (id && id !== 'index' && !id.startsWith('quiz')) { + markComplete(id); + } +} + +document.addEventListener('DOMContentLoaded', () => { + const pageId = document.body.dataset.page; + autoMarkVisited(pageId); + buildSidebar(pageId); + initCollapsibles(); +}); diff --git a/process/trainings/_portals/requirements_engineering/index.html b/process/trainings/_portals/requirements_engineering/index.html new file mode 100644 index 0000000000..32d045859e --- /dev/null +++ b/process/trainings/_portals/requirements_engineering/index.html @@ -0,0 +1,167 @@ + + + + + + +S-CORE Requirements Engineering Training | S-CORE Process Training + + + + + +
+ + +
+ Course Overview + +
+ +
+ + + + +

S-CORE Requirements Engineering

+

A focused, self-paced training on the Requirements Engineering process area +of the Eclipse S-CORE Process Description, covering its concepts, roles, +workflows, work products, and practical application in safety- and +security-critical automotive open-source software development.

+ + + + + + + + + + + + + + + + + + + + + + + + + +
Duration~3.5 hours
Structure4 Modules + Checkpoint Quiz
FormatSelf-paced
StandardsISO 26262 · ASPICE SWE.1 · ISO/SAE 21434 · ISO PAS 8926
+

Modules

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ModuleTitleDescriptionDuration
Module 1Why Requirements Engineering?Role of RE in safety-critical OSS, stakeholders, roles, and how standards drive the process.~30 min
Module 2Requirement Levels and TypesThe five requirement levels (Stakeholder, Feature, Component, AoU, Process), types, and their traceability relationships.~45 min
Module 3Requirement Attributes and QualityMandatory and auto-generated attributes, formulation rules, versioning, and reviews.~45 min
Module 4Workflows and Work ProductsThe six S-CORE workflows, work products with compliance tags, and end-to-end traceability.~45 min
+

Checkpoint Quiz — All Modules +10 questions covering all four modules. Pass mark: 70%. Instant scoring with explanations. (~20 min)

+

About This Course

+

This training is based on the Eclipse S-CORE Process Description — +specifically the Requirements Engineering process area — and the applicable +standards it implements: ISO 26262 (Part 8), ASPICE PAM 4.0 (SWE.1), +ISO/SAE 21434, and ISO PAS 8926.

+

It is intended for anyone contributing to or reviewing requirements in an +S-CORE-compliant project: developers, architects, safety managers, security +managers, quality managers, and testers.

+
+
How to use this portal
+

Work through the modules in order. Each module ends with a short three-question +check-in. After completing all four modules take the Checkpoint Quiz. +Your progress is saved in your browser — no server required.

+
+ +

Learning Objectives

+

After completing this training you will be able to:

+ + + + + +
+ + + + Module 1: Why Requirements Engineering? → + + +
+ +
+
+ + + + + + \ No newline at end of file diff --git a/process/trainings/_portals/requirements_engineering/module-1.html b/process/trainings/_portals/requirements_engineering/module-1.html new file mode 100644 index 0000000000..b96eff4c10 --- /dev/null +++ b/process/trainings/_portals/requirements_engineering/module-1.html @@ -0,0 +1,281 @@ + + + + + + +Why Requirements Engineering? | S-CORE Process Training + + + + + +
+ + +
+ Course Overview + + › + Module 1: Why Requirements Engineering? + +
+ +
+ + + + +

Why Requirements Engineering?

+
+ ⏱ ~30 min + 📖 Module 1 of 4 + 🗂 Requirements +
+ +

Why Requirements Engineering?

+

Requirements engineering is not bureaucracy — it is the foundation that connects +a customer's need to the last line of tested code. In safety- and security-critical +automotive software this chain must be complete, correct, and auditable. +This module explains why, who is involved, and what standards demand.

+

1.1 The Role of Requirements in Safety-Critical Software

+

Modern automotive software controls safety-critical actuators — brakes, steering, +power management — and runs in open-source collaborative environments where dozens of +contributors work across organisational boundaries. Without a structured requirements +process two problems become inevitable:

+
    +
  1. No agreed specification — contributors implement different interpretations + of the same need.
    2. +
  2. No audit trail — safety and security auditors cannot verify that every + standard requirement is addressed.
    3. +
+
+
Why RE is Mandated by Standards
+

ISO 26262 (Part 8, SWE.1), ASPICE PAM 4.0, ISO/SAE 21434, and ISO PAS 8926 all +iltiyexplicitly require a documented, traceable requirements hierarchy as a precondition +for safety and security releases. Without it, certification is impossible.

+
+ +

The S-CORE Requirements Engineering process provides a single, standardised answer +to both problems: a hierarchy of requirement levels with defined attributes, +mandatory reviews, and automatic traceability links to code and tests.

+

1.2 Stakeholders and Their Information Needs

+

The requirements hierarchy must satisfy the needs of every stakeholder who will +either write, review, implement, test, or audit requirements. The S-CORE process +identifies the following key stakeholders:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
StakeholderSource IDRole in S-COREWhat they need from requirements
Project Leadrl__project_leadDefines platform specification and content, creates project timeline, tracks project progressClear stakeholder requirements as a project description
SW Architectrl__committerBreaks down platform specification into features, derives feature/component architecture, allocates requirements to architecture elements, defines AoUs from architectureFeature requirements and AoUs to drive architecture decisions
Testerrl__committerVerifies that the specification is satisfied by the elements under test, considers AoUs for test case specificationVerifiable, testable requirements with traceability to test cases
Safety Architectrl__safety_engineerPerforms Dependent Failure Analysis, qualitative safety analysis (e.g. FMEA), initiates additional requirements and AoUs to cover failuresRequirements with safety attributes and independence information
Security Architectrl__security_engineerPerforms Trust Boundary Analysis, Defense in Depth Analysis, qualitative security analysis (TARA)Requirements with security attributes
Module/Tooling SW Developerrl__delivery_teamImplements SW according to specification, creates traceability by linking specification to code, considers AoUs of other components, creates AoUs for the component under developmentComponent requirements with clear acceptance criteria
Feature User(no formal role ID)Gets detailed information on the specification of a feature, is informed about boundary conditions (AoUs)AoUs — boundary conditions they must fulfil when using the SW
Platform SW Developer of the Reference Integrationrl__platform_teamImplements requirements for reference integrationComponent and feature requirements
+
+
Open Source Working Mode
+

In S-CORE any Contributor may write a requirement, but every requirement must be +approved by a Committer or Project Lead before it is merged. Safety and Security +Managers provide support when their domain is involved.

+
+ +

1.3 Standard Connections

+

The S-CORE requirements process implements requirements from multiple standards +simultaneously. Understanding these connections helps prioritise engineering effort.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
StandardRelevant ClauseWhat it requires
ISO 26262Part 8, SWE.1SW requirements specification with safety classification, traceability, and review
ASPICE PAM 4.0SWE.1Elicitation, documentation, agreement, and traceability of SW requirements
ISO/SAE 21434§10.5.1Cybersecurity requirements derived from TARA, traceable through development
ISO PAS 8926§4.5.2.1To Be Defined
+
+
Assumptions of Use (AoU)
+

A special requirement type that defines the boundary conditions the user of a +software element must fulfil to ensure safe and secure operation. AoUs are +exportable to integrators so they can include them in their own requirements +management systems.

+
+ +

1.4 Roles and Approval Chains

+

The S-CORE process defines clear responsibility for each level of the hierarchy:

+ +

This separation ensures that the level of scrutiny matches the safety and security +implications of the requirement.

+
+
Why does the approval chain differ between Feature and Component level? ▼
+

Feature requirements describe platform-level integration behaviour and are visible +to all users of the platform — they require Project Lead approval because they +represent agreements between the platform team and its stakeholders.

+

Component requirements are implementation-specific and concern only the component +team — Committer approval is sufficient, as Committers are the technical +gatekeepers for their component.

+
+
+

Module Check-In

+

Answer all questions and click Submit to check your understanding.

+
+

Q1. Who is responsible for approving Feature Requirements in S-CORE?

+
    +
  • A Contributor
    • +
  • B Project Lead
    • +
  • C Safety Manager
    • +
  • D Feature User
    • +
+ +
+
+

Q2. Which standard requires SW requirements with a safety classification attribute, traceability, and formal review?

+
    +
  • A ISO/SAE 21434
    • +
  • B ISO PAS 8926
    • +
  • C ISO 26262 Part 8 / ASPICE SWE.1
    • +
  • D IEC 61508
    • +
+ +
+
+

Q3. An integrator using an S-CORE platform component needs to know the boundary conditions they must satisfy for safe use. Which requirement type addresses this?

+
    +
  • A Stakeholder Requirements
    • +
  • B Feature Requirements
    • +
  • C Process Requirements
    • +
  • D Assumptions of Use (AoU)
    • +
+ +
+ +
+
+ + + + + +
+ + ← Course Overview + + + + Module 2: Requirement Levels and Types → + + +
+ +
+
+ + + + + + \ No newline at end of file diff --git a/process/trainings/_portals/requirements_engineering/module-2.html b/process/trainings/_portals/requirements_engineering/module-2.html new file mode 100644 index 0000000000..d14e74a8de --- /dev/null +++ b/process/trainings/_portals/requirements_engineering/module-2.html @@ -0,0 +1,322 @@ + + + + + + +Requirement Levels and Types | S-CORE Process Training + + + + + +
+ + +
+ Course Overview + + › + Module 2: Requirement Levels and Types + +
+ +
+ + + + +

Requirement Levels and Types

+
+ ⏱ ~45 min + 📖 Module 2 of 4 + 🗂 Requirements +
+ +

Requirement Levels and Types

+

S-CORE defines a five-level requirement hierarchy. Each level has a precise +meaning, a defined audience, a characteristic abstraction, and specific +compliance obligations under ISO 26262, ASPICE, and ISO/SAE 21434. +This module maps the hierarchy and explains when to use each level.

+

2.1 The S-CORE Requirement Hierarchy

+

The following diagram summarises the levels and their derivation relationships:

+
Stakeholder Requirements (SW-Platform level)
+    │
+    ▼
+Feature Requirements  ←→  Feature AoU
+    │
+    ▼
+Component Requirements  ←→  Component AoU
+    │
+    ├── Code (Implemented by)
+    └── Tests (Verified by)
+
+

Additionally, Process/Tool Requirements sit alongside the hierarchy and +describe the tooling and process activities that support it.

+

A child requirement is always derived from its parent. The derivation link +includes the parent's version number so that stale links are automatically +detected during the docs build.

+

2.2 Stakeholder Requirements (wp__requirements_stkh)

+

Stakeholder Requirements are defined at the SW-Platform level. They describe +what the platform needs to contain from the perspective of the customer +(stakeholder), expressed as technical requirements at the highest level of +abstraction.

+
+
Assumed Technical Safety Requirements
+

In SEooC (Safety Element out of Context) development — which is the S-CORE model +— Stakeholder Requirements represent the assumed Technical Safety Requirements. +The integrator must verify that these assumptions match their vehicle-level +safety goals before using the platform.

+
+ +
+
Stakeholder Requirement Example
+
The platform shall support configuration of applications via files
+(e.g. yaml, json).
+
+

This describes a platform-level capability without specifying how it is +implemented or which component provides it.

+
+ +

Compliance obligations: ISO 26262 §8 / SWE.1, ISO/SAE 21434 §10.5.1

+

2.3 Feature Requirements (wp__requirements_feat)

+

Feature Requirements are derived from Stakeholder Requirements and describe +the behaviour of a feature at platform integration level, independent of +which components implement it.

+

A "feature" represents a coherent set of requirements that together deliver a +platform-level capability. Feature requirements are the primary input for +architects, testers, and integrators.

+
+
Feature Requirement Example
+
The feature shall use JSON formatted string according to RFC-8259 for
+configuration.
+
+

This specifies the format at feature level without naming an implementation component.

+
+ +

Feature requirements also serve as the basis for integration testing on +platform level.

+

Compliance obligations: ISO 26262 §8 / SWE.1, ISO/SAE 21434 §10.5.1

+

2.4 Component Requirements (wp__requirements_comp)

+

Component Requirements are derived from Feature Requirements and describe +component-specific behaviour. They are implementation-facing: they tell a +developer exactly what a component must do within the context of its feature.

+
+
Component Requirement Example
+
The component shall provide API calls to read and interpret every field of a
+JSON body in C++.
+
+

This is unambiguously allocated to a single component and is directly testable +at unit level.

+
+ +

Component Requirements are the lowest level in the hierarchy and have the most +direct link to code and test artefacts via the auto-generated implemented_by +and verified_by attributes.

+

Compliance obligations: ISO 26262 §8 / SWE.1, ISO PAS 8926 §4.5.2.1, +ISO 26262 (analysis appendix), ISO/SAE 21434 §10.5.1 + §10.5.2

+

2.5 Assumptions of Use (AoU)

+

AoUs can exist at every level — SW-Platform, Feature, and Component. They +define the boundary conditions that the user of the software element must +fulfil to ensure correct, safe, and secure operation.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
AoU LevelWork Product IDAudienceCompliance
SW-Platform AoUwp__requirements_sw_platform_aouVehicle integrators using the platformISO 26262, ISO/SAE 21434 §10.5.1–2
Feature AoUwp__requirements_feat_aouTeams integrating the feature into a productISO 26262, ISO/SAE 21434 §10.5.1–2
Component AoUwp__requirements_comp_aouDevelopers using the component APIISO 26262, ISO PAS 8926, ISO/SAE 21434 §10.5.1–2
+
+
AoU Example
+
The user shall provide a string as input which is not corrupted due to HW or
+QM SW errors.
+
+

This AoU tells the caller of the JSON configuration component what quality of +input they must guarantee.

+
+ +
+
AoU and the Safety Manual
+

Feature and Component AoUs feed directly into the Platform Safety Manual and +Module Safety Manual respectively. These manuals are the exportable artefacts +that document all conditions an integrator must satisfy when deploying S-CORE +components in a safety-relevant context.

+
+ +

2.6 Process and Tool Requirements (wp__requirements_proc_tool)

+

Process/Tool Requirements describe the activities and tooling constraints +that support the development process. They are derived from the process +description and specify what must be done manually versus what must be +automated (tool-supported).

+
+
Process/Tool Requirement Example
+
It shall be checked that safety requirements (Safety != QM) can only be linked
+against safety requirements.
+
+

This is a process requirement that drives tool implementation in the +Docs-as-Code build.

+
+ +

Process Requirements are verified by reviewing the process description rather +than by functional testing.

+

2.7 Requirement Types

+

Every requirement — regardless of level — carries a type attribute that +determines how it is verified and how it participates in traceability:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TypeDefinitionVerification method
FunctionalDescribes a behaviour that can be demonstrated by testUnit test, integration test
InterfaceDefines an API or protocol; does not itself describe a behaviourReview / analysis
ProcessDescribes a process activity or constraint; sub-type of Non-FunctionalReview of process description
Non-FunctionalAll other quality constraints (performance, capacity, …)Review / analysis
+
+
Type Affects Linkage Rules
+

The type attribute controls which architecture and safety linkage rules apply. +For example, safety requirements of type Functional must eventually be linked to +a test that exercises the functional behaviour. A Process requirement linked to a +Functional safety requirement would be flagged as a linkage violation.

+
+ +
+
Interface requirements — when are they needed? ▼
+

Use the Interface type when a requirement defines a contract between two +parties (e.g., an API signature, a protocol format, a data format) rather than a +behaviour. Interface requirements are important for safety analysis because they +define the boundaries across which faults can propagate — they often appear as +inputs to DFA (Dependent Failure Analysis) and TARA.

+
+
+

Module Check-In

+

Answer all questions and click Submit to check your understanding.

+
+

Q1. A requirement states: 'The feature shall use JSON formatted strings according to RFC-8259 for configuration.' At which requirement level does this belong?

+
    +
  • A Stakeholder Requirements
    • +
  • B Feature Requirements
    • +
  • C Component Requirements
    • +
  • D Process Requirements
    • +
+ +
+
+

Q2. An integrator is building a vehicle product using an S-CORE platform component. They receive a document listing the conditions their application must satisfy to use the component safely. What type of requirement is this?

+
    +
  • A Stakeholder Requirements
    • +
  • B Process Requirements
    • +
  • C Assumptions of Use (AoU)
    • +
  • D Functional Requirements
    • +
+ +
+
+

Q3. Which requirement type is verified by reviewing the process description rather than by functional test execution?

+
    +
  • A Functional
    • +
  • B Interface
    • +
  • C Process
    • +
  • D Non-Functional
    • +
+ +
+ +
+
+ + + + + +
+ + ← Module 1: Why Requirements Engineering? + + + + Module 3: Requirement Attributes and Quality → + + +
+ +
+
+ + + + + + \ No newline at end of file diff --git a/process/trainings/_portals/requirements_engineering/module-3.html b/process/trainings/_portals/requirements_engineering/module-3.html new file mode 100644 index 0000000000..332451f34c --- /dev/null +++ b/process/trainings/_portals/requirements_engineering/module-3.html @@ -0,0 +1,377 @@ + + + + + + +Requirement Attributes and Quality | S-CORE Process Training + + + + + +
+ + +
+ Course Overview + + › + Module 3: Requirement Attributes and Quality + +
+ +
+ + + + +

Requirement Attributes and Quality

+
+ ⏱ ~45 min + 📖 Module 3 of 4 + 🗂 Requirements +
+ +

Requirement Attributes and Quality

+

A requirement without well-defined attributes is not a requirement — it is a +wish. S-CORE mandates a specific attribute set for every requirement and +automates part of its population. This module covers all attributes, versioning +rules, and the formulation principles that make requirements verifiable.

+

3.1 Manual Attributes

+

Every S-CORE requirement must have the following attributes set by the author +before a pull request can be merged:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
AttributeValues / FormatPurpose
Unique ID<type_prefix>__<keyword>_<shortname>Stable identifier used for all traceability links
Statusvalid | invalidOnly valid requirements are accepted in main branch
TitleFree text, expressiveHuman-readable label
DescriptionFree textThe actual requirement statement
VersionInteger (1, 2, 3, …)Bumped on every significant change
Rationale / LinkageFree text | derived_from linkStakeholder reqs need a rationale; derived reqs link to parent
SafetyQM | ASIL_BSafety integrity level of this requirement
SecurityBoolean / free textWhether the requirement has security relevance
TypeFunctional | Interface | Process | Non-FunctionalDetermines verification method and linkage rules
+
+
No "Draft" Status in Main Branch
+

S-CORE intentionally has no draft status value. A requirement is either +valid (merged) or it lives in a pull request / feature branch. This forces +engineers to complete a requirement before integrating it rather than +accumulating technical debt in the form of unfinished requirements.

+
+ +

3.2 The Safety Attribute in Detail

+

The safety attribute is the cornerstone of ISO 26262 compliance. S-CORE +currently supports two values:

+ + + + + + + + + + + + + + + + + +
ValueMeaning
QMQuality Management — no ASIL claim; standard software quality processes apply
ASIL_BAutomotive Safety Integrity Level B — requires ASIL-B process measures, verification rigour, and traceability
+
+
ASIL Decomposition Is Not Used
+

S-CORE does not currently apply ASIL decomposition, so ASIL_A, ASIL_C, and +ASIL_D are not required. Only QM and ASIL_B are defined. All safety-relevant +requirements must be classified ASIL_B — a safety-relevant requirement that is +incorrectly marked QM is a safety defect.

+
+ +

The tooling enforces linkage rules: an ASIL_B requirement may only be linked to +other ASIL_B requirements or to QM requirements with a documented rationale.

+

3.3 Auto-Generated Attributes

+

The Docs-as-Code build populates three attributes automatically, eliminating +manual maintenance overhead and ensuring the attributes are always current:

+ + + + + + + + + + + + + + + + + + + + + + + + + +
AttributeHow it is populatedTool
DerivesAutomatically inserted into the parent requirement when a child requirement references it via derived_fromDocs-as-Code
Implemented bySource files are scanned for a defined tag containing the requirement ID; matching code locations are linkedDocs-as-Code
Verified byTest files are scanned for a defined marker containing the requirement ID; matching test cases are linkedDocs-as-Code
+
+
How Implemented by Works
+

A developer adds the following tag in C++ source code:

+
// [feat__json_config__parse_body]
+void ConfigParser::parseBody(const std::string& json) { ... }
+
+

During the docs build, the tool finds this tag, resolves feat__json_config__parse_body +to the corresponding feature requirement, and automatically links the source +file and line to the implemented_by attribute.

+
+ +

This automatic population means that the traceability matrix is always +regenerated from the actual code and test artefacts — it cannot be manually +falsified or forgotten.

+

3.4 Requirement Versioning

+

Significant vs. Non-Significant Changes

+

Not every edit to a requirement warrants a version increment. S-CORE defines +precisely which changes are significant:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
AttributeSignificant changeNon-significant change
DescriptionFunctional content change or rewrite affecting meaningTypo corrections, layout, notes
SafetyAny change—
SecurityAny change—
TypeAny change—
+
+
Version Mismatch Is a Build Error
+

Child requirements reference their parent requirement with an explicit version number +(e.g., derived_from: stkh__platform__config_files[version==2]). If the parent +requirement's version is later bumped, all child derivation links become stale and +the docs build emits a warning that blocks merging until the child requirements +are updated. This ensures that a change in a parent requirement always triggers a +review of all its children.

+
+ +

Versioning Sets of Requirements

+

Individual requirement versioning covers single-requirement changes. For +baselines — frozen sets of requirements used as the basis for a release or +for a safety case — S-CORE uses standard version control tagging: a git tag +applied to the repository records the exact state of all requirement files.

+

3.5 Requirement Quality and Formulation

+

A well-written requirement has four properties:

+ + + + + + + + + + + + + + + + + + + + + + + + + +
PropertyTest question
AtomicDoes the requirement describe exactly one thing?
VerifiableCan we write a test or review criterion that definitively confirms conformance?
UnambiguousIs there exactly one valid interpretation?
TraceableDoes the requirement link upward to a parent (or have a rationale) and downward to implementation and test?
+
+
Notes Are Not Requirements
+

A note in a requirement (marked as such in the Docs-as-Code tool) is not part of +the requirement itself. Notes provide additional explanation or context but +must not contain normative content. Reviewers must check that normative +statements are in the description, not buried in notes.

+
+ +

3.6 Requirement Reviews

+

Requirements that cannot be checked automatically require a manual inspection. +The S-CORE process supports two kinds of review:

+
    +
  1. Peer review (PR review) — every requirement passes through a pull request + where Committers (rl__committer) and Project Leads (rl__project_lead) review it before it is merged to main.
    2. +
  2. Formal inspection — triggered explicitly when a contributor wants a + thorough review of a set of requirements. Uses a structured inspection + checklist (gd_chklst__req_inspection) that may be integrated into requirements/version management tooling.
    3. +
+
+
What does the inspection checklist cover? ▼
+

The inspection checklist verifies:

+
    +
  • Completeness: all mandatory attributes are populated
    • +
  • Consistency: no contradictions between requirements at the same level
    • +
  • Feasibility: the requirement can realistically be implemented and tested
    • +
  • Traceability: every requirement is derived from a parent or has a documented rationale
    • +
  • Safety/security classification: safety attribute is correct relative to safety analysis
    • +
  • Formulation quality: atomic, verifiable, unambiguous
    • +
+
+
+

Module Check-In

+

Answer all questions and click Submit to check your understanding.

+
+

Q1. A developer edits a requirement's description to fix a typo and improve layout, with no change to its functional meaning. Should the version attribute be incremented?

+
    +
  • A Yes — any edit to a requirement must increment the version
    • +
  • B No — only significant changes (functional content, safety, security, type) trigger a version increment
    • +
  • C Yes — the version must be incremented so child links are re-validated
    • +
  • D No — versions are only managed by git tags, not per-requirement
    • +
+ +
+
+

Q2. Which attribute is automatically populated by the Docs-as-Code build when test files contain a defined marker with the requirement ID?

+
    +
  • A Derives
    • +
  • B Implemented by
    • +
  • C Verified by
    • +
  • D Status
    • +
+ +
+
+

Q3. A requirement is marked safety=QM but a safety analysis has determined it is ASIL_B relevant. What is the consequence?

+
    +
  • A Nothing — QM and ASIL_B requirements can be freely mixed
    • +
  • B The build will flag a linkage violation and the requirement is a safety defect
    • +
  • C The requirement is automatically upgraded to ASIL_B at build time
    • +
  • D A note is added to the requirement by the tool
    • +
+ +
+ +
+
+ + + + + +
+ + ← Module 2: Requirement Levels and Types + + + + Module 4: Workflows and Work Products → + + +
+ +
+
+ + + + + + \ No newline at end of file diff --git a/process/trainings/_portals/requirements_engineering/module-4.html b/process/trainings/_portals/requirements_engineering/module-4.html new file mode 100644 index 0000000000..6395333caa --- /dev/null +++ b/process/trainings/_portals/requirements_engineering/module-4.html @@ -0,0 +1,356 @@ + + + + + + +Workflows and Work Products | S-CORE Process Training + + + + + +
+ + +
+ Course Overview + + › + Module 4: Workflows and Work Products + +
+ +
+ + + + +

Workflows and Work Products

+
+ ⏱ ~45 min + 📖 Module 4 of 4 + 🗂 Requirements +
+ +

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

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Workflow IDWorkflow nameResponsibleApproved by
wf__req_stkh_reqCreate/Maintain Stakeholder Requirements and SW-Platform AoUContributor rl__contributorProject Lead rl__project_lead
wf__req_feat_reqCreate/Maintain Feature RequirementsContributor rl__contributorProject Lead rl__project_lead
wf__req_feat_aouCreate/Maintain Feature AoUsContributor rl__contributorProject Lead rl__project_lead
wf__req_comp_reqCreate/Maintain Component RequirementsContributor rl__contributorCommitter rl__committer
wf__req_comp_aouCreate/Maintain Component AoUsContributor rl__contributorCommitter rl__committer
wf__req_toolCreate/Maintain Tool/Process RequirementsContributor rl__contributorCommitter rl__committer
wf__monitor_verify_requirementsMonitor/Verify RequirementsCommitter rl__committerCommitter rl__committer
+

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

+
+
Triggering this workflow
+

A project lead opens a change request: "The platform shall support OTA software +updates for individual components." A contributor writes the stakeholder +requirement and the SW-Platform AoU (the conditions the OEM integrator must +satisfy to use OTA safely). The project lead reviews and approves the PR.

+
+ +

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:

+ +
+
AoU and Architecture Are Coupled
+

AoUs cannot be written without the architecture work product because AoUs +emerge from the safety concept: once the architecture defines the isolation +boundaries and safety mechanisms, the AoUs state what conditions must hold +outside those boundaries for the safety concept to be valid.

+
+ +

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.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Work ProductIDCompliance tags
Stakeholder Requirementswp__requirements_stkhISO 26262 §8/6.5.1, ISO/SAE 21434 §10.5.1
Feature Requirementswp__requirements_featISO 26262 §8/6.5.1, ISO/SAE 21434 §10.5.1
Component Requirementswp__requirements_compISO 26262 §8/6.5.1, ISO PAS 8926 §4.5.2.1, ISO 26262 analysis annex, ISO/SAE 21434 §10.5.1
SW-Platform AoUwp__requirements_sw_platform_aouISO 26262 §8/6.5.1, ISO/SAE 21434 §10.5.1–2
Feature AoUwp__requirements_feat_aouISO 26262 §8/6.5.1, ISO/SAE 21434 §10.5.1–2
Component AoUwp__requirements_comp_aouISO 26262 §8/6.5.1, ISO PAS 8926 §4.5.2.1, ISO/SAE 21434 §10.5.1–2
Process/Tool Requirementswp__requirements_proc_tool(internal process lifecycle)
Requirements Inspectionwp__requirements_inspectISO 26262 §8/6.5.3
+

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
+
+
+
Traceability Is Automatically Maintained
+

The implemented_by and verified_by links are populated automatically by the +Docs-as-Code build. This means the traceability matrix is always regenerated +from the real artefacts — it cannot drift from the code. Auditors can trust +that a requirement shown as "verified by test X" genuinely corresponds to a test +that references that requirement ID.

+
+ +

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. +
  2. Build-time validation — attribute completeness, version link consistency, linkage rule enforcement, and safety attribute propagation checks.
    3. +
  3. Coverage reports — automatically generated views showing which requirements lack implemented_by or verified_by links (coverage gaps).
    4. +
  4. PR-based review workflow — all requirement changes go through a pull request; the Committer or Project Lead review is recorded in git history.
    5. +
+
+
Getting Started
+

The Requirements Engineering concept (doc_concept__req_process) and Getting +Started guide (doc_getstrt__req_process) describe the exact steps for creating +a new requirement, deriving child requirements, and triggering a formal inspection. +The workflow diagram in the getting started guide maps every step to the +corresponding workflow ID listed in Section 4.1.

+
+ +
+
Linking requirements to code and tests — practical steps ▼
+
    +
  1. Find the requirement ID in the generated HTML portal or in the RST source.
    2. +
  2. Add the implementation tag in the source file as a structured comment: + // [<requirement_id>] (exact syntax depends on the Docs-as-Code version).
    3. +
  3. Add the verification marker in the test file using the framework-specific + marker (e.g., a pytest mark or a comment annotation).
    4. +
  4. Run the docs build (bazel run //:docs). The build will now populate + implemented_by and verified_by in the HTML output.
    5. +
  5. Verify coverage in the generated requirements traceability report.
    6. +
+
+
+

Module Check-In

+

Answer all questions and click Submit to check your understanding.

+
+

Q1. A contributor wants to create new Component Requirements. Which approval chain applies?

+
    +
  • A Written by Safety Manager, approved by Project Lead
    • +
  • B Written by Contributor, approved by Committer
    • +
  • C Written by Committer, approved by Project Lead
    • +
  • D Written by Contributor, approved by Safety Manager
    • +
+ +
+
+

Q2. Feature AoU requirements have an additional input compared to Feature Requirements. What is it?

+
    +
  • A wp__requirements_stkh (Stakeholder Requirements)
    • +
  • B wp__requirements_comp (Component Requirements)
    • +
  • C wp__feature_arch (Feature Architecture)
    • +
  • D wp__issue_track_system (Issue Tracker)
    • +
+ +
+
+

Q3. An auditor asks: 'How do you guarantee that the traceability matrix between requirements and test cases is up to date?' What is the correct S-CORE answer?

+
    +
  • A The traceability matrix is maintained manually by the Safety Manager and reviewed quarterly
    • +
  • B Traceability is managed in an external ALM tool which is synced monthly
    • +
  • C The Docs-as-Code build automatically regenerates the verified_by links from test file markers on every build, so the matrix cannot drift from the actual test artefacts
    • +
  • D Developers are required to update the traceability spreadsheet when they add tests
    • +
+ +
+ +
+
+ + + + + +
+ + ← Module 3: Requirement Attributes and Quality + + + + Checkpoint Quiz → + + +
+ +
+
+ + + + + + \ No newline at end of file diff --git a/process/trainings/_portals/requirements_engineering/quiz-1.html b/process/trainings/_portals/requirements_engineering/quiz-1.html new file mode 100644 index 0000000000..6411c7efa9 --- /dev/null +++ b/process/trainings/_portals/requirements_engineering/quiz-1.html @@ -0,0 +1,244 @@ + + + + + + +Requirements Engineering Checkpoint Quiz | S-CORE Process Training + + + + + + + +
+ + +
+ Course Overview + + › + Requirements Engineering Checkpoint Quiz + +
+ +
+ + + + +
+

Requirements Engineering Checkpoint Quiz

+

10 questions covering all four modules — Module 1 through Module 4. Read each question carefully. Some questions are scenario-based. Instant scoring with explanations on submission.

+
+ 📋 10 Questions⏱ ~20 min🎯 Pass mark: 70% (7/10)📖 Covers Modules 1–4 +
+
+ +
+
+

Q1. Why is structured requirements engineering mandated in S-CORE rather than left to individual project discretion?

+
    +
  • A It is required because requirements management tools are already available in the platform.
    • +
  • B ISO 26262, ASPICE SWE.1, ISO/SAE 21434, and ISO PAS 8926 all require a documented, traceable requirements hierarchy as a precondition for certification; without it a safety and security release is not possible.
    • +
  • C It is only needed for ASIL_D projects; QM-only projects can skip structured RE.
    • +
  • D Requirements engineering is optional — projects can substitute it with comprehensive test coverage.
    • +
+ +
+
+

Q2. In S-CORE, any Contributor may write a requirement. Which of the following statements about the approval process is correct?

+
    +
  • A Contributors may directly merge requirements without review if the safety attribute is QM.
    • +
  • B All requirements are approved exclusively by Safety Managers.
    • +
  • C Stakeholder and Feature requirements must be approved by the Project Lead; Component requirements must be approved by a Committer.
    • +
  • D Requirements are approved by the Feature User because they are the primary consumer.
    • +
+ +
+
+

Q3. A requirement states: 'The platform shall support JSON-based configuration.' At which level does this belong, and why?

+
    +
  • A Component Requirements — because it describes a concrete implementation detail.
    • +
  • B Stakeholder Requirements — because it describes a platform-level capability at high abstraction, without specifying how any component implements it.
    • +
  • C Feature Requirements — because JSON is a specific technical format.
    • +
  • D Process Requirements — because it describes a process constraint.
    • +
+ +
+
+

Q4. An S-CORE component is released for integration into a vehicle OEM project. The OEM needs to know the boundary conditions their application must satisfy for the component to behave correctly under safety constraints. Which S-CORE work product delivers this information?

+
    +
  • A wp__requirements_comp (Component Requirements)
    • +
  • B wp__requirements_feat (Feature Requirements)
    • +
  • C wp__requirements_comp_aou (Component Assumptions of Use)
    • +
  • D wp__requirements_proc_tool (Process/Tool Requirements)
    • +
+ +
+
+

Q5. Which values are currently defined for the 'safety' attribute in S-CORE requirements?

+
    +
  • A QM and ASIL_B only, because ASIL decomposition is not used in S-CORE.
    • +
  • B ASIL_A, ASIL_B, ASIL_C, and ASIL_D to cover the full ISO 26262 range.
    • +
  • C QM, ASIL_A, and ASIL_B for the subset of ISO 26262 levels used in automotive OSS.
    • +
  • D Safety classification is not an attribute in S-CORE requirements.
    • +
+ +
+
+

Q6. A developer edits a Component Requirement by changing its description to fix a typo and rewrites one sentence for clarity — the functional meaning is identical. Must the version attribute be incremented?

+
    +
  • A Yes — any edit to description requires a version bump.
    • +
  • B No — only functional content changes, or changes to the safety, security, or type attribute, are significant and require a version increment.
    • +
  • C Yes — otherwise child requirement links become invalid.
    • +
  • D No — version increments are only required for ASIL_B requirements.
    • +
+ +
+
+

Q7. Which of the three auto-generated attributes is populated by scanning source code files for a defined tag containing the requirement ID?

+
    +
  • A Derives
    • +
  • B Implemented by
    • +
  • C Verified by
    • +
  • D Status
    • +
+ +
+
+

Q8. A contributor wants to create Feature AoU requirements. Compared to a plain Feature Requirements workflow, which additional input is required?

+
    +
  • A wp__requirements_stkh (Stakeholder Requirements)
    • +
  • B wp__requirements_proc_tool (Process/Tool Requirements)
    • +
  • C wp__feature_arch (Feature Architecture)
    • +
  • D wp__requirements_inspect (Requirements Inspection)
    • +
+ +
+
+

Q9. A safety auditor asks how S-CORE ensures that a requirement shown as 'verified by Test_X' in the documentation genuinely corresponds to a test that references that requirement. What is the correct answer?

+
    +
  • A The Safety Manager manually cross-checks the traceability matrix against the test repository each sprint.
    • +
  • B The Docs-as-Code build scans all test files for requirement ID markers on every build and regenerates the 'verified_by' links automatically, so the documentation can never show a test link that does not exist in the codebase.
    • +
  • C An external ALM tool is synchronised monthly to keep the traceability matrix current.
    • +
  • D Developers are required to update the traceability spreadsheet whenever a new test is added.
    • +
+ +
+
+

Q10. A new feature is being specified. The correct end-to-end flow in S-CORE is:

+
    +
  • A Write Component Requirements first to anchor implementation, then derive Feature and Stakeholder Requirements bottom-up.
    • +
  • B Write Stakeholder Requirements first, then derive Feature Requirements, then derive Component Requirements top-down, linking each level to its parent with a versioned derived_from reference.
    • +
  • C Write Feature Requirements first, then both Stakeholder Requirements and Component Requirements independently.
    • +
  • D Only Stakeholder Requirements and Component Requirements are needed; Feature Requirements are optional in S-CORE.
    • +
+ +
+ +
+ +
+
🏆
+

Requirements Engineering Certified

+

You have successfully passed the S-CORE Requirements Engineering Training.

+
S-CORE Requirements Engineering Training — Eclipse Foundation
+

+ Eclipse S-CORE Training Program · +

+
+
+ + + + + +
+ + ← Module 4: Workflows and Work Products + + +
+ +
+
+ + + + + + \ No newline at end of file diff --git a/process/trainings/_portals/requirements_engineering/style.css b/process/trainings/_portals/requirements_engineering/style.css new file mode 100644 index 0000000000..c225f1a2fe --- /dev/null +++ b/process/trainings/_portals/requirements_engineering/style.css @@ -0,0 +1,458 @@ +/* + * Copyright (c) 2026 Contributors to the Eclipse Foundation + * + * See the NOTICE file(s) distributed with this work for additional + * information regarding copyright ownership. + * + * This program and the accompanying materials are made available under the + * terms of the Apache License Version 2.0 which is available at + * https://www.apache.org/licenses/LICENSE-2.0 + * + * SPDX-License-Identifier: Apache-2.0 + * + * AI Disclosure: This file was largely AI-generated. The AI-generated + * portions are made available under CC0-1.0 and not subject to the + * project's license. The human contributor has reviewed and verified + * that the code is correct. + * SPDX-License-Identifier: CC0-1.0 + * Assisted-by: Claude Sonnet 4.6 + */ + +/* S-CORE Requirements Engineering Training Portal — Shared Styles */ + +:root { + --navy: #2d1942; + --navy-light: #3d2460; + --blue: #7c4daa; + --blue-light: #a382c5; + --amber: #d97706; + --amber-light: #fef3c7; + --green: #2d8a4e; + --green-light: #d1fae5; + --red: #c0392b; + --red-light: #fde8e8; + --gray-100: #f5f7fa; + --gray-200: #e2e8f0; + --gray-400: #94a3b8; + --gray-600: #475569; + --gray-800: #1e293b; + --white: #ffffff; + --sidebar-w: 270px; + --header-h: 60px; + --font: 'Segoe UI', system-ui, -apple-system, sans-serif; + --font-mono: 'Consolas', 'Courier New', monospace; +} + +*, *::before, *::after { box-sizing: border-box; margin: 0; padding: 0; } + +html { font-size: 16px; scroll-behavior: smooth; } + +body { + font-family: var(--font); + color: var(--gray-800); + background: var(--gray-100); + min-height: 100vh; + display: flex; +} + +/* ── Sidebar ────────────────────────────────────── */ +#sidebar { + width: var(--sidebar-w); + min-height: 100vh; + background: var(--navy); + color: #c8d6e5; + display: flex; + flex-direction: column; + position: fixed; + top: 0; left: 0; bottom: 0; + z-index: 100; + overflow-y: auto; +} + +#sidebar .brand { + padding: 20px 20px 16px; + border-bottom: 1px solid var(--navy-light); +} +#sidebar .brand h1 { + font-size: 0.85rem; + font-weight: 700; + text-transform: uppercase; + letter-spacing: .08em; + color: var(--white); + line-height: 1.4; +} +#sidebar .brand p { + font-size: 0.72rem; + color: var(--gray-400); + margin-top: 4px; +} + +.progress-area { + padding: 14px 20px; + border-bottom: 1px solid var(--navy-light); +} +.progress-label { + display: flex; + justify-content: space-between; + font-size: 0.72rem; + color: var(--gray-400); + margin-bottom: 6px; +} +.progress-bar-outer { + background: var(--navy-light); + border-radius: 4px; + height: 6px; + overflow: hidden; +} +.progress-bar-inner { + background: var(--amber); + height: 100%; + border-radius: 4px; + transition: width .4s ease; +} + +.nav-section-label { + font-size: 0.65rem; + font-weight: 700; + text-transform: uppercase; + letter-spacing: .1em; + color: var(--gray-400); + padding: 16px 20px 6px; +} + +#sidebar nav a { + display: flex; + align-items: center; + gap: 10px; + padding: 10px 20px; + text-decoration: none; + color: #c8d6e5; + font-size: 0.84rem; + border-left: 3px solid transparent; + transition: background .15s, border-color .15s; +} +#sidebar nav a:hover { background: var(--navy-light); color: var(--white); } +#sidebar nav a.active { background: var(--navy-light); border-left-color: var(--amber); color: var(--white); } +#sidebar nav a.completed .nav-icon { color: var(--green); } + +.nav-icon { + width: 20px; + height: 20px; + border-radius: 50%; + display: flex; + align-items: center; + justify-content: center; + font-size: 0.7rem; + font-weight: 700; + flex-shrink: 0; + background: var(--navy-light); + color: var(--gray-400); +} +a.active .nav-icon { background: var(--amber); color: var(--white); } +a.completed .nav-icon { background: var(--green); color: var(--white); } + +.nav-sep { margin: 8px 20px; border: none; border-top: 1px solid var(--navy-light); } + +/* ── Main Layout ───────────────────────────────── */ +#main { + margin-left: var(--sidebar-w); + flex: 1; + min-height: 100vh; + display: flex; + flex-direction: column; +} + +/* ── Top Bar ───────────────────────────────────── */ +#topbar { + background: var(--white); + border-bottom: 1px solid var(--gray-200); + height: var(--header-h); + display: flex; + align-items: center; + padding: 0 40px; + gap: 8px; + font-size: 0.82rem; + color: var(--gray-600); + position: sticky; + top: 0; + z-index: 50; +} +#topbar a { color: var(--blue); text-decoration: none; } +#topbar a:hover { text-decoration: underline; } +#topbar .sep { color: var(--gray-400); } + +/* ── Content Area ──────────────────────────────── */ +#content { + flex: 1; + padding: 40px 48px 80px; + max-width: 900px; +} + +/* ── Typography ───────────────────────────────── */ +h1.module-title { + font-size: 2rem; + font-weight: 700; + color: var(--gray-800); + margin-bottom: 6px; + line-height: 1.25; +} +.module-meta { + font-size: 0.82rem; + color: var(--gray-400); + display: flex; + gap: 16px; + margin-bottom: 32px; + flex-wrap: wrap; +} +.module-meta span { display: flex; align-items: center; gap: 4px; } + +h2 { + font-size: 1.3rem; + font-weight: 700; + color: var(--blue); + margin: 36px 0 14px; + padding-bottom: 8px; + border-bottom: 2px solid var(--gray-200); +} +h3 { + font-size: 1.05rem; + font-weight: 600; + color: var(--gray-800); + margin: 24px 0 10px; +} +p { line-height: 1.7; margin-bottom: 14px; color: var(--gray-800); } +ul, ol { margin: 10px 0 16px 22px; } +li { line-height: 1.7; margin-bottom: 4px; } +strong { color: var(--gray-800); } + +/* ── Callout Boxes ─────────────────────────────── */ +.callout { + border-radius: 8px; + padding: 16px 20px; + margin: 20px 0; + border-left: 4px solid; +} +.callout.definition { + background: #f5f0ff; + border-color: var(--blue); +} +.callout.definition .callout-label { color: var(--blue); } +.callout.example { + background: var(--amber-light); + border-color: var(--amber); +} +.callout.example .callout-label { color: var(--amber); } +.callout.important { + background: #fef2f2; + border-color: var(--red); +} +.callout.important .callout-label { color: var(--red); } +.callout.tip { + background: var(--green-light); + border-color: var(--green); +} +.callout.tip .callout-label { color: var(--green); } +.callout-label { + font-size: 0.72rem; + font-weight: 700; + text-transform: uppercase; + letter-spacing: .08em; + margin-bottom: 6px; +} +.callout p:last-child { margin-bottom: 0; } + +/* ── Tables ─────────────────────────────────────── */ +.table-wrap { overflow-x: auto; margin: 20px 0; border-radius: 8px; border: 1px solid var(--gray-200); } +table { width: 100%; border-collapse: collapse; font-size: 0.88rem; } +thead { background: var(--blue); color: var(--white); } +thead th { padding: 10px 14px; text-align: left; font-weight: 600; } +tbody tr:nth-child(even) { background: var(--gray-100); } +tbody tr:hover { background: #e8f0fe; } +tbody td { padding: 9px 14px; border-bottom: 1px solid var(--gray-200); vertical-align: top; } +tbody tr:last-child td { border-bottom: none; } + +/* ── ASIL badge colors ────────────────────────── */ +.asil { display: inline-block; padding: 2px 8px; border-radius: 4px; font-weight: 700; font-size: 0.8rem; } +.asil-qm { background: #e5e7eb; color: #374151; } +.asil-a { background: #fef3c7; color: #92400e; } +.asil-b { background: #fed7aa; color: #9a3412; } +.asil-c { background: #fecaca; color: #991b1b; } +.asil-d { background: #dc2626; color: #fff; } + +/* ── Collapsible Sections ──────────────────────── */ +.collapsible { + border: 1px solid var(--gray-200); + border-radius: 8px; + margin: 16px 0; + overflow: hidden; +} +.collapsible-header { + display: flex; + justify-content: space-between; + align-items: center; + padding: 14px 20px; + background: var(--white); + cursor: pointer; + user-select: none; + font-weight: 600; + font-size: 0.95rem; + transition: background .15s; +} +.collapsible-header:hover { background: var(--gray-100); } +.collapsible-header .arrow { + font-size: 0.8rem; + color: var(--gray-400); + transition: transform .25s; +} +.collapsible-header.open .arrow { transform: rotate(180deg); } +.collapsible-body { display: none; padding: 16px 20px; background: var(--white); border-top: 1px solid var(--gray-200); } +.collapsible-body.open { display: block; } + +/* ── Inline Quiz (per module) ──────────────────── */ +.quiz-section { + background: var(--white); + border: 2px solid var(--blue); + border-radius: 12px; + padding: 28px 32px; + margin: 40px 0; +} +.quiz-section h2 { + color: var(--blue); + border: none; + padding: 0; + margin: 0 0 6px; + font-size: 1.15rem; +} +.quiz-section .quiz-intro { color: var(--gray-600); font-size: 0.88rem; margin-bottom: 24px; } +.question-block { margin-bottom: 28px; } +.question-text { font-weight: 600; margin-bottom: 12px; line-height: 1.55; } +.question-num { color: var(--blue); margin-right: 6px; } +.options { list-style: none; margin: 0; padding: 0; } +.options li { + display: flex; + align-items: flex-start; + gap: 10px; + padding: 10px 14px; + border: 1.5px solid var(--gray-200); + border-radius: 6px; + margin-bottom: 8px; + cursor: pointer; + transition: background .15s, border-color .15s; + font-size: 0.9rem; + line-height: 1.5; +} +.options li:hover { border-color: var(--blue-light); background: #f5f0ff; } +.options li.selected { border-color: var(--blue); background: #f5f0ff; } +.options li.correct { border-color: var(--green); background: var(--green-light); } +.options li.wrong { border-color: var(--red); background: var(--red-light); } +.options li.reveal-correct { border-color: var(--green); background: var(--green-light); } +.opt-letter { + width: 24px; height: 24px; + border-radius: 50%; + background: var(--gray-200); + color: var(--gray-600); + font-size: 0.75rem; + font-weight: 700; + display: flex; align-items: center; justify-content: center; + flex-shrink: 0; +} +li.correct .opt-letter { background: var(--green); color: #fff; } +li.wrong .opt-letter { background: var(--red); color: #fff; } +li.reveal-correct .opt-letter { background: var(--green); color: #fff; } +.feedback { + display: none; + margin-top: 10px; + padding: 10px 14px; + border-radius: 6px; + font-size: 0.85rem; + line-height: 1.5; +} +.feedback.correct-fb { background: var(--green-light); color: #065f46; } +.feedback.wrong-fb { background: var(--red-light); color: #7f1d1d; } +.quiz-submit { + display: inline-flex; + align-items: center; + gap: 8px; + background: var(--blue); + color: var(--white); + border: none; + padding: 11px 24px; + border-radius: 6px; + font-size: 0.9rem; + font-weight: 600; + cursor: pointer; + margin-top: 8px; + transition: background .15s; +} +.quiz-submit:hover { background: var(--blue-light); } +.quiz-submit:disabled { background: var(--gray-400); cursor: not-allowed; } +.quiz-result { + display: none; + margin-top: 20px; + padding: 16px 20px; + border-radius: 8px; + font-weight: 600; +} +.quiz-result.pass { background: var(--green-light); color: #065f46; border-left: 4px solid var(--green); } +.quiz-result.fail { background: var(--red-light); color: #7f1d1d; border-left: 4px solid var(--red); } + +/* ── Navigation Footer ─────────────────────────── */ +.page-nav { + display: flex; + justify-content: space-between; + align-items: center; + margin-top: 40px; + padding-top: 24px; + border-top: 1px solid var(--gray-200); + gap: 12px; +} +.btn-nav { + display: inline-flex; + align-items: center; + gap: 8px; + padding: 10px 20px; + border-radius: 6px; + font-size: 0.88rem; + font-weight: 600; + text-decoration: none; + transition: background .15s; +} +.btn-prev { background: var(--white); color: var(--blue); border: 1.5px solid var(--gray-200); } +.btn-prev:hover { background: var(--gray-100); } +.btn-next { background: var(--blue); color: var(--white); border: 1.5px solid transparent; } +.btn-next:hover { background: var(--blue-light); } + +/* ── Intro / Index Page ────────────────────────── */ +.course-hero { + background: linear-gradient(135deg, var(--navy) 0%, var(--blue) 100%); + border-radius: 12px; + padding: 40px 48px; + color: var(--white); + margin-bottom: 40px; +} +.course-hero h1 { font-size: 2.2rem; margin-bottom: 10px; } +.course-hero p { color: #c8d6e5; max-width: 600px; line-height: 1.7; } +.module-cards { display: grid; grid-template-columns: 1fr 1fr; gap: 16px; margin: 24px 0; } +.module-card { + background: var(--white); + border: 1.5px solid var(--gray-200); + border-radius: 10px; + padding: 20px 24px; + text-decoration: none; + color: var(--gray-800); + transition: border-color .15s, box-shadow .15s; + display: block; +} +.module-card:hover { border-color: var(--blue); box-shadow: 0 4px 12px rgba(26,77,143,.1); } +.module-card .card-num { font-size: 0.72rem; font-weight: 700; color: var(--blue); text-transform: uppercase; letter-spacing: .08em; margin-bottom: 6px; } +.module-card h3 { font-size: 1rem; margin: 0 0 6px; } +.module-card p { font-size: 0.82rem; color: var(--gray-600); margin: 0; } +.module-card .card-meta { font-size: 0.75rem; color: var(--gray-400); margin-top: 10px; } + +/* ── Print ─────────────────────────────────────── */ +@media print { + #sidebar, #topbar, .page-nav, .quiz-submit { display: none; } + #main { margin-left: 0; } + #content { padding: 20px; max-width: 100%; } + .collapsible-body { display: block !important; } +} diff --git a/process/trainings/index.rst b/process/trainings/index.rst new file mode 100644 index 0000000000..e5b476892f --- /dev/null +++ b/process/trainings/index.rst @@ -0,0 +1,89 @@ +.. ******************************************************************************* +.. Copyright (c) 2026 Contributors to the Eclipse Foundation +.. +.. See the NOTICE file(s) distributed with this work for additional +.. information regarding copyright ownership. +.. +.. This program and the accompanying materials are made available under the +.. terms of the Apache License Version 2.0 which is available at +.. https://www.apache.org/licenses/LICENSE-2.0 +.. +.. SPDX-License-Identifier: Apache-2.0 +.. ******************************************************************************* + +.. AI Disclosure: This file was largely AI-generated. The AI-generated +.. portions are made available under CC0-1.0 and not subject to the +.. project's license. The human contributor has reviewed and verified +.. that the code is correct. +.. SPDX-License-Identifier: CC0-1.0 +.. Assisted-by: Claude Sonnet 4.6 + +.. _trainings: + +Trainings +========= + +.. note:: + ATTENTION: THE CONTENT IS CREATED BY AI AND MAY CONTAIN ERRORS. PLEASE VERIFY THE INFORMATION BEFORE USE. + + Human verification has NOT YET been performed to ensure the accuracy of the content. + +Self-paced interactive training portals for the Eclipse S-CORE process areas. +Each portal is built from editable Markdown source files and rendered as a +standalone HTML site with progress tracking and embedded quizzes. + +.. note:: + The portals open as self-contained HTML applications. + Progress is saved locally in your browser — no server or login required. + +Available Trainings +------------------- + +.. grid:: 1 1 2 2 + :class-container: score-grid + + .. grid-item-card:: + :class-card: card-ml2 + + Requirements Engineering + ^^^^^^^^^^^^^^^^^^^^^^^^ + A focused 4-module training covering the S-CORE requirements engineering + process: concepts, requirement levels, attributes, and workflows. + + | **Duration:** ~3.5 hours + | **Modules:** 4 + Checkpoint Quiz + | **Standards:** ISO 26262 · ASPICE SWE.1 · ISO/SAE 21434 + + .. raw:: html + + + Open Training Portal → + + +Training Source and Build +------------------------- + +Each training is maintained under +``process/trainings//source/`` as editable Markdown files and +rebuilt automatically whenever the documentation is built via +``bazel run //:docs``. + +To rebuild a specific training manually: + +.. code-block:: bash + + cd process/trainings/trainings_requirements_engineering/source + python build.py + +Adding a new training +--------------------- + +1. Copy the template from ``process/trainings/trainings_templates/content/`` + into a new ``trainings_/source/content/`` directory. +2. Copy ``build.py``, ``template.html``, ``requirements.txt``, and ``assets/`` + from an existing training source folder. +3. Update the ``MODULES`` array in ``assets/app.js`` and the ``OUT`` path in + ``build.py``. +4. Add a grid card above pointing to the generated portal. diff --git a/process/trainings/trainings_requirements_engineering/portal/app.js b/process/trainings/trainings_requirements_engineering/portal/app.js new file mode 100644 index 0000000000..94ed953d07 --- /dev/null +++ b/process/trainings/trainings_requirements_engineering/portal/app.js @@ -0,0 +1,168 @@ +/* S-CORE Requirements Engineering Training Portal — Progress & Quiz Logic */ + +const MODULES = [ + { id: 'index', label: 'Course Overview', url: 'index.html' }, + { id: 'module-1', label: 'Why Requirements Engineering?', url: 'module-1.html' }, + { id: 'module-2', label: 'Requirement Levels and Types', url: 'module-2.html' }, + { id: 'module-3', label: 'Requirement Attributes and Quality', url: 'module-3.html' }, + { id: 'module-4', label: 'Workflows and Work Products', url: 'module-4.html' }, + { id: 'quiz-1', label: 'Checkpoint Quiz', url: 'quiz-1.html', isQuiz: true }, +]; + +function getProgress() { + const raw = localStorage.getItem('score-re-progress'); + return raw ? JSON.parse(raw) : {}; +} +function markComplete(id) { + const p = getProgress(); p[id] = true; localStorage.setItem('score-re-progress', JSON.stringify(p)); + updateProgressBar(); +} +function isComplete(id) { return !!getProgress()[id]; } + +function updateProgressBar() { + const p = getProgress(); + const total = MODULES.filter(m => m.id !== 'index').length; + const done = MODULES.filter(m => m.id !== 'index' && p[m.id]).length; + const pct = Math.round((done / total) * 100); + document.querySelectorAll('.progress-bar-inner').forEach(el => el.style.width = pct + '%'); + document.querySelectorAll('.progress-pct').forEach(el => el.textContent = pct + '%'); + document.querySelectorAll('.progress-count').forEach(el => el.textContent = done + ' / ' + total + ' complete'); + MODULES.forEach(m => { + const a = document.querySelector(`#sidebar nav a[data-id="${m.id}"]`); + if (!a) return; + const icon = a.querySelector('.nav-icon'); + if (p[m.id]) { a.classList.add('completed'); icon.textContent = '✓'; } + }); +} + +function buildSidebar(activeId) { + const p = getProgress(); + const sb = document.getElementById('sidebar'); + if (!sb) return; + + const total = MODULES.filter(m => m.id !== 'index').length; + const done = MODULES.filter(m => m.id !== 'index' && p[m.id]).length; + const pct = Math.round((done / total) * 100); + + const modules = MODULES.filter(m => m.id !== 'index'); + const navGroup = (label, items, startIdx) => ` +
${label}
+ + `; + + sb.innerHTML = ` +
+

S-CORE
Requirements
Engineering

+

Eclipse Foundation

+
+
+
+ ${done} / ${total} complete + ${pct}% +
+
+
+ + ⌂Course Overview + +
+ ${navGroup('Modules', modules, 1)} + `; +} + +/* ── Collapsible Sections ─────────────────────── */ +function initCollapsibles() { + document.querySelectorAll('.collapsible-header').forEach(header => { + header.addEventListener('click', () => { + header.classList.toggle('open'); + const body = header.nextElementSibling; + body.classList.toggle('open'); + }); + }); +} + +/* ── Quiz Engine ──────────────────────────────── */ +function initQuiz(quizId, passMark, onPass) { + const form = document.getElementById(quizId); + if (!form) return; + + const submitBtn = form.querySelector('.quiz-submit'); + const resultEl = form.querySelector('.quiz-result'); + + form.querySelectorAll('.options li').forEach(opt => { + opt.addEventListener('click', () => { + const questionBlock = opt.closest('.question-block'); + if (questionBlock.dataset.answered) return; + questionBlock.querySelectorAll('.options li').forEach(o => o.classList.remove('selected')); + opt.classList.add('selected'); + }); + }); + + if (submitBtn) { + submitBtn.addEventListener('click', () => { + let correct = 0; + let total = 0; + let unanswered = false; + + form.querySelectorAll('.question-block').forEach(qb => { + total++; + const selected = qb.querySelector('.options li.selected'); + if (!selected) { unanswered = true; return; } + qb.dataset.answered = '1'; + const isCorrect = selected.dataset.correct === 'true'; + if (isCorrect) { + correct++; + selected.classList.replace('selected', 'correct'); + } else { + selected.classList.replace('selected', 'wrong'); + qb.querySelectorAll('.options li').forEach(o => { + if (o.dataset.correct === 'true') o.classList.add('reveal-correct'); + }); + } + const fb = qb.querySelector('.feedback'); + if (fb) { + fb.style.display = 'block'; + fb.classList.add(isCorrect ? 'correct-fb' : 'wrong-fb'); + } + }); + + if (unanswered) { alert('Please answer all questions before submitting.'); return; } + + submitBtn.disabled = true; + const pct = Math.round((correct / total) * 100); + resultEl.style.display = 'block'; + if (pct >= passMark) { + resultEl.className = 'quiz-result pass'; + resultEl.innerHTML = `✓ Passed! You scored ${correct}/${total} (${pct}%). ${onPass ? 'Module marked as complete.' : ''}`; + if (onPass) { markComplete(onPass); } + } else { + resultEl.className = 'quiz-result fail'; + resultEl.innerHTML = `✗ Score: ${correct}/${total} (${pct}%). Pass mark is ${passMark}%. Review the sections above and try again.`; + } + }); + } +} + +/* ── Auto-mark module visited ─────────────────── */ +function autoMarkVisited(id) { + if (id && id !== 'index' && !id.startsWith('quiz')) { + markComplete(id); + } +} + +document.addEventListener('DOMContentLoaded', () => { + const pageId = document.body.dataset.page; + autoMarkVisited(pageId); + buildSidebar(pageId); + initCollapsibles(); +}); diff --git a/process/trainings/trainings_requirements_engineering/portal/index.html b/process/trainings/trainings_requirements_engineering/portal/index.html new file mode 100644 index 0000000000..fbddea22a7 --- /dev/null +++ b/process/trainings/trainings_requirements_engineering/portal/index.html @@ -0,0 +1,148 @@ + + + + + +S-CORE Requirements Engineering Training | S-CORE Process Training + + + + + +
+ + + + +
+ + + + +

S-CORE Requirements Engineering

+

A focused, self-paced training on the Requirements Engineering process area +of the Eclipse S-CORE Process Description, covering its concepts, roles, +workflows, work products, and practical application in safety- and +security-critical automotive open-source software development.

+ + + + + + + + + + + + + + + + + + + + + + + + + +
Duration~3.5 hours
Structure4 Modules + Checkpoint Quiz
FormatSelf-paced
StandardsISO 26262 · ASPICE SWE.1 · ISO/SAE 21434 · ISO PAS 8926
+

Modules

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ModuleTitleDescriptionDuration
Module 1Why Requirements Engineering?Role of RE in safety-critical OSS, stakeholders, roles, and how standards drive the process.~30 min
Module 2Requirement Levels and TypesThe five requirement levels (Stakeholder, Feature, Component, AoU, Process), types, and their traceability relationships.~45 min
Module 3Requirement Attributes and QualityMandatory and auto-generated attributes, formulation rules, versioning, and reviews.~45 min
Module 4Workflows and Work ProductsThe six S-CORE workflows, work products with compliance tags, and end-to-end traceability.~45 min
+

Checkpoint Quiz — All Modules +10 questions covering all four modules. Pass mark: 70%. Instant scoring with explanations. (~20 min)

+

About This Course

+

This training is based on the Eclipse S-CORE Process Description — +specifically the Requirements Engineering process area — and the applicable +standards it implements: ISO 26262 (Part 8), ASPICE PAM 4.0 (SWE.1), +ISO/SAE 21434, and ISO PAS 8926.

+

It is intended for anyone contributing to or reviewing requirements in an +S-CORE-compliant project: developers, architects, safety managers, security +managers, quality managers, and testers.

+
+
How to use this portal
+

Work through the modules in order. Each module ends with a short three-question +check-in. After completing all four modules take the Checkpoint Quiz. +Your progress is saved in your browser — no server required.

+
+ +

Learning Objectives

+

After completing this training you will be able to:

+
    +
  • Explain the role of structured requirements engineering in safety- and security-critical automotive software
    • +
  • Name all stakeholders and identify their information needs in an S-CORE project
    • +
  • Distinguish the five requirement levels and select the correct one for a given situation
    • +
  • Write well-formed requirements that satisfy the mandatory attribute set
    • +
  • Apply S-CORE versioning rules and identify when a version bump is required
    • +
  • Trace requirements from stakeholder level through code and tests using the S-CORE workflow
    • +
+ + + + +
+ + + + Module 1: Why Requirements Engineering? → + + +
+ +
+
+ + + + + + \ No newline at end of file diff --git a/process/trainings/trainings_requirements_engineering/portal/module-1.html b/process/trainings/trainings_requirements_engineering/portal/module-1.html new file mode 100644 index 0000000000..a2b92676d8 --- /dev/null +++ b/process/trainings/trainings_requirements_engineering/portal/module-1.html @@ -0,0 +1,253 @@ + + + + + +Why Requirements Engineering? | S-CORE Process Training + + + + + +
+ + +
+ Course Overview + + › + Module 1: Why Requirements Engineering? + +
+ +
+ + + + +

Why Requirements Engineering?

+
+ ⏱ ~30 min + 📖 Module 1 of 4 + 🗂 Requirements +
+ +

Why Requirements Engineering?

+

Requirements engineering is not bureaucracy — it is the foundation that connects +a customer's need to the last line of tested code. In safety- and security-critical +automotive software this chain must be complete, correct, and auditable. +This module explains why, who is involved, and what standards demand.

+

1.1 The Role of Requirements in Safety-Critical Software

+

Modern automotive software controls safety-critical actuators — brakes, steering, +power management — and runs in open-source collaborative environments where dozens of +contributors work across organisational boundaries. Without a structured requirements +process two problems become inevitable:

+
    +
  1. No agreed specification — contributors implement different interpretations + of the same need.
    2. +
  2. No audit trail — safety and security auditors cannot verify that every + standard requirement is addressed.
    3. +
+
+
Why RE is Mandated by Standards
+

ISO 26262 (Part 8, SWE.1), ASPICE PAM 4.0, ISO/SAE 21434, and ISO PAS 8926 all +explicitly require a documented, traceable requirements hierarchy as a precondition +for safety and security releases. Without it, certification is impossible.

+
+ +

The S-CORE Requirements Engineering process provides a single, standardised answer +to both problems: a hierarchy of requirement levels with defined attributes, +mandatory reviews, and automatic traceability links to code and tests.

+

1.2 Stakeholders and Their Information Needs

+

The requirements hierarchy must satisfy the needs of every stakeholder who will +either write, review, implement, test, or audit requirements. The S-CORE process +identifies the following key stakeholders:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
StakeholderRole in S-COREWhat they need from requirements
Project LeadDefines platform specification and timeline, tracks progressClear stakeholder requirements as a project description
SW ArchitectDerives features from stakeholder reqs, allocates to architectureFeature requirements and AoUs to drive architecture decisions
TesterVerifies specification is satisfiedVerifiable, testable requirements with traceability to test cases
Safety ManagerInitiates safety requirements, performs DFA and FMEA supportRequirements with safety attributes and independence information
Security ManagerInitiates security requirements, performs TARA supportRequirements with security attributes
SW DeveloperImplements requirements, creates traceability to codeComponent requirements with clear acceptance criteria
Feature UserIntegrates platform components into their vehicle projectAoUs — boundary conditions they must fulfil when using the SW
Platform Integration DeveloperImplements requirements for integrationComponent and feature requirements
+
+
Open Source Working Mode
+

In S-CORE any Contributor may write a requirement, but every requirement must be +approved by a Committer or Project Lead before it is merged. Safety and Security +Managers provide support when their domain is involved.

+
+ +

1.3 Standard Connections

+

The S-CORE requirements process implements requirements from multiple standards +simultaneously. Understanding these connections helps prioritise engineering effort.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
StandardRelevant ClauseWhat it requires
ISO 26262Part 8, SWE.1SW requirements specification with safety classification, traceability, and review
ASPICE PAM 4.0SWE.1Elicitation, documentation, agreement, and traceability of SW requirements
ISO/SAE 21434§10.5.1Cybersecurity requirements derived from TARA, traceable through development
ISO PAS 8926§4.5.2.1Safety and cybersecurity requirements for automated driving
+
+
Assumptions of Use (AoU)
+

A special requirement type that defines the boundary conditions the user of a +software element must fulfil to ensure safe and secure operation. AoUs are +exportable to integrators so they can include them in their own requirements +management systems.

+
+ +

1.4 Roles and Approval Chains

+

The S-CORE process defines clear responsibility for each level of the hierarchy:

+
    +
  • Stakeholder requirements and SW-Platform AoU: Written by Contributor, approved by Project Lead, supported by Safety Manager.
    • +
  • Feature requirements and Feature AoU: Written by Contributor, approved by Project Lead, supported by Safety Manager and Security Manager.
    • +
  • Component requirements and Component AoU: Written by Contributor, approved by Committer, supported by Safety Manager and Security Manager.
    • +
  • Tool/Process requirements: Written by Contributor, approved by Committer.
    • +
+

This separation ensures that the level of scrutiny matches the safety and security +implications of the requirement.

+
+
Why does the approval chain differ between Feature and Component level? ▼
+

Feature requirements describe platform-level integration behaviour and are visible +to all users of the platform — they require Project Lead approval because they +represent agreements between the platform team and its stakeholders.

+

Component requirements are implementation-specific and concern only the component +team — Committer approval is sufficient, as Committers are the technical +gatekeepers for their component.

+
+
+

Module Check-In

+

Answer all questions and click Submit to check your understanding.

+
+

Q1. Who is responsible for approving Feature Requirements in S-CORE?

+
    +
  • A Contributor
    • +
  • B Project Lead
    • +
  • C Safety Manager
    • +
  • D Feature User
    • +
+ +
+
+

Q2. Which standard requires SW requirements with a safety classification attribute, traceability, and formal review?

+
    +
  • A ISO/SAE 21434
    • +
  • B ISO PAS 8926
    • +
  • C ISO 26262 Part 8 / ASPICE SWE.1
    • +
  • D IEC 61508
    • +
+ +
+
+

Q3. An integrator using an S-CORE platform component needs to know the boundary conditions they must satisfy for safe use. Which requirement type addresses this?

+
    +
  • A Stakeholder Requirements
    • +
  • B Feature Requirements
    • +
  • C Process Requirements
    • +
  • D Assumptions of Use (AoU)
    • +
+ +
+ +
+
+ + + + + +
+ + ← Course Overview + + + + Module 2: Requirement Levels and Types → + + +
+ +
+
+ + + + + + \ No newline at end of file diff --git a/process/trainings/trainings_requirements_engineering/portal/module-2.html b/process/trainings/trainings_requirements_engineering/portal/module-2.html new file mode 100644 index 0000000000..d1e4708f54 --- /dev/null +++ b/process/trainings/trainings_requirements_engineering/portal/module-2.html @@ -0,0 +1,299 @@ + + + + + +Requirement Levels and Types | S-CORE Process Training + + + + + +
+ + +
+ Course Overview + + › + Module 2: Requirement Levels and Types + +
+ +
+ + + + +

Requirement Levels and Types

+
+ ⏱ ~45 min + 📖 Module 2 of 4 + 🗂 Requirements +
+ +

Requirement Levels and Types

+

S-CORE defines a five-level requirement hierarchy. Each level has a precise +meaning, a defined audience, a characteristic abstraction, and specific +compliance obligations under ISO 26262, ASPICE, and ISO/SAE 21434. +This module maps the hierarchy and explains when to use each level.

+

2.1 The S-CORE Requirement Hierarchy

+

The following diagram summarises the levels and their derivation relationships:

+
Stakeholder Requirements (SW-Platform level)
+    │
+    ▼
+Feature Requirements  ←→  Feature AoU
+    │
+    ▼
+Component Requirements  ←→  Component AoU
+    │
+    ├── Code (Implemented by)
+    └── Tests (Verified by)
+
+

Additionally, Process/Tool Requirements sit alongside the hierarchy and +describe the tooling and process activities that support it.

+

A child requirement is always derived from its parent. The derivation link +includes the parent's version number so that stale links are automatically +detected during the docs build.

+

2.2 Stakeholder Requirements

+

Stakeholder Requirements are defined at the SW-Platform level. They describe +what the platform needs to contain from the perspective of the customer +(stakeholder), expressed as technical requirements at the highest level of +abstraction.

+
+
Assumed Technical Safety Requirements
+

In SEooC (Safety Element out of Context) development — which is the S-CORE model +— Stakeholder Requirements represent the assumed Technical Safety Requirements. +The integrator must verify that these assumptions match their vehicle-level +safety goals before using the platform.

+
+ +
+
Stakeholder Requirement Example
+
The platform shall support configuration of applications via files
+(e.g. yaml, json).
+
+

This describes a platform-level capability without specifying how it is +implemented or which component provides it.

+
+ +

Compliance obligations: ISO 26262 §8 / SWE.1, ISO/SAE 21434 §10.5.1

+

2.3 Feature Requirements

+

Feature Requirements are derived from Stakeholder Requirements and describe +the behaviour of a feature at platform integration level, independent of +which components implement it.

+

A "feature" represents a coherent set of requirements that together deliver a +platform-level capability. Feature requirements are the primary input for +architects, testers, and integrators.

+
+
Feature Requirement Example
+
The feature shall use JSON formatted string according to RFC-8259 for
+configuration.
+
+

This specifies the format at feature level without naming an implementation component.

+
+ +

Feature requirements also serve as the basis for integration testing on +platform level.

+

Compliance obligations: ISO 26262 §8 / SWE.1, ISO/SAE 21434 §10.5.1

+

2.4 Component Requirements

+

Component Requirements are derived from Feature Requirements and describe +component-specific behaviour. They are implementation-facing: they tell a +developer exactly what a component must do within the context of its feature.

+
+
Component Requirement Example
+
The component shall provide API calls to read and interpret every field of a
+JSON body in C++.
+
+

This is unambiguously allocated to a single component and is directly testable +at unit level.

+
+ +

Component Requirements are the lowest level in the hierarchy and have the most +direct link to code and test artefacts via the auto-generated implemented_by +and verified_by attributes.

+

Compliance obligations: ISO 26262 §8 / SWE.1, ISO PAS 8926 §4.5.2.1, +ISO 26262 (analysis appendix), ISO/SAE 21434 §10.5.1 + §10.5.2

+

2.5 Assumptions of Use (AoU)

+

AoUs can exist at every level — SW-Platform, Feature, and Component. They +define the boundary conditions that the user of the software element must +fulfil to ensure correct, safe, and secure operation.

+ + + + + + + + + + + + + + + + + + + + + + + + + +
AoU LevelAudienceCompliance
SW-Platform AoUVehicle integrators using the platformISO 26262, ISO/SAE 21434 §10.5.1–2
Feature AoUTeams integrating the feature into a productISO 26262, ISO/SAE 21434 §10.5.1–2
Component AoUDevelopers using the component APIISO 26262, ISO PAS 8926, ISO/SAE 21434 §10.5.1–2
+
+
AoU Example
+
The user shall provide a string as input which is not corrupted due to HW or
+QM SW errors.
+
+

This AoU tells the caller of the JSON configuration component what quality of +input they must guarantee.

+
+ +
+
AoU and the Safety Manual
+

Feature and Component AoUs feed directly into the Platform Safety Manual and +Module Safety Manual respectively. These manuals are the exportable artefacts +that document all conditions an integrator must satisfy when deploying S-CORE +components in a safety-relevant context.

+
+ +

2.6 Process and Tool Requirements

+

Process/Tool Requirements describe the activities and tooling constraints +that support the development process. They are derived from the process +description and specify what must be done manually versus what must be +automated (tool-supported).

+
+
Process/Tool Requirement Example
+
It shall be checked that safety requirements (Safety != QM) can only be linked
+against safety requirements.
+
+

This is a process requirement that drives tool implementation in the +Docs-as-Code build.

+
+ +

Process Requirements are verified by reviewing the process description rather +than by functional testing.

+

2.7 Requirement Types

+

Every requirement — regardless of level — carries a type attribute that +determines how it is verified and how it participates in traceability:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TypeDefinitionVerification method
FunctionalDescribes a behaviour that can be demonstrated by testUnit test, integration test
InterfaceDefines an API or protocol; does not itself describe a behaviourReview / analysis
ProcessDescribes a process activity or constraint; sub-type of Non-FunctionalReview of process description
Non-FunctionalAll other quality constraints (performance, capacity, …)Review / analysis
+
+
Type Affects Linkage Rules
+

The type attribute controls which architecture and safety linkage rules apply. +For example, safety requirements of type Functional must eventually be linked to +a test that exercises the functional behaviour. A Process requirement linked to a +Functional safety requirement would be flagged as a linkage violation.

+
+ +
+
Interface requirements — when are they needed? ▼
+

Use the Interface type when a requirement defines a contract between two +parties (e.g., an API signature, a protocol format, a data format) rather than a +behaviour. Interface requirements are important for safety analysis because they +define the boundaries across which faults can propagate — they often appear as +inputs to DFA (Dependent Failure Analysis) and TARA.

+
+
+

Module Check-In

+

Answer all questions and click Submit to check your understanding.

+
+

Q1. A requirement states: 'The feature shall use JSON formatted strings according to RFC-8259 for configuration.' At which requirement level does this belong?

+
    +
  • A Stakeholder Requirements
    • +
  • B Feature Requirements
    • +
  • C Component Requirements
    • +
  • D Process Requirements
    • +
+ +
+
+

Q2. An integrator is building a vehicle product using an S-CORE platform component. They receive a document listing the conditions their application must satisfy to use the component safely. What type of requirement is this?

+
    +
  • A Stakeholder Requirements
    • +
  • B Process Requirements
    • +
  • C Assumptions of Use (AoU)
    • +
  • D Functional Requirements
    • +
+ +
+
+

Q3. Which requirement type is verified by reviewing the process description rather than by functional test execution?

+
    +
  • A Functional
    • +
  • B Interface
    • +
  • C Process
    • +
  • D Non-Functional
    • +
+ +
+ +
+
+ + + + + +
+ + ← Module 1: Why Requirements Engineering? + + + + Module 3: Requirement Attributes and Quality → + + +
+ +
+
+ + + + + + \ No newline at end of file diff --git a/process/trainings/trainings_requirements_engineering/portal/module-3.html b/process/trainings/trainings_requirements_engineering/portal/module-3.html new file mode 100644 index 0000000000..5bd5432ec6 --- /dev/null +++ b/process/trainings/trainings_requirements_engineering/portal/module-3.html @@ -0,0 +1,358 @@ + + + + + +Requirement Attributes and Quality | S-CORE Process Training + + + + + +
+ + +
+ Course Overview + + › + Module 3: Requirement Attributes and Quality + +
+ +
+ + + + +

Requirement Attributes and Quality

+
+ ⏱ ~45 min + 📖 Module 3 of 4 + 🗂 Requirements +
+ +

Requirement Attributes and Quality

+

A requirement without well-defined attributes is not a requirement — it is a +wish. S-CORE mandates a specific attribute set for every requirement and +automates part of its population. This module covers all attributes, versioning +rules, and the formulation principles that make requirements verifiable.

+

3.1 Manual Attributes

+

Every S-CORE requirement must have the following attributes set by the author +before a pull request can be merged:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
AttributeValues / FormatPurpose
Unique ID<type_prefix>__<keyword>_<shortname>Stable identifier used for all traceability links
Statusvalid | invalidOnly valid requirements are accepted in main branch
TitleFree text, expressiveHuman-readable label
DescriptionFree textThe actual requirement statement
VersionInteger (1, 2, 3, …)Bumped on every significant change
Rationale / LinkageFree text | derived_from linkStakeholder reqs need a rationale; derived reqs link to parent
SafetyQM | ASIL_BSafety integrity level of this requirement
SecurityBoolean / free textWhether the requirement has security relevance
TypeFunctional | Interface | Process | Non-FunctionalDetermines verification method and linkage rules
+
+
No "Draft" Status in Main Branch
+

S-CORE intentionally has no draft status value. A requirement is either +valid (merged) or it lives in a pull request / feature branch. This forces +engineers to complete a requirement before integrating it rather than +accumulating technical debt in the form of unfinished requirements.

+
+ +

3.2 The Safety Attribute in Detail

+

The safety attribute is the cornerstone of ISO 26262 compliance. S-CORE +currently supports two values:

+ + + + + + + + + + + + + + + + + +
ValueMeaning
QMQuality Management — no ASIL claim; standard software quality processes apply
ASIL_BAutomotive Safety Integrity Level B — requires ASIL-B process measures, verification rigour, and traceability
+
+
ASIL Decomposition Is Not Used
+

S-CORE does not currently apply ASIL decomposition, so ASIL_A, ASIL_C, and +ASIL_D are not required. Only QM and ASIL_B are defined. All safety-relevant +requirements must be classified ASIL_B — a safety-relevant requirement that is +incorrectly marked QM is a safety defect.

+
+ +

The tooling enforces linkage rules: an ASIL_B requirement may only be linked to +other ASIL_B requirements or to QM requirements with a documented rationale.

+

3.3 Auto-Generated Attributes

+

The Docs-as-Code build populates three attributes automatically, eliminating +manual maintenance overhead and ensuring the attributes are always current:

+ + + + + + + + + + + + + + + + + + + + + + + + + +
AttributeHow it is populatedTool
DerivesAutomatically inserted into the parent requirement when a child requirement references it via derived_fromDocs-as-Code
Implemented bySource files are scanned for a defined tag containing the requirement ID; matching code locations are linkedDocs-as-Code
Verified byTest files are scanned for a defined marker containing the requirement ID; matching test cases are linkedDocs-as-Code
+
+
How Implemented by Works
+

A developer adds the following tag in C++ source code:

+
// [feat__json_config__parse_body]
+void ConfigParser::parseBody(const std::string& json) { ... }
+
+

During the docs build, the tool finds this tag, resolves feat__json_config__parse_body +to the corresponding feature requirement, and automatically links the source +file and line to the implemented_by attribute.

+
+ +

This automatic population means that the traceability matrix is always +regenerated from the actual code and test artefacts — it cannot be manually +falsified or forgotten.

+

3.4 Requirement Versioning

+

Significant vs. Non-Significant Changes

+

Not every edit to a requirement warrants a version increment. S-CORE defines +precisely which changes are significant:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
AttributeSignificant changeNon-significant change
DescriptionFunctional content change or rewrite affecting meaningTypo corrections, layout, notes
SafetyAny change—
SecurityAny change—
TypeAny change—
+
+
Version Mismatch Is a Build Error
+

Child requirements reference their parent requirement with an explicit version number +(e.g., derived_from: stkh__platform__config_files[version==2]). If the parent +requirement's version is later bumped, all child derivation links become stale and +the docs build emits a warning that blocks merging until the child requirements +are updated. This ensures that a change in a parent requirement always triggers a +review of all its children.

+
+ +

Versioning Sets of Requirements

+

Individual requirement versioning covers single-requirement changes. For +baselines — frozen sets of requirements used as the basis for a release or +for a safety case — S-CORE uses standard version control tagging: a git tag +applied to the repository records the exact state of all requirement files.

+

3.5 Requirement Quality and Formulation

+

A well-written requirement has four properties:

+ + + + + + + + + + + + + + + + + + + + + + + + + +
PropertyTest question
AtomicDoes the requirement describe exactly one thing?
VerifiableCan we write a test or review criterion that definitively confirms conformance?
UnambiguousIs there exactly one valid interpretation?
TraceableDoes the requirement link upward to a parent (or have a rationale) and downward to implementation and test?
+
+
Notes Are Not Requirements
+

A note in a requirement (marked as such in the Docs-as-Code tool) is not part of +the requirement itself. Notes provide additional explanation or context but +must not contain normative content. Reviewers must check that normative +statements are in the description, not buried in notes.

+
+ +

3.6 Requirement Reviews

+

Requirements that cannot be checked automatically require a manual inspection. +The S-CORE process supports two kinds of review:

+
    +
  1. Peer review (PR review) — every requirement passes through a pull request + where Committers and Project Leads review it before it is merged to main.
    2. +
  2. Formal inspection — triggered explicitly when a contributor wants a + thorough review of a set of requirements. Uses a structured inspection + checklist that may be integrated into the requirements management tooling.
    3. +
+
+
What does the inspection checklist cover? ▼
+

The inspection checklist verifies:

+
    +
  • Completeness: all mandatory attributes are populated
    • +
  • Consistency: no contradictions between requirements at the same level
    • +
  • Feasibility: the requirement can realistically be implemented and tested
    • +
  • Traceability: every requirement is derived from a parent or has a documented rationale
    • +
  • Safety/security classification: safety attribute is correct relative to safety analysis
    • +
  • Formulation quality: atomic, verifiable, unambiguous
    • +
+
+
+

Module Check-In

+

Answer all questions and click Submit to check your understanding.

+
+

Q1. A developer edits a requirement's description to fix a typo and improve layout, with no change to its functional meaning. Should the version attribute be incremented?

+
    +
  • A Yes — any edit to a requirement must increment the version
    • +
  • B No — only significant changes (functional content, safety, security, type) trigger a version increment
    • +
  • C Yes — the version must be incremented so child links are re-validated
    • +
  • D No — versions are only managed by git tags, not per-requirement
    • +
+ +
+
+

Q2. Which attribute is automatically populated by the Docs-as-Code build when test files contain a defined marker with the requirement ID?

+
    +
  • A Derives
    • +
  • B Implemented by
    • +
  • C Verified by
    • +
  • D Status
    • +
+ +
+
+

Q3. A requirement is marked safety=QM but a safety analysis has determined it is ASIL_B relevant. What is the consequence?

+
    +
  • A Nothing — QM and ASIL_B requirements can be freely mixed
    • +
  • B The build will flag a linkage violation and the requirement is a safety defect
    • +
  • C The requirement is automatically upgraded to ASIL_B at build time
    • +
  • D A note is added to the requirement by the tool
    • +
+ +
+ +
+
+ + + + + +
+ + ← Module 2: Requirement Levels and Types + + + + Module 4: Workflows and Work Products → + + +
+ +
+
+ + + + + + \ No newline at end of file diff --git a/process/trainings/trainings_requirements_engineering/portal/module-4.html b/process/trainings/trainings_requirements_engineering/portal/module-4.html new file mode 100644 index 0000000000..4fb2195acb --- /dev/null +++ b/process/trainings/trainings_requirements_engineering/portal/module-4.html @@ -0,0 +1,324 @@ + + + + + +Workflows and Work Products | S-CORE Process Training + + + + + +
+ + +
+ Course Overview + + › + Module 4: Workflows and Work Products + +
+ +
+ + + + +

Workflows and Work Products

+
+ ⏱ ~45 min + 📖 Module 4 of 4 + 🗂 Requirements +
+ +

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

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Workflow IDWorkflow nameResponsibleApproved by
wf__req_stkh_reqCreate/Maintain Stakeholder Requirements and SW-Platform AoUContributorProject Lead
wf__req_feat_reqCreate/Maintain Feature RequirementsContributorProject Lead
wf__req_feat_aouCreate/Maintain Feature AoUsContributorProject Lead
wf__req_comp_reqCreate/Maintain Component RequirementsContributorCommitter
wf__req_comp_aouCreate/Maintain Component AoUsContributorCommitter
wf__req_toolCreate/Maintain Tool/Process RequirementsContributorCommitter
+

All six 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.

+

Safety Managers are supported_by in the three stakeholder/feature workflows; +both Safety and Security Managers 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

+
+
Triggering this workflow
+

A project lead opens a change request: "The platform shall support OTA software +updates for individual components." A contributor writes the stakeholder +requirement and the SW-Platform AoU (the conditions the OEM integrator must +satisfy to use OTA safely). The project lead reviews and approves the PR.

+
+ +

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
    • +
+
+
AoU and Architecture Are Coupled
+

AoUs cannot be written without the architecture work product because AoUs +emerge from the safety concept: once the architecture defines the isolation +boundaries and safety mechanisms, the AoUs state what conditions must hold +outside those boundaries for the safety concept to be valid.

+
+ +

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.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Work ProductIDCompliance tags
Stakeholder Requirementswp__requirements_stkhISO 26262 §8/6.5.1, ISO/SAE 21434 §10.5.1
Feature Requirementswp__requirements_featISO 26262 §8/6.5.1, ISO/SAE 21434 §10.5.1
Component Requirementswp__requirements_compISO 26262 §8/6.5.1, ISO PAS 8926 §4.5.2.1, ISO 26262 analysis annex, ISO/SAE 21434 §10.5.1
SW-Platform AoUwp__requirements_sw_platform_aouISO 26262 §8/6.5.1, ISO/SAE 21434 §10.5.1–2
Feature AoUwp__requirements_feat_aouISO 26262 §8/6.5.1, ISO/SAE 21434 §10.5.1–2
Component AoUwp__requirements_comp_aouISO 26262 §8/6.5.1, ISO PAS 8926 §4.5.2.1, ISO/SAE 21434 §10.5.1–2
Process/Tool Requirementswp__requirements_proc_tool(internal process lifecycle)
Requirements Inspectionwp__requirements_inspectISO 26262 §8/6.5.3
+

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
+
+
+
Traceability Is Automatically Maintained
+

The implemented_by and verified_by links are populated automatically by the +Docs-as-Code build. This means the traceability matrix is always regenerated +from the real artefacts — it cannot drift from the code. Auditors can trust +that a requirement shown as "verified by test X" genuinely corresponds to a test +that references that requirement ID.

+
+ +

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. +
  2. Build-time validation — attribute completeness, version link consistency, linkage rule enforcement, and safety attribute propagation checks.
    3. +
  3. Coverage reports — automatically generated views showing which requirements lack implemented_by or verified_by links (coverage gaps).
    4. +
  4. PR-based review workflow — all requirement changes go through a pull request; the Committer or Project Lead review is recorded in git history.
    5. +
+
+
Getting Started
+

The Requirements Engineering "Getting Started" guide (doc_getstrt__req_process) +describes the exact steps for creating a new requirement, deriving child +requirements, and triggering a formal inspection. The workflow diagram in that +guide maps every step to the corresponding workflow ID listed in Section 4.1.

+
+ +
+
Linking requirements to code and tests — practical steps ▼
+
    +
  1. Find the requirement ID in the generated HTML portal or in the RST source.
    2. +
  2. Add the implementation tag in the source file as a structured comment: + // [<requirement_id>] (exact syntax depends on the Docs-as-Code version).
    3. +
  3. Add the verification marker in the test file using the framework-specific + marker (e.g., a pytest mark or a comment annotation).
    4. +
  4. Run the docs build (bazel run //:docs). The build will now populate + implemented_by and verified_by in the HTML output.
    5. +
  5. Verify coverage in the generated requirements traceability report.
    6. +
+
+
+

Module Check-In

+

Answer all questions and click Submit to check your understanding.

+
+

Q1. A contributor wants to create new Component Requirements. Which approval chain applies?

+
    +
  • A Written by Safety Manager, approved by Project Lead
    • +
  • B Written by Contributor, approved by Committer
    • +
  • C Written by Committer, approved by Project Lead
    • +
  • D Written by Contributor, approved by Safety Manager
    • +
+ +
+
+

Q2. Feature AoU requirements have an additional input compared to Feature Requirements. What is it?

+
    +
  • A wp__requirements_stkh (Stakeholder Requirements)
    • +
  • B wp__requirements_comp (Component Requirements)
    • +
  • C wp__feature_arch (Feature Architecture)
    • +
  • D wp__issue_track_system (Issue Tracker)
    • +
+ +
+
+

Q3. An auditor asks: 'How do you guarantee that the traceability matrix between requirements and test cases is up to date?' What is the correct S-CORE answer?

+
    +
  • A The traceability matrix is maintained manually by the Safety Manager and reviewed quarterly
    • +
  • B Traceability is managed in an external ALM tool which is synced monthly
    • +
  • C The Docs-as-Code build automatically regenerates the verified_by links from test file markers on every build, so the matrix cannot drift from the actual test artefacts
    • +
  • D Developers are required to update the traceability spreadsheet when they add tests
    • +
+ +
+ +
+
+ + + + + +
+ + ← Module 3: Requirement Attributes and Quality + + + + Checkpoint Quiz → + + +
+ +
+
+ + + + + + \ No newline at end of file diff --git a/process/trainings/trainings_requirements_engineering/portal/quiz-1.html b/process/trainings/trainings_requirements_engineering/portal/quiz-1.html new file mode 100644 index 0000000000..81421cc911 --- /dev/null +++ b/process/trainings/trainings_requirements_engineering/portal/quiz-1.html @@ -0,0 +1,225 @@ + + + + + +Requirements Engineering Checkpoint Quiz | S-CORE Process Training + + + + + + + +
+ + +
+ Course Overview + + › + Requirements Engineering Checkpoint Quiz + +
+ +
+ + + + +
+

Requirements Engineering Checkpoint Quiz

+

10 questions covering all four modules — Module 1 through Module 4. Read each question carefully. Some questions are scenario-based. Instant scoring with explanations on submission.

+
+ 📋 10 Questions⏱ ~20 min🎯 Pass mark: 70% (7/10)📖 Covers Modules 1–4 +
+
+ +
+
+

Q1. Why is structured requirements engineering mandated in S-CORE rather than left to individual project discretion?

+
    +
  • A It is required because requirements management tools are already available in the platform.
    • +
  • B ISO 26262, ASPICE SWE.1, ISO/SAE 21434, and ISO PAS 8926 all require a documented, traceable requirements hierarchy as a precondition for certification; without it a safety and security release is not possible.
    • +
  • C It is only needed for ASIL_D projects; QM-only projects can skip structured RE.
    • +
  • D Requirements engineering is optional — projects can substitute it with comprehensive test coverage.
    • +
+ +
+
+

Q2. In S-CORE, any Contributor may write a requirement. Which of the following statements about the approval process is correct?

+
    +
  • A Contributors may directly merge requirements without review if the safety attribute is QM.
    • +
  • B All requirements are approved exclusively by Safety Managers.
    • +
  • C Stakeholder and Feature requirements must be approved by the Project Lead; Component requirements must be approved by a Committer.
    • +
  • D Requirements are approved by the Feature User because they are the primary consumer.
    • +
+ +
+
+

Q3. A requirement states: 'The platform shall support JSON-based configuration.' At which level does this belong, and why?

+
    +
  • A Component Requirements — because it describes a concrete implementation detail.
    • +
  • B Stakeholder Requirements — because it describes a platform-level capability at high abstraction, without specifying how any component implements it.
    • +
  • C Feature Requirements — because JSON is a specific technical format.
    • +
  • D Process Requirements — because it describes a process constraint.
    • +
+ +
+
+

Q4. An S-CORE component is released for integration into a vehicle OEM project. The OEM needs to know the boundary conditions their application must satisfy for the component to behave correctly under safety constraints. Which S-CORE work product delivers this information?

+
    +
  • A wp__requirements_comp (Component Requirements)
    • +
  • B wp__requirements_feat (Feature Requirements)
    • +
  • C wp__requirements_comp_aou (Component Assumptions of Use)
    • +
  • D wp__requirements_proc_tool (Process/Tool Requirements)
    • +
+ +
+
+

Q5. Which values are currently defined for the 'safety' attribute in S-CORE requirements?

+
    +
  • A QM and ASIL_B only, because ASIL decomposition is not used in S-CORE.
    • +
  • B ASIL_A, ASIL_B, ASIL_C, and ASIL_D to cover the full ISO 26262 range.
    • +
  • C QM, ASIL_A, and ASIL_B for the subset of ISO 26262 levels used in automotive OSS.
    • +
  • D Safety classification is not an attribute in S-CORE requirements.
    • +
+ +
+
+

Q6. A developer edits a Component Requirement by changing its description to fix a typo and rewrites one sentence for clarity — the functional meaning is identical. Must the version attribute be incremented?

+
    +
  • A Yes — any edit to description requires a version bump.
    • +
  • B No — only functional content changes, or changes to the safety, security, or type attribute, are significant and require a version increment.
    • +
  • C Yes — otherwise child requirement links become invalid.
    • +
  • D No — version increments are only required for ASIL_B requirements.
    • +
+ +
+
+

Q7. Which of the three auto-generated attributes is populated by scanning source code files for a defined tag containing the requirement ID?

+
    +
  • A Derives
    • +
  • B Implemented by
    • +
  • C Verified by
    • +
  • D Status
    • +
+ +
+
+

Q8. A contributor wants to create Feature AoU requirements. Compared to a plain Feature Requirements workflow, which additional input is required?

+
    +
  • A wp__requirements_stkh (Stakeholder Requirements)
    • +
  • B wp__requirements_proc_tool (Process/Tool Requirements)
    • +
  • C wp__feature_arch (Feature Architecture)
    • +
  • D wp__requirements_inspect (Requirements Inspection)
    • +
+ +
+
+

Q9. A safety auditor asks how S-CORE ensures that a requirement shown as 'verified by Test_X' in the documentation genuinely corresponds to a test that references that requirement. What is the correct answer?

+
    +
  • A The Safety Manager manually cross-checks the traceability matrix against the test repository each sprint.
    • +
  • B The Docs-as-Code build scans all test files for requirement ID markers on every build and regenerates the 'verified_by' links automatically, so the documentation can never show a test link that does not exist in the codebase.
    • +
  • C An external ALM tool is synchronised monthly to keep the traceability matrix current.
    • +
  • D Developers are required to update the traceability spreadsheet whenever a new test is added.
    • +
+ +
+
+

Q10. A new feature is being specified. The correct end-to-end flow in S-CORE is:

+
    +
  • A Write Component Requirements first to anchor implementation, then derive Feature and Stakeholder Requirements bottom-up.
    • +
  • B Write Process Requirements, then Stakeholder Requirements, then derive Feature and Component Requirements top-down, linking each level to its parent with a versioned derived_from reference.
    • +
  • C Write Feature Requirements first, then both Stakeholder Requirements and Component Requirements independently.
    • +
  • D Only Stakeholder Requirements and Component Requirements are needed; Feature Requirements are optional in S-CORE.
    • +
+ +
+ +
+ +
+
🏆
+

Requirements Engineering Certified

+

You have successfully passed the S-CORE Requirements Engineering Training.

+
S-CORE Requirements Engineering Training — Eclipse Foundation
+

+ Eclipse S-CORE Training Program · +

+
+
+ + + + + +
+ + ← Module 4: Workflows and Work Products + + +
+ +
+
+ + + + + + \ No newline at end of file diff --git a/process/trainings/trainings_requirements_engineering/portal/style.css b/process/trainings/trainings_requirements_engineering/portal/style.css new file mode 100644 index 0000000000..bb588bd1eb --- /dev/null +++ b/process/trainings/trainings_requirements_engineering/portal/style.css @@ -0,0 +1,438 @@ +/* S-CORE Requirements Engineering Training Portal — Shared Styles */ + +:root { + --navy: #1e2d45; + --navy-light: #2a3f60; + --blue: #1a4d8f; + --blue-light: #2563ab; + --amber: #d97706; + --amber-light: #fef3c7; + --green: #2d8a4e; + --green-light: #d1fae5; + --red: #c0392b; + --red-light: #fde8e8; + --gray-100: #f5f7fa; + --gray-200: #e2e8f0; + --gray-400: #94a3b8; + --gray-600: #475569; + --gray-800: #1e293b; + --white: #ffffff; + --sidebar-w: 270px; + --header-h: 60px; + --font: 'Segoe UI', system-ui, -apple-system, sans-serif; + --font-mono: 'Consolas', 'Courier New', monospace; +} + +*, *::before, *::after { box-sizing: border-box; margin: 0; padding: 0; } + +html { font-size: 16px; scroll-behavior: smooth; } + +body { + font-family: var(--font); + color: var(--gray-800); + background: var(--gray-100); + min-height: 100vh; + display: flex; +} + +/* ── Sidebar ────────────────────────────────────── */ +#sidebar { + width: var(--sidebar-w); + min-height: 100vh; + background: var(--navy); + color: #c8d6e5; + display: flex; + flex-direction: column; + position: fixed; + top: 0; left: 0; bottom: 0; + z-index: 100; + overflow-y: auto; +} + +#sidebar .brand { + padding: 20px 20px 16px; + border-bottom: 1px solid var(--navy-light); +} +#sidebar .brand h1 { + font-size: 0.85rem; + font-weight: 700; + text-transform: uppercase; + letter-spacing: .08em; + color: var(--white); + line-height: 1.4; +} +#sidebar .brand p { + font-size: 0.72rem; + color: var(--gray-400); + margin-top: 4px; +} + +.progress-area { + padding: 14px 20px; + border-bottom: 1px solid var(--navy-light); +} +.progress-label { + display: flex; + justify-content: space-between; + font-size: 0.72rem; + color: var(--gray-400); + margin-bottom: 6px; +} +.progress-bar-outer { + background: var(--navy-light); + border-radius: 4px; + height: 6px; + overflow: hidden; +} +.progress-bar-inner { + background: var(--amber); + height: 100%; + border-radius: 4px; + transition: width .4s ease; +} + +.nav-section-label { + font-size: 0.65rem; + font-weight: 700; + text-transform: uppercase; + letter-spacing: .1em; + color: var(--gray-400); + padding: 16px 20px 6px; +} + +#sidebar nav a { + display: flex; + align-items: center; + gap: 10px; + padding: 10px 20px; + text-decoration: none; + color: #c8d6e5; + font-size: 0.84rem; + border-left: 3px solid transparent; + transition: background .15s, border-color .15s; +} +#sidebar nav a:hover { background: var(--navy-light); color: var(--white); } +#sidebar nav a.active { background: var(--navy-light); border-left-color: var(--amber); color: var(--white); } +#sidebar nav a.completed .nav-icon { color: var(--green); } + +.nav-icon { + width: 20px; + height: 20px; + border-radius: 50%; + display: flex; + align-items: center; + justify-content: center; + font-size: 0.7rem; + font-weight: 700; + flex-shrink: 0; + background: var(--navy-light); + color: var(--gray-400); +} +a.active .nav-icon { background: var(--amber); color: var(--white); } +a.completed .nav-icon { background: var(--green); color: var(--white); } + +.nav-sep { margin: 8px 20px; border: none; border-top: 1px solid var(--navy-light); } + +/* ── Main Layout ───────────────────────────────── */ +#main { + margin-left: var(--sidebar-w); + flex: 1; + min-height: 100vh; + display: flex; + flex-direction: column; +} + +/* ── Top Bar ───────────────────────────────────── */ +#topbar { + background: var(--white); + border-bottom: 1px solid var(--gray-200); + height: var(--header-h); + display: flex; + align-items: center; + padding: 0 40px; + gap: 8px; + font-size: 0.82rem; + color: var(--gray-600); + position: sticky; + top: 0; + z-index: 50; +} +#topbar a { color: var(--blue); text-decoration: none; } +#topbar a:hover { text-decoration: underline; } +#topbar .sep { color: var(--gray-400); } + +/* ── Content Area ──────────────────────────────── */ +#content { + flex: 1; + padding: 40px 48px 80px; + max-width: 900px; +} + +/* ── Typography ───────────────────────────────── */ +h1.module-title { + font-size: 2rem; + font-weight: 700; + color: var(--gray-800); + margin-bottom: 6px; + line-height: 1.25; +} +.module-meta { + font-size: 0.82rem; + color: var(--gray-400); + display: flex; + gap: 16px; + margin-bottom: 32px; + flex-wrap: wrap; +} +.module-meta span { display: flex; align-items: center; gap: 4px; } + +h2 { + font-size: 1.3rem; + font-weight: 700; + color: var(--blue); + margin: 36px 0 14px; + padding-bottom: 8px; + border-bottom: 2px solid var(--gray-200); +} +h3 { + font-size: 1.05rem; + font-weight: 600; + color: var(--gray-800); + margin: 24px 0 10px; +} +p { line-height: 1.7; margin-bottom: 14px; color: var(--gray-800); } +ul, ol { margin: 10px 0 16px 22px; } +li { line-height: 1.7; margin-bottom: 4px; } +strong { color: var(--gray-800); } + +/* ── Callout Boxes ─────────────────────────────── */ +.callout { + border-radius: 8px; + padding: 16px 20px; + margin: 20px 0; + border-left: 4px solid; +} +.callout.definition { + background: #eff6ff; + border-color: var(--blue); +} +.callout.definition .callout-label { color: var(--blue); } +.callout.example { + background: var(--amber-light); + border-color: var(--amber); +} +.callout.example .callout-label { color: var(--amber); } +.callout.important { + background: #fef2f2; + border-color: var(--red); +} +.callout.important .callout-label { color: var(--red); } +.callout.tip { + background: var(--green-light); + border-color: var(--green); +} +.callout.tip .callout-label { color: var(--green); } +.callout-label { + font-size: 0.72rem; + font-weight: 700; + text-transform: uppercase; + letter-spacing: .08em; + margin-bottom: 6px; +} +.callout p:last-child { margin-bottom: 0; } + +/* ── Tables ─────────────────────────────────────── */ +.table-wrap { overflow-x: auto; margin: 20px 0; border-radius: 8px; border: 1px solid var(--gray-200); } +table { width: 100%; border-collapse: collapse; font-size: 0.88rem; } +thead { background: var(--blue); color: var(--white); } +thead th { padding: 10px 14px; text-align: left; font-weight: 600; } +tbody tr:nth-child(even) { background: var(--gray-100); } +tbody tr:hover { background: #e8f0fe; } +tbody td { padding: 9px 14px; border-bottom: 1px solid var(--gray-200); vertical-align: top; } +tbody tr:last-child td { border-bottom: none; } + +/* ── ASIL badge colors ────────────────────────── */ +.asil { display: inline-block; padding: 2px 8px; border-radius: 4px; font-weight: 700; font-size: 0.8rem; } +.asil-qm { background: #e5e7eb; color: #374151; } +.asil-a { background: #fef3c7; color: #92400e; } +.asil-b { background: #fed7aa; color: #9a3412; } +.asil-c { background: #fecaca; color: #991b1b; } +.asil-d { background: #dc2626; color: #fff; } + +/* ── Collapsible Sections ──────────────────────── */ +.collapsible { + border: 1px solid var(--gray-200); + border-radius: 8px; + margin: 16px 0; + overflow: hidden; +} +.collapsible-header { + display: flex; + justify-content: space-between; + align-items: center; + padding: 14px 20px; + background: var(--white); + cursor: pointer; + user-select: none; + font-weight: 600; + font-size: 0.95rem; + transition: background .15s; +} +.collapsible-header:hover { background: var(--gray-100); } +.collapsible-header .arrow { + font-size: 0.8rem; + color: var(--gray-400); + transition: transform .25s; +} +.collapsible-header.open .arrow { transform: rotate(180deg); } +.collapsible-body { display: none; padding: 16px 20px; background: var(--white); border-top: 1px solid var(--gray-200); } +.collapsible-body.open { display: block; } + +/* ── Inline Quiz (per module) ──────────────────── */ +.quiz-section { + background: var(--white); + border: 2px solid var(--blue); + border-radius: 12px; + padding: 28px 32px; + margin: 40px 0; +} +.quiz-section h2 { + color: var(--blue); + border: none; + padding: 0; + margin: 0 0 6px; + font-size: 1.15rem; +} +.quiz-section .quiz-intro { color: var(--gray-600); font-size: 0.88rem; margin-bottom: 24px; } +.question-block { margin-bottom: 28px; } +.question-text { font-weight: 600; margin-bottom: 12px; line-height: 1.55; } +.question-num { color: var(--blue); margin-right: 6px; } +.options { list-style: none; margin: 0; padding: 0; } +.options li { + display: flex; + align-items: flex-start; + gap: 10px; + padding: 10px 14px; + border: 1.5px solid var(--gray-200); + border-radius: 6px; + margin-bottom: 8px; + cursor: pointer; + transition: background .15s, border-color .15s; + font-size: 0.9rem; + line-height: 1.5; +} +.options li:hover { border-color: var(--blue-light); background: #eff6ff; } +.options li.selected { border-color: var(--blue); background: #eff6ff; } +.options li.correct { border-color: var(--green); background: var(--green-light); } +.options li.wrong { border-color: var(--red); background: var(--red-light); } +.options li.reveal-correct { border-color: var(--green); background: var(--green-light); } +.opt-letter { + width: 24px; height: 24px; + border-radius: 50%; + background: var(--gray-200); + color: var(--gray-600); + font-size: 0.75rem; + font-weight: 700; + display: flex; align-items: center; justify-content: center; + flex-shrink: 0; +} +li.correct .opt-letter { background: var(--green); color: #fff; } +li.wrong .opt-letter { background: var(--red); color: #fff; } +li.reveal-correct .opt-letter { background: var(--green); color: #fff; } +.feedback { + display: none; + margin-top: 10px; + padding: 10px 14px; + border-radius: 6px; + font-size: 0.85rem; + line-height: 1.5; +} +.feedback.correct-fb { background: var(--green-light); color: #065f46; } +.feedback.wrong-fb { background: var(--red-light); color: #7f1d1d; } +.quiz-submit { + display: inline-flex; + align-items: center; + gap: 8px; + background: var(--blue); + color: var(--white); + border: none; + padding: 11px 24px; + border-radius: 6px; + font-size: 0.9rem; + font-weight: 600; + cursor: pointer; + margin-top: 8px; + transition: background .15s; +} +.quiz-submit:hover { background: var(--blue-light); } +.quiz-submit:disabled { background: var(--gray-400); cursor: not-allowed; } +.quiz-result { + display: none; + margin-top: 20px; + padding: 16px 20px; + border-radius: 8px; + font-weight: 600; +} +.quiz-result.pass { background: var(--green-light); color: #065f46; border-left: 4px solid var(--green); } +.quiz-result.fail { background: var(--red-light); color: #7f1d1d; border-left: 4px solid var(--red); } + +/* ── Navigation Footer ─────────────────────────── */ +.page-nav { + display: flex; + justify-content: space-between; + align-items: center; + margin-top: 40px; + padding-top: 24px; + border-top: 1px solid var(--gray-200); + gap: 12px; +} +.btn-nav { + display: inline-flex; + align-items: center; + gap: 8px; + padding: 10px 20px; + border-radius: 6px; + font-size: 0.88rem; + font-weight: 600; + text-decoration: none; + transition: background .15s; +} +.btn-prev { background: var(--white); color: var(--blue); border: 1.5px solid var(--gray-200); } +.btn-prev:hover { background: var(--gray-100); } +.btn-next { background: var(--blue); color: var(--white); border: 1.5px solid transparent; } +.btn-next:hover { background: var(--blue-light); } + +/* ── Intro / Index Page ────────────────────────── */ +.course-hero { + background: linear-gradient(135deg, var(--navy) 0%, var(--blue) 100%); + border-radius: 12px; + padding: 40px 48px; + color: var(--white); + margin-bottom: 40px; +} +.course-hero h1 { font-size: 2.2rem; margin-bottom: 10px; } +.course-hero p { color: #c8d6e5; max-width: 600px; line-height: 1.7; } +.module-cards { display: grid; grid-template-columns: 1fr 1fr; gap: 16px; margin: 24px 0; } +.module-card { + background: var(--white); + border: 1.5px solid var(--gray-200); + border-radius: 10px; + padding: 20px 24px; + text-decoration: none; + color: var(--gray-800); + transition: border-color .15s, box-shadow .15s; + display: block; +} +.module-card:hover { border-color: var(--blue); box-shadow: 0 4px 12px rgba(26,77,143,.1); } +.module-card .card-num { font-size: 0.72rem; font-weight: 700; color: var(--blue); text-transform: uppercase; letter-spacing: .08em; margin-bottom: 6px; } +.module-card h3 { font-size: 1rem; margin: 0 0 6px; } +.module-card p { font-size: 0.82rem; color: var(--gray-600); margin: 0; } +.module-card .card-meta { font-size: 0.75rem; color: var(--gray-400); margin-top: 10px; } + +/* ── Print ─────────────────────────────────────── */ +@media print { + #sidebar, #topbar, .page-nav, .quiz-submit { display: none; } + #main { margin-left: 0; } + #content { padding: 20px; max-width: 100%; } + .collapsible-body { display: block !important; } +} diff --git a/process/trainings/trainings_requirements_engineering/source/assets/app.js b/process/trainings/trainings_requirements_engineering/source/assets/app.js new file mode 100644 index 0000000000..83da212d05 --- /dev/null +++ b/process/trainings/trainings_requirements_engineering/source/assets/app.js @@ -0,0 +1,188 @@ +/* + * Copyright (c) 2026 Contributors to the Eclipse Foundation + * + * See the NOTICE file(s) distributed with this work for additional + * information regarding copyright ownership. + * + * This program and the accompanying materials are made available under the + * terms of the Apache License Version 2.0 which is available at + * https://www.apache.org/licenses/LICENSE-2.0 + * + * SPDX-License-Identifier: Apache-2.0 + * + * AI Disclosure: This file was largely AI-generated. The AI-generated + * portions are made available under CC0-1.0 and not subject to the + * project's license. The human contributor has reviewed and verified + * that the code is correct. + * SPDX-License-Identifier: CC0-1.0 + * Assisted-by: Claude Sonnet 4.6 + */ + +/* S-CORE Requirements Engineering Training Portal — Progress & Quiz Logic */ + +const MODULES = [ + { id: 'index', label: 'Course Overview', url: 'index.html' }, + { id: 'module-1', label: 'Why Requirements Engineering?', url: 'module-1.html' }, + { id: 'module-2', label: 'Requirement Levels and Types', url: 'module-2.html' }, + { id: 'module-3', label: 'Requirement Attributes and Quality', url: 'module-3.html' }, + { id: 'module-4', label: 'Workflows and Work Products', url: 'module-4.html' }, + { id: 'quiz-1', label: 'Checkpoint Quiz', url: 'quiz-1.html', isQuiz: true }, +]; + +function getProgress() { + const raw = localStorage.getItem('score-re-progress'); + return raw ? JSON.parse(raw) : {}; +} +function markComplete(id) { + const p = getProgress(); p[id] = true; localStorage.setItem('score-re-progress', JSON.stringify(p)); + updateProgressBar(); +} +function isComplete(id) { return !!getProgress()[id]; } + +function updateProgressBar() { + const p = getProgress(); + const total = MODULES.filter(m => m.id !== 'index').length; + const done = MODULES.filter(m => m.id !== 'index' && p[m.id]).length; + const pct = Math.round((done / total) * 100); + document.querySelectorAll('.progress-bar-inner').forEach(el => el.style.width = pct + '%'); + document.querySelectorAll('.progress-pct').forEach(el => el.textContent = pct + '%'); + document.querySelectorAll('.progress-count').forEach(el => el.textContent = done + ' / ' + total + ' complete'); + MODULES.forEach(m => { + const a = document.querySelector(`#sidebar nav a[data-id="${m.id}"]`); + if (!a) return; + const icon = a.querySelector('.nav-icon'); + if (p[m.id]) { a.classList.add('completed'); icon.textContent = '✓'; } + }); +} + +function buildSidebar(activeId) { + const p = getProgress(); + const sb = document.getElementById('sidebar'); + if (!sb) return; + + const total = MODULES.filter(m => m.id !== 'index').length; + const done = MODULES.filter(m => m.id !== 'index' && p[m.id]).length; + const pct = Math.round((done / total) * 100); + + const modules = MODULES.filter(m => m.id !== 'index'); + const navGroup = (label, items, startIdx) => ` +
${label}
+ + `; + + sb.innerHTML = ` +
+

S-CORE
Requirements
Engineering

+

Eclipse Foundation

+
+
+
+ ${done} / ${total} complete + ${pct}% +
+
+
+ + ⌂Course Overview + +
+ ${navGroup('Modules', modules, 1)} + `; +} + +/* ── Collapsible Sections ─────────────────────── */ +function initCollapsibles() { + document.querySelectorAll('.collapsible-header').forEach(header => { + header.addEventListener('click', () => { + header.classList.toggle('open'); + const body = header.nextElementSibling; + body.classList.toggle('open'); + }); + }); +} + +/* ── Quiz Engine ──────────────────────────────── */ +function initQuiz(quizId, passMark, onPass) { + const form = document.getElementById(quizId); + if (!form) return; + + const submitBtn = form.querySelector('.quiz-submit'); + const resultEl = form.querySelector('.quiz-result'); + + form.querySelectorAll('.options li').forEach(opt => { + opt.addEventListener('click', () => { + const questionBlock = opt.closest('.question-block'); + if (questionBlock.dataset.answered) return; + questionBlock.querySelectorAll('.options li').forEach(o => o.classList.remove('selected')); + opt.classList.add('selected'); + }); + }); + + if (submitBtn) { + submitBtn.addEventListener('click', () => { + let correct = 0; + let total = 0; + let unanswered = false; + + form.querySelectorAll('.question-block').forEach(qb => { + total++; + const selected = qb.querySelector('.options li.selected'); + if (!selected) { unanswered = true; return; } + qb.dataset.answered = '1'; + const isCorrect = selected.dataset.correct === 'true'; + if (isCorrect) { + correct++; + selected.classList.replace('selected', 'correct'); + } else { + selected.classList.replace('selected', 'wrong'); + qb.querySelectorAll('.options li').forEach(o => { + if (o.dataset.correct === 'true') o.classList.add('reveal-correct'); + }); + } + const fb = qb.querySelector('.feedback'); + if (fb) { + fb.style.display = 'block'; + fb.classList.add(isCorrect ? 'correct-fb' : 'wrong-fb'); + } + }); + + if (unanswered) { alert('Please answer all questions before submitting.'); return; } + + submitBtn.disabled = true; + const pct = Math.round((correct / total) * 100); + resultEl.style.display = 'block'; + if (pct >= passMark) { + resultEl.className = 'quiz-result pass'; + resultEl.innerHTML = `✓ Passed! You scored ${correct}/${total} (${pct}%). ${onPass ? 'Module marked as complete.' : ''}`; + if (onPass) { markComplete(onPass); } + } else { + resultEl.className = 'quiz-result fail'; + resultEl.innerHTML = `✗ Score: ${correct}/${total} (${pct}%). Pass mark is ${passMark}%. Review the sections above and try again.`; + } + }); + } +} + +/* ── Auto-mark module visited ─────────────────── */ +function autoMarkVisited(id) { + if (id && id !== 'index' && !id.startsWith('quiz')) { + markComplete(id); + } +} + +document.addEventListener('DOMContentLoaded', () => { + const pageId = document.body.dataset.page; + autoMarkVisited(pageId); + buildSidebar(pageId); + initCollapsibles(); +}); diff --git a/process/trainings/trainings_requirements_engineering/source/assets/style.css b/process/trainings/trainings_requirements_engineering/source/assets/style.css new file mode 100644 index 0000000000..c225f1a2fe --- /dev/null +++ b/process/trainings/trainings_requirements_engineering/source/assets/style.css @@ -0,0 +1,458 @@ +/* + * Copyright (c) 2026 Contributors to the Eclipse Foundation + * + * See the NOTICE file(s) distributed with this work for additional + * information regarding copyright ownership. + * + * This program and the accompanying materials are made available under the + * terms of the Apache License Version 2.0 which is available at + * https://www.apache.org/licenses/LICENSE-2.0 + * + * SPDX-License-Identifier: Apache-2.0 + * + * AI Disclosure: This file was largely AI-generated. The AI-generated + * portions are made available under CC0-1.0 and not subject to the + * project's license. The human contributor has reviewed and verified + * that the code is correct. + * SPDX-License-Identifier: CC0-1.0 + * Assisted-by: Claude Sonnet 4.6 + */ + +/* S-CORE Requirements Engineering Training Portal — Shared Styles */ + +:root { + --navy: #2d1942; + --navy-light: #3d2460; + --blue: #7c4daa; + --blue-light: #a382c5; + --amber: #d97706; + --amber-light: #fef3c7; + --green: #2d8a4e; + --green-light: #d1fae5; + --red: #c0392b; + --red-light: #fde8e8; + --gray-100: #f5f7fa; + --gray-200: #e2e8f0; + --gray-400: #94a3b8; + --gray-600: #475569; + --gray-800: #1e293b; + --white: #ffffff; + --sidebar-w: 270px; + --header-h: 60px; + --font: 'Segoe UI', system-ui, -apple-system, sans-serif; + --font-mono: 'Consolas', 'Courier New', monospace; +} + +*, *::before, *::after { box-sizing: border-box; margin: 0; padding: 0; } + +html { font-size: 16px; scroll-behavior: smooth; } + +body { + font-family: var(--font); + color: var(--gray-800); + background: var(--gray-100); + min-height: 100vh; + display: flex; +} + +/* ── Sidebar ────────────────────────────────────── */ +#sidebar { + width: var(--sidebar-w); + min-height: 100vh; + background: var(--navy); + color: #c8d6e5; + display: flex; + flex-direction: column; + position: fixed; + top: 0; left: 0; bottom: 0; + z-index: 100; + overflow-y: auto; +} + +#sidebar .brand { + padding: 20px 20px 16px; + border-bottom: 1px solid var(--navy-light); +} +#sidebar .brand h1 { + font-size: 0.85rem; + font-weight: 700; + text-transform: uppercase; + letter-spacing: .08em; + color: var(--white); + line-height: 1.4; +} +#sidebar .brand p { + font-size: 0.72rem; + color: var(--gray-400); + margin-top: 4px; +} + +.progress-area { + padding: 14px 20px; + border-bottom: 1px solid var(--navy-light); +} +.progress-label { + display: flex; + justify-content: space-between; + font-size: 0.72rem; + color: var(--gray-400); + margin-bottom: 6px; +} +.progress-bar-outer { + background: var(--navy-light); + border-radius: 4px; + height: 6px; + overflow: hidden; +} +.progress-bar-inner { + background: var(--amber); + height: 100%; + border-radius: 4px; + transition: width .4s ease; +} + +.nav-section-label { + font-size: 0.65rem; + font-weight: 700; + text-transform: uppercase; + letter-spacing: .1em; + color: var(--gray-400); + padding: 16px 20px 6px; +} + +#sidebar nav a { + display: flex; + align-items: center; + gap: 10px; + padding: 10px 20px; + text-decoration: none; + color: #c8d6e5; + font-size: 0.84rem; + border-left: 3px solid transparent; + transition: background .15s, border-color .15s; +} +#sidebar nav a:hover { background: var(--navy-light); color: var(--white); } +#sidebar nav a.active { background: var(--navy-light); border-left-color: var(--amber); color: var(--white); } +#sidebar nav a.completed .nav-icon { color: var(--green); } + +.nav-icon { + width: 20px; + height: 20px; + border-radius: 50%; + display: flex; + align-items: center; + justify-content: center; + font-size: 0.7rem; + font-weight: 700; + flex-shrink: 0; + background: var(--navy-light); + color: var(--gray-400); +} +a.active .nav-icon { background: var(--amber); color: var(--white); } +a.completed .nav-icon { background: var(--green); color: var(--white); } + +.nav-sep { margin: 8px 20px; border: none; border-top: 1px solid var(--navy-light); } + +/* ── Main Layout ───────────────────────────────── */ +#main { + margin-left: var(--sidebar-w); + flex: 1; + min-height: 100vh; + display: flex; + flex-direction: column; +} + +/* ── Top Bar ───────────────────────────────────── */ +#topbar { + background: var(--white); + border-bottom: 1px solid var(--gray-200); + height: var(--header-h); + display: flex; + align-items: center; + padding: 0 40px; + gap: 8px; + font-size: 0.82rem; + color: var(--gray-600); + position: sticky; + top: 0; + z-index: 50; +} +#topbar a { color: var(--blue); text-decoration: none; } +#topbar a:hover { text-decoration: underline; } +#topbar .sep { color: var(--gray-400); } + +/* ── Content Area ──────────────────────────────── */ +#content { + flex: 1; + padding: 40px 48px 80px; + max-width: 900px; +} + +/* ── Typography ───────────────────────────────── */ +h1.module-title { + font-size: 2rem; + font-weight: 700; + color: var(--gray-800); + margin-bottom: 6px; + line-height: 1.25; +} +.module-meta { + font-size: 0.82rem; + color: var(--gray-400); + display: flex; + gap: 16px; + margin-bottom: 32px; + flex-wrap: wrap; +} +.module-meta span { display: flex; align-items: center; gap: 4px; } + +h2 { + font-size: 1.3rem; + font-weight: 700; + color: var(--blue); + margin: 36px 0 14px; + padding-bottom: 8px; + border-bottom: 2px solid var(--gray-200); +} +h3 { + font-size: 1.05rem; + font-weight: 600; + color: var(--gray-800); + margin: 24px 0 10px; +} +p { line-height: 1.7; margin-bottom: 14px; color: var(--gray-800); } +ul, ol { margin: 10px 0 16px 22px; } +li { line-height: 1.7; margin-bottom: 4px; } +strong { color: var(--gray-800); } + +/* ── Callout Boxes ─────────────────────────────── */ +.callout { + border-radius: 8px; + padding: 16px 20px; + margin: 20px 0; + border-left: 4px solid; +} +.callout.definition { + background: #f5f0ff; + border-color: var(--blue); +} +.callout.definition .callout-label { color: var(--blue); } +.callout.example { + background: var(--amber-light); + border-color: var(--amber); +} +.callout.example .callout-label { color: var(--amber); } +.callout.important { + background: #fef2f2; + border-color: var(--red); +} +.callout.important .callout-label { color: var(--red); } +.callout.tip { + background: var(--green-light); + border-color: var(--green); +} +.callout.tip .callout-label { color: var(--green); } +.callout-label { + font-size: 0.72rem; + font-weight: 700; + text-transform: uppercase; + letter-spacing: .08em; + margin-bottom: 6px; +} +.callout p:last-child { margin-bottom: 0; } + +/* ── Tables ─────────────────────────────────────── */ +.table-wrap { overflow-x: auto; margin: 20px 0; border-radius: 8px; border: 1px solid var(--gray-200); } +table { width: 100%; border-collapse: collapse; font-size: 0.88rem; } +thead { background: var(--blue); color: var(--white); } +thead th { padding: 10px 14px; text-align: left; font-weight: 600; } +tbody tr:nth-child(even) { background: var(--gray-100); } +tbody tr:hover { background: #e8f0fe; } +tbody td { padding: 9px 14px; border-bottom: 1px solid var(--gray-200); vertical-align: top; } +tbody tr:last-child td { border-bottom: none; } + +/* ── ASIL badge colors ────────────────────────── */ +.asil { display: inline-block; padding: 2px 8px; border-radius: 4px; font-weight: 700; font-size: 0.8rem; } +.asil-qm { background: #e5e7eb; color: #374151; } +.asil-a { background: #fef3c7; color: #92400e; } +.asil-b { background: #fed7aa; color: #9a3412; } +.asil-c { background: #fecaca; color: #991b1b; } +.asil-d { background: #dc2626; color: #fff; } + +/* ── Collapsible Sections ──────────────────────── */ +.collapsible { + border: 1px solid var(--gray-200); + border-radius: 8px; + margin: 16px 0; + overflow: hidden; +} +.collapsible-header { + display: flex; + justify-content: space-between; + align-items: center; + padding: 14px 20px; + background: var(--white); + cursor: pointer; + user-select: none; + font-weight: 600; + font-size: 0.95rem; + transition: background .15s; +} +.collapsible-header:hover { background: var(--gray-100); } +.collapsible-header .arrow { + font-size: 0.8rem; + color: var(--gray-400); + transition: transform .25s; +} +.collapsible-header.open .arrow { transform: rotate(180deg); } +.collapsible-body { display: none; padding: 16px 20px; background: var(--white); border-top: 1px solid var(--gray-200); } +.collapsible-body.open { display: block; } + +/* ── Inline Quiz (per module) ──────────────────── */ +.quiz-section { + background: var(--white); + border: 2px solid var(--blue); + border-radius: 12px; + padding: 28px 32px; + margin: 40px 0; +} +.quiz-section h2 { + color: var(--blue); + border: none; + padding: 0; + margin: 0 0 6px; + font-size: 1.15rem; +} +.quiz-section .quiz-intro { color: var(--gray-600); font-size: 0.88rem; margin-bottom: 24px; } +.question-block { margin-bottom: 28px; } +.question-text { font-weight: 600; margin-bottom: 12px; line-height: 1.55; } +.question-num { color: var(--blue); margin-right: 6px; } +.options { list-style: none; margin: 0; padding: 0; } +.options li { + display: flex; + align-items: flex-start; + gap: 10px; + padding: 10px 14px; + border: 1.5px solid var(--gray-200); + border-radius: 6px; + margin-bottom: 8px; + cursor: pointer; + transition: background .15s, border-color .15s; + font-size: 0.9rem; + line-height: 1.5; +} +.options li:hover { border-color: var(--blue-light); background: #f5f0ff; } +.options li.selected { border-color: var(--blue); background: #f5f0ff; } +.options li.correct { border-color: var(--green); background: var(--green-light); } +.options li.wrong { border-color: var(--red); background: var(--red-light); } +.options li.reveal-correct { border-color: var(--green); background: var(--green-light); } +.opt-letter { + width: 24px; height: 24px; + border-radius: 50%; + background: var(--gray-200); + color: var(--gray-600); + font-size: 0.75rem; + font-weight: 700; + display: flex; align-items: center; justify-content: center; + flex-shrink: 0; +} +li.correct .opt-letter { background: var(--green); color: #fff; } +li.wrong .opt-letter { background: var(--red); color: #fff; } +li.reveal-correct .opt-letter { background: var(--green); color: #fff; } +.feedback { + display: none; + margin-top: 10px; + padding: 10px 14px; + border-radius: 6px; + font-size: 0.85rem; + line-height: 1.5; +} +.feedback.correct-fb { background: var(--green-light); color: #065f46; } +.feedback.wrong-fb { background: var(--red-light); color: #7f1d1d; } +.quiz-submit { + display: inline-flex; + align-items: center; + gap: 8px; + background: var(--blue); + color: var(--white); + border: none; + padding: 11px 24px; + border-radius: 6px; + font-size: 0.9rem; + font-weight: 600; + cursor: pointer; + margin-top: 8px; + transition: background .15s; +} +.quiz-submit:hover { background: var(--blue-light); } +.quiz-submit:disabled { background: var(--gray-400); cursor: not-allowed; } +.quiz-result { + display: none; + margin-top: 20px; + padding: 16px 20px; + border-radius: 8px; + font-weight: 600; +} +.quiz-result.pass { background: var(--green-light); color: #065f46; border-left: 4px solid var(--green); } +.quiz-result.fail { background: var(--red-light); color: #7f1d1d; border-left: 4px solid var(--red); } + +/* ── Navigation Footer ─────────────────────────── */ +.page-nav { + display: flex; + justify-content: space-between; + align-items: center; + margin-top: 40px; + padding-top: 24px; + border-top: 1px solid var(--gray-200); + gap: 12px; +} +.btn-nav { + display: inline-flex; + align-items: center; + gap: 8px; + padding: 10px 20px; + border-radius: 6px; + font-size: 0.88rem; + font-weight: 600; + text-decoration: none; + transition: background .15s; +} +.btn-prev { background: var(--white); color: var(--blue); border: 1.5px solid var(--gray-200); } +.btn-prev:hover { background: var(--gray-100); } +.btn-next { background: var(--blue); color: var(--white); border: 1.5px solid transparent; } +.btn-next:hover { background: var(--blue-light); } + +/* ── Intro / Index Page ────────────────────────── */ +.course-hero { + background: linear-gradient(135deg, var(--navy) 0%, var(--blue) 100%); + border-radius: 12px; + padding: 40px 48px; + color: var(--white); + margin-bottom: 40px; +} +.course-hero h1 { font-size: 2.2rem; margin-bottom: 10px; } +.course-hero p { color: #c8d6e5; max-width: 600px; line-height: 1.7; } +.module-cards { display: grid; grid-template-columns: 1fr 1fr; gap: 16px; margin: 24px 0; } +.module-card { + background: var(--white); + border: 1.5px solid var(--gray-200); + border-radius: 10px; + padding: 20px 24px; + text-decoration: none; + color: var(--gray-800); + transition: border-color .15s, box-shadow .15s; + display: block; +} +.module-card:hover { border-color: var(--blue); box-shadow: 0 4px 12px rgba(26,77,143,.1); } +.module-card .card-num { font-size: 0.72rem; font-weight: 700; color: var(--blue); text-transform: uppercase; letter-spacing: .08em; margin-bottom: 6px; } +.module-card h3 { font-size: 1rem; margin: 0 0 6px; } +.module-card p { font-size: 0.82rem; color: var(--gray-600); margin: 0; } +.module-card .card-meta { font-size: 0.75rem; color: var(--gray-400); margin-top: 10px; } + +/* ── Print ─────────────────────────────────────── */ +@media print { + #sidebar, #topbar, .page-nav, .quiz-submit { display: none; } + #main { margin-left: 0; } + #content { padding: 20px; max-width: 100%; } + .collapsible-body { display: block !important; } +} diff --git a/process/trainings/trainings_requirements_engineering/source/build.py b/process/trainings/trainings_requirements_engineering/source/build.py new file mode 100644 index 0000000000..3e3a3cfd4e --- /dev/null +++ b/process/trainings/trainings_requirements_engineering/source/build.py @@ -0,0 +1,297 @@ +#!/usr/bin/env python3 +# ******************************************************************************* +# Copyright (c) 2026 Contributors to the Eclipse Foundation +# +# See the NOTICE file(s) distributed with this work for additional +# information regarding copyright ownership. +# +# This program and the accompanying materials are made available under the +# terms of the Apache License Version 2.0 which is available at +# https://www.apache.org/licenses/LICENSE-2.0 +# +# SPDX-License-Identifier: Apache-2.0 +# ******************************************************************************* +# AI Disclosure: This file was largely AI-generated. The AI-generated +# portions are made available under CC0-1.0 and not subject to the +# project's license. The human contributor has reviewed and verified +# that the code is correct. +# SPDX-License-Identifier: CC0-1.0 +# Assisted-by: Claude Sonnet 4.6 +# ******************************************************************************* +""" +S-CORE Requirements Engineering Training Portal — Build Script + +Converts trainings_requirements_engineering/source/content/*.md +→ trainings_requirements_engineering/portal/*.html + +Dependencies: + pip install markdown pyyaml jinja2 + (or: pip install -r requirements.txt) + +Usage: + python build.py # rebuild everything + python build.py module-3 # rebuild one page by id + python build.py --list # list all source files +""" + +import os, re, sys, shutil +from pathlib import Path + +# ── Dependency check ───────────────────────────────────────────────────────── +try: + import yaml + import markdown as _mdlib + from jinja2 import Environment, FileSystemLoader + from markupsafe import Markup +except ImportError as e: + sys.exit( + f"\nMissing package: {e}\n" + f"Fix with: pip install markdown pyyaml jinja2\n" + f" or: pip install -r requirements.txt\n" + ) + +# ── Paths ──────────────────────────────────────────────────────────────────── +SRC = Path(__file__).parent.resolve() +CONTENT = SRC / 'content' +ASSETS = SRC / 'assets' +OUT = SRC.parent.parent / '_portals' / 'requirements_engineering' +TMPL = SRC # template.html lives here + +CALLOUT_TYPES = 'definition|example|important|tip' +LETTERS = 'ABCDE' + + +# ── Frontmatter ────────────────────────────────────────────────────────────── + +def parse_frontmatter(text: str) -> tuple: + """Return (frontmatter_dict, body_str). Body starts after closing ---.""" + if not text.startswith('---\n'): + return {}, text + try: + end = text.index('\n---\n', 4) + except ValueError: + return {}, text + fm = yaml.safe_load(text[4:end]) or {} + body = text[end + 5:] + return fm, body + + +# ── Markdown conversion ─────────────────────────────────────────────────────── + +def _md(text: str) -> str: + """Convert a markdown string to an HTML fragment.""" + return _mdlib.markdown( + text.strip(), + extensions=['tables', 'fenced_code'], + ) + + +# ── Custom block substitutions ──────────────────────────────────────────────── + +def _sub_callout(m: re.Match) -> str: + ctype = m.group(1) + label = (m.group(2) or '').strip() + body = m.group(3) + label_html = f'
{label}
\n' if label else '' + return ( + f'
\n' + f'{label_html}' + f'{_md(body)}\n' + f'
' + ) + + +def _sub_collapsible(m: re.Match) -> str: + title = (m.group(1) or '').strip() + inner = _md(m.group(2)) + return ( + f'
\n' + f'
{title}' + f' ▼
\n' + f'
{inner}
\n' + f'
' + ) + + +_RE_CALLOUT = re.compile( + rf'^:::({CALLOUT_TYPES})(?:\s+([^\n]+))?\n(.*?)^:::', + re.M | re.S, +) +_RE_COLLAPSIBLE = re.compile( + r'^:::collapsible(?:\s+([^\n]+))?\n(.*?)^:::', + re.M | re.S, +) +_RE_QUIZ = re.compile( + r'^:::quiz\s+(\S+)\s*\n(.*?)^:::', + re.M | re.S, +) + + +def extract_quiz_block(text: str) -> tuple: + """Remove :::quiz block from body; return (clean_body, quiz_dict | None).""" + m = _RE_QUIZ.search(text) + if not m: + return text.strip(), None + quiz_id = m.group(1) + questions = yaml.safe_load(m.group(2)) or [] + clean = text[:m.start()] + text[m.end():] + return clean.strip(), {'id': quiz_id, 'questions': questions} + + +def convert_body(text: str) -> str: + """Full pipeline: callouts → collapsibles → markdown → HTML.""" + text = _RE_CALLOUT.sub(_sub_callout, text) + text = _RE_COLLAPSIBLE.sub(_sub_collapsible, text) + return _md(text) + + +# ── Quiz HTML generators ────────────────────────────────────────────────────── + +def _question_html(idx: int, q: dict, standalone: bool = False) -> str: + """Render one question block.""" + scenario_html = '' + if standalone and q.get('scenario'): + s = q['scenario'].replace('\n', ' ').strip() + scenario_html = f'
{s}
\n ' + + opts_html = '\n '.join( + f'
  • ' + f'{LETTERS[j]} {o["text"]}
    • ' + for j, o in enumerate(q.get('options', [])) + ) + fb = q.get('feedback', '') + return ( + f'
    \n' + f'

    ' + f'Q{idx}. {scenario_html}{q["q"]}

    \n' + f' \n' + f' \n' + f'
    ' + ) + + +def render_inline_quiz(quiz: dict, pass_mark: int = 67) -> str: + """3-question module check-in quiz section.""" + qs = '\n'.join(_question_html(i, q) for i, q in enumerate(quiz['questions'], 1)) + return ( + f'
    \n' + f'

    Module Check-In

    \n' + f'

    ' + f'Answer all questions and click Submit to check your understanding.

    \n' + f' {qs}\n' + f' \n' + f'
    \n' + f'
    ' + ) + + +def render_checkpoint_questions(questions: list) -> str: + """All question blocks for a standalone checkpoint quiz page.""" + return '\n'.join( + _question_html(i, q, standalone=True) + for i, q in enumerate(questions, 1) + ) + + +# ── Page builder ────────────────────────────────────────────────────────────── + +def build_page(md_path: Path, env: Environment) -> None: + raw = md_path.read_text(encoding='utf-8') + fm, body = parse_frontmatter(raw) + page_id = fm.get('id', md_path.stem) + ptype = fm.get('page_type', 'module') + + # strip keys we pass explicitly to avoid duplicate-keyword errors + _STRIP = {'page_type', 'questions'} + fm_ctx = {k: v for k, v in fm.items() if k not in _STRIP} + + tmpl = env.get_template('template.html') + + if ptype == 'quiz': + questions = fm.get('questions', []) + questions_html = Markup(render_checkpoint_questions(questions)) + html = tmpl.render( + page_type = 'quiz', + questions_html = questions_html, + content = Markup(''), + quiz_html = Markup(''), + quiz_init = '', + **fm_ctx, + ) + + elif ptype == 'index': + content_html = convert_body(body) + html = tmpl.render( + page_type = 'index', + content = Markup(content_html), + quiz_html = Markup(''), + quiz_init = '', + **fm_ctx, + ) + + else: # module + body, quiz = extract_quiz_block(body) + content_html = convert_body(body) + quiz_html = Markup(render_inline_quiz(quiz)) if quiz else Markup('') + quiz_init = '' + if quiz: + pm = fm.get('quiz_pass_mark', 67) + on_pass = fm.get('quiz_on_pass', None) + op_js = f'"{on_pass}"' if on_pass else 'null' + quiz_init = f"initQuiz('{quiz['id']}', {pm}, {op_js});" + + html = tmpl.render( + page_type = 'module', + content = Markup(content_html), + quiz_html = quiz_html, + quiz_init = quiz_init, + **fm_ctx, + ) + + out = OUT / f'{page_id}.html' + out.write_text(html, encoding='utf-8') + print(f' ✓ {page_id}.html') + + +# ── Main ────────────────────────────────────────────────────────────────────── + +def build_all(target_id: str | None = None) -> None: + OUT.mkdir(parents=True, exist_ok=True) + + # copy shared assets + for name in ('style.css', 'app.js'): + src = ASSETS / name + if src.exists(): + shutil.copy2(src, OUT / name) + print(f' → {name} (copied)') + + env = Environment(loader=FileSystemLoader(str(TMPL)), autoescape=False) + files = sorted(CONTENT.glob('*.md')) + + if not files: + sys.exit(f"No .md files found in {CONTENT}") + + built = 0 + for f in files: + pid = f.stem + if target_id and pid != target_id: + continue + build_page(f, env) + built += 1 + + if target_id and built == 0: + sys.exit(f"No file found with id '{target_id}' in {CONTENT}") + + print(f'\nDone — {built} page(s) written to {OUT}') + + +if __name__ == '__main__': + args = sys.argv[1:] + + if '--list' in args: + for f in sorted(CONTENT.glob('*.md')): + fm, _ = parse_frontmatter(f.read_text(encoding='utf-8')) + print(f" {f.stem:20s} {fm.get('title', '—')}") + sys.exit(0) + + build_all(args[0] if args else None) diff --git a/process/trainings/trainings_requirements_engineering/source/content/index.md b/process/trainings/trainings_requirements_engineering/source/content/index.md new file mode 100644 index 0000000000..4cc02397e1 --- /dev/null +++ b/process/trainings/trainings_requirements_engineering/source/content/index.md @@ -0,0 +1,83 @@ +--- +# ******************************************************************************* +# Copyright (c) 2026 Contributors to the Eclipse Foundation +# +# See the NOTICE file(s) distributed with this work for additional +# information regarding copyright ownership. +# +# This program and the accompanying materials are made available under the +# terms of the Apache License Version 2.0 which is available at +# https://www.apache.org/licenses/LICENSE-2.0 +# +# SPDX-License-Identifier: Apache-2.0 +# ******************************************************************************* +# AI Disclosure: This file was largely AI-generated. The AI-generated +# portions are made available under CC0-1.0 and not subject to the +# project's license. The human contributor has reviewed and verified +# that the code is correct. +# SPDX-License-Identifier: CC0-1.0 +# Assisted-by: Claude Sonnet 4.6 +# ******************************************************************************* +id: index +page_type: index +title: "S-CORE Requirements Engineering Training" +breadcrumb: "" +prev: null +next: + url: module-1.html + label: "Module 1: Why Requirements Engineering?" +--- + +# S-CORE Requirements Engineering + +A focused, self-paced training on the **Requirements Engineering** process area +of the Eclipse S-CORE Process Description, covering its concepts, roles, +workflows, work products, and practical application in safety- and +security-critical automotive open-source software development. + +| | | +|---|---| +| Duration | ~3.5 hours | +| Structure | 4 Modules + Checkpoint Quiz | +| Format | Self-paced | +| Standards | ISO 26262 · ASPICE SWE.1 · ISO/SAE 21434 · ISO PAS 8926 | + +## Modules + +| Module | Title | Description | Duration | +|--------|-------|-------------|----------| +| Module 1 | [Why Requirements Engineering?](module-1.html) | Role of RE in safety-critical OSS, stakeholders, roles, and how standards drive the process. | ~30 min | +| Module 2 | [Requirement Levels and Types](module-2.html) | The five requirement levels (Stakeholder, Feature, Component, AoU, Process), types, and their traceability relationships. | ~45 min | +| Module 3 | [Requirement Attributes and Quality](module-3.html) | Mandatory and auto-generated attributes, formulation rules, versioning, and reviews. | ~45 min | +| Module 4 | [Workflows and Work Products](module-4.html) | The six S-CORE workflows, work products with compliance tags, and end-to-end traceability. | ~45 min | + +**[Checkpoint Quiz — All Modules](quiz-1.html)** +10 questions covering all four modules. Pass mark: 70%. Instant scoring with explanations. (~20 min) + +## About This Course + +This training is based on the **Eclipse S-CORE Process Description** — +specifically the Requirements Engineering process area — and the applicable +standards it implements: ISO 26262 (Part 8), ASPICE PAM 4.0 (SWE.1), +ISO/SAE 21434, and ISO PAS 8926. + +It is intended for anyone contributing to or reviewing requirements in an +S-CORE-compliant project: developers, architects, safety managers, security +managers, quality managers, and testers. + +:::tip How to use this portal +Work through the modules in order. Each module ends with a short three-question +check-in. After completing all four modules take the Checkpoint Quiz. +Your progress is saved in your browser — no server required. +::: + +## Learning Objectives + +After completing this training you will be able to: + +- Explain the role of structured requirements engineering in safety- and security-critical automotive software +- Name all stakeholders and identify their information needs in an S-CORE project +- Distinguish the five requirement levels and select the correct one for a given situation +- Write well-formed requirements that satisfy the mandatory attribute set +- Apply S-CORE versioning rules and identify when a version bump is required +- Trace requirements from stakeholder level through code and tests using the S-CORE workflow diff --git a/process/trainings/trainings_requirements_engineering/source/content/module-1.md b/process/trainings/trainings_requirements_engineering/source/content/module-1.md new file mode 100644 index 0000000000..828688ab6c --- /dev/null +++ b/process/trainings/trainings_requirements_engineering/source/content/module-1.md @@ -0,0 +1,166 @@ +--- +# ******************************************************************************* +# Copyright (c) 2026 Contributors to the Eclipse Foundation +# +# See the NOTICE file(s) distributed with this work for additional +# information regarding copyright ownership. +# +# This program and the accompanying materials are made available under the +# terms of the Apache License Version 2.0 which is available at +# https://www.apache.org/licenses/LICENSE-2.0 +# +# SPDX-License-Identifier: Apache-2.0 +# ******************************************************************************* +# AI Disclosure: This file was largely AI-generated. The AI-generated +# portions are made available under CC0-1.0 and not subject to the +# project's license. The human contributor has reviewed and verified +# that the code is correct. +# SPDX-License-Identifier: CC0-1.0 +# Assisted-by: Claude Sonnet 4.6 +# ******************************************************************************* +id: module-1 +title: "Why Requirements Engineering?" +breadcrumb: "Module 1: Why Requirements Engineering?" +day: 1 +module_number: 1 +duration: "~30 min" +standard: Requirements +quiz_pass_mark: 70 +prev: + url: index.html + label: Course Overview +next: + url: module-2.html + label: "Module 2: Requirement Levels and Types" +--- + +# Why Requirements Engineering? + +Requirements engineering is not bureaucracy — it is the foundation that connects +a customer's need to the last line of tested code. In safety- and security-critical +automotive software this chain must be complete, correct, and auditable. +This module explains why, who is involved, and what standards demand. + +## 1.1 The Role of Requirements in Safety-Critical Software + +Modern automotive software controls safety-critical actuators — brakes, steering, +power management — and runs in open-source collaborative environments where dozens of +contributors work across organisational boundaries. Without a structured requirements +process two problems become inevitable: + +1. **No agreed specification** — contributors implement different interpretations + of the same need. +2. **No audit trail** — safety and security auditors cannot verify that every + standard requirement is addressed. + +:::important Why RE is Mandated by Standards +ISO 26262 (Part 8, SWE.1), ASPICE PAM 4.0, ISO/SAE 21434, and ISO PAS 8926 all +iltiyexplicitly require a documented, traceable requirements hierarchy as a precondition +for safety and security releases. Without it, certification is impossible. +::: + +The S-CORE Requirements Engineering process provides a single, standardised answer +to both problems: a hierarchy of requirement levels with defined attributes, +mandatory reviews, and automatic traceability links to code and tests. + +## 1.2 Stakeholders and Their Information Needs + +The requirements hierarchy must satisfy the needs of every stakeholder who will +either write, review, implement, test, or audit requirements. The S-CORE process +identifies the following key stakeholders: + +| Stakeholder | Source ID | Role in S-CORE | What they need from requirements | +|-------------|-----------|---------------|----------------------------------| +| **Project Lead** | `rl__project_lead` | Defines platform specification and content, creates project timeline, tracks project progress | Clear stakeholder requirements as a project description | +| **SW Architect** | `rl__committer` | Breaks down platform specification into features, derives feature/component architecture, allocates requirements to architecture elements, defines AoUs from architecture | Feature requirements and AoUs to drive architecture decisions | +| **Tester** | `rl__committer` | Verifies that the specification is satisfied by the elements under test, considers AoUs for test case specification | Verifiable, testable requirements with traceability to test cases | +| **Safety Architect** | `rl__safety_engineer` | Performs Dependent Failure Analysis, qualitative safety analysis (e.g. FMEA), initiates additional requirements and AoUs to cover failures | Requirements with safety attributes and independence information | +| **Security Architect** | `rl__security_engineer` | Performs Trust Boundary Analysis, Defense in Depth Analysis, qualitative security analysis (TARA) | Requirements with security attributes | +| **Module/Tooling SW Developer** | `rl__delivery_team` | Implements SW according to specification, creates traceability by linking specification to code, considers AoUs of other components, creates AoUs for the component under development | Component requirements with clear acceptance criteria | +| **Feature User** | *(no formal role ID)* | Gets detailed information on the specification of a feature, is informed about boundary conditions (AoUs) | AoUs — boundary conditions they must fulfil when using the SW | +| **Platform SW Developer of the Reference Integration** | `rl__platform_team` | Implements requirements for reference integration | Component and feature requirements | + +:::tip Open Source Working Mode +In S-CORE **any Contributor may write a requirement**, but every requirement must be +approved by a Committer or Project Lead before it is merged. Safety and Security +Managers provide support when their domain is involved. +::: + +## 1.3 Standard Connections + +The S-CORE requirements process implements requirements from multiple standards +simultaneously. Understanding these connections helps prioritise engineering effort. + +| Standard | Relevant Clause | What it requires | +|----------|----------------|-----------------| +| **ISO 26262** | Part 8, SWE.1 | SW requirements specification with safety classification, traceability, and review | +| **ASPICE PAM 4.0** | SWE.1 | Elicitation, documentation, agreement, and traceability of SW requirements | +| **ISO/SAE 21434** | §10.5.1 | Cybersecurity requirements derived from TARA, traceable through development | +| **ISO PAS 8926** | §4.5.2.1 | To Be Defined | + +:::definition Assumptions of Use (AoU) +A special requirement type that defines the **boundary conditions the user of a +software element must fulfil** to ensure safe and secure operation. AoUs are +exportable to integrators so they can include them in their own requirements +management systems. +::: + +## 1.4 Roles and Approval Chains + +The S-CORE process defines clear responsibility for each level of the hierarchy: + +- **Stakeholder requirements and SW-Platform AoU:** Written by Contributor (`rl__contributor`), approved by Project Lead (`rl__project_lead`), supported by Safety Manager (`rl__safety_manager`). +- **Feature requirements and Feature AoU:** Written by Contributor (`rl__contributor`), approved by Project Lead (`rl__project_lead`), supported by Safety Manager (`rl__safety_manager`) and Security Manager (`rl__security_manager`). +- **Component requirements and Component AoU:** Written by Contributor (`rl__contributor`), approved by Committer (`rl__committer`), supported by Safety Manager (`rl__safety_manager`) and Security Manager (`rl__security_manager`). +- **Tool/Process requirements:** Written by Contributor (`rl__contributor`), approved by Committer (`rl__committer`). + +This separation ensures that the level of scrutiny matches the safety and security +implications of the requirement. + +:::collapsible Why does the approval chain differ between Feature and Component level? +Feature requirements describe platform-level integration behaviour and are visible +to all users of the platform — they require Project Lead approval because they +represent agreements between the platform team and its stakeholders. + +Component requirements are implementation-specific and concern only the component +team — Committer approval is sufficient, as Committers are the technical +gatekeepers for their component. +::: + +:::quiz module-1-check + +- q: "Who is responsible for approving Feature Requirements in S-CORE?" + options: + - text: "Contributor" + - text: "Project Lead" + correct: true + - text: "Safety Manager" + - text: "Feature User" + feedback: >- + Correct: B. Feature requirements are written by any Contributor but must be approved + by the Project Lead. Safety and Security Managers provide support but do not approve. + +- q: "Which standard requires SW requirements with a safety classification attribute, traceability, and formal review?" + options: + - text: "ISO/SAE 21434" + - text: "ISO PAS 8926" + - text: "ISO 26262 Part 8 / ASPICE SWE.1" + correct: true + - text: "IEC 61508" + feedback: >- + Correct: C. ISO 26262 Part 8 (in conjunction with ASPICE SWE.1) drives the SW requirements + specification obligations in S-CORE. ISO/SAE 21434 and ISO PAS 8926 add cybersecurity + and ADS-specific requirements on top. + +- q: "An integrator using an S-CORE platform component needs to know the boundary conditions they must satisfy for safe use. Which requirement type addresses this?" + options: + - text: "Stakeholder Requirements" + - text: "Feature Requirements" + - text: "Process Requirements" + - text: "Assumptions of Use (AoU)" + correct: true + feedback: >- + Correct: D. Assumptions of Use (AoUs) define the boundary conditions that the user of a + software element must fulfil. They are exportable so integrators can incorporate them + into their own requirements management systems. +::: diff --git a/process/trainings/trainings_requirements_engineering/source/content/module-2.md b/process/trainings/trainings_requirements_engineering/source/content/module-2.md new file mode 100644 index 0000000000..c596a7ef1e --- /dev/null +++ b/process/trainings/trainings_requirements_engineering/source/content/module-2.md @@ -0,0 +1,250 @@ +--- +# ******************************************************************************* +# Copyright (c) 2026 Contributors to the Eclipse Foundation +# +# See the NOTICE file(s) distributed with this work for additional +# information regarding copyright ownership. +# +# This program and the accompanying materials are made available under the +# terms of the Apache License Version 2.0 which is available at +# https://www.apache.org/licenses/LICENSE-2.0 +# +# SPDX-License-Identifier: Apache-2.0 +# ******************************************************************************* +# AI Disclosure: This file was largely AI-generated. The AI-generated +# portions are made available under CC0-1.0 and not subject to the +# project's license. The human contributor has reviewed and verified +# that the code is correct. +# SPDX-License-Identifier: CC0-1.0 +# Assisted-by: Claude Sonnet 4.6 +# ******************************************************************************* +id: module-2 +title: "Requirement Levels and Types" +breadcrumb: "Module 2: Requirement Levels and Types" +day: 1 +module_number: 2 +duration: "~45 min" +standard: Requirements +quiz_pass_mark: 70 +prev: + url: module-1.html + label: "Module 1: Why Requirements Engineering?" +next: + url: module-3.html + label: "Module 3: Requirement Attributes and Quality" +--- + +# Requirement Levels and Types + +S-CORE defines a five-level requirement hierarchy. Each level has a precise +meaning, a defined audience, a characteristic abstraction, and specific +compliance obligations under ISO 26262, ASPICE, and ISO/SAE 21434. +This module maps the hierarchy and explains when to use each level. + +## 2.1 The S-CORE Requirement Hierarchy + +The following diagram summarises the levels and their derivation relationships: + +``` +Stakeholder Requirements (SW-Platform level) + │ + ▼ +Feature Requirements ←→ Feature AoU + │ + ▼ +Component Requirements ←→ Component AoU + │ + ├── Code (Implemented by) + └── Tests (Verified by) +``` + +Additionally, **Process/Tool Requirements** sit alongside the hierarchy and +describe the tooling and process activities that support it. + +A child requirement is always *derived from* its parent. The derivation link +includes the parent's version number so that stale links are automatically +detected during the docs build. + +## 2.2 Stakeholder Requirements (`wp__requirements_stkh`) + +**Stakeholder Requirements** are defined at the SW-Platform level. They describe +**what the platform needs to contain** from the perspective of the customer +(stakeholder), expressed as technical requirements at the highest level of +abstraction. + +:::important Assumed Technical Safety Requirements +In SEooC (Safety Element out of Context) development — which is the S-CORE model +— Stakeholder Requirements represent the **assumed Technical Safety Requirements**. +The integrator must verify that these assumptions match their vehicle-level +safety goals before using the platform. +::: + +:::example Stakeholder Requirement Example +``` +The platform shall support configuration of applications via files +(e.g. yaml, json). +``` +This describes a platform-level capability without specifying how it is +implemented or which component provides it. +::: + +**Compliance obligations:** ISO 26262 §8 / SWE.1, ISO/SAE 21434 §10.5.1 + +## 2.3 Feature Requirements (`wp__requirements_feat`) + +**Feature Requirements** are derived from Stakeholder Requirements and describe +the behaviour of a feature **at platform integration level**, independent of +which components implement it. + +A "feature" represents a coherent set of requirements that together deliver a +platform-level capability. Feature requirements are the primary input for +architects, testers, and integrators. + +:::example Feature Requirement Example +``` +The feature shall use JSON formatted string according to RFC-8259 for +configuration. +``` +This specifies the format at feature level without naming an implementation component. +::: + +Feature requirements also serve as the basis for integration testing on +platform level. + +**Compliance obligations:** ISO 26262 §8 / SWE.1, ISO/SAE 21434 §10.5.1 + +## 2.4 Component Requirements (`wp__requirements_comp`) + +**Component Requirements** are derived from Feature Requirements and describe +component-specific behaviour. They are implementation-facing: they tell a +developer exactly what a component must do within the context of its feature. + +:::example Component Requirement Example +``` +The component shall provide API calls to read and interpret every field of a +JSON body in C++. +``` +This is unambiguously allocated to a single component and is directly testable +at unit level. +::: + +Component Requirements are the lowest level in the hierarchy and have the most +direct link to code and test artefacts via the auto-generated `implemented_by` +and `verified_by` attributes. + +**Compliance obligations:** ISO 26262 §8 / SWE.1, ISO PAS 8926 §4.5.2.1, +ISO 26262 (analysis appendix), ISO/SAE 21434 §10.5.1 + §10.5.2 + +## 2.5 Assumptions of Use (AoU) + +AoUs can exist at **every level** — SW-Platform, Feature, and Component. They +define the boundary conditions that the *user* of the software element must +fulfil to ensure correct, safe, and secure operation. + +| AoU Level | Work Product ID | Audience | Compliance | +|-----------|----------------|----------|------------| +| SW-Platform AoU | `wp__requirements_sw_platform_aou` | Vehicle integrators using the platform | ISO 26262, ISO/SAE 21434 §10.5.1–2 | +| Feature AoU | `wp__requirements_feat_aou` | Teams integrating the feature into a product | ISO 26262, ISO/SAE 21434 §10.5.1–2 | +| Component AoU | `wp__requirements_comp_aou` | Developers using the component API | ISO 26262, ISO PAS 8926, ISO/SAE 21434 §10.5.1–2 | + +:::example AoU Example +``` +The user shall provide a string as input which is not corrupted due to HW or +QM SW errors. +``` +This AoU tells the caller of the JSON configuration component what quality of +input they must guarantee. +::: + +:::important AoU and the Safety Manual +Feature and Component AoUs feed directly into the **Platform Safety Manual** and +**Module Safety Manual** respectively. These manuals are the exportable artefacts +that document all conditions an integrator must satisfy when deploying S-CORE +components in a safety-relevant context. +::: + +## 2.6 Process and Tool Requirements (`wp__requirements_proc_tool`) + +**Process/Tool Requirements** describe the activities and tooling constraints +that support the development process. They are derived from the process +description and specify what must be done manually versus what must be +automated (tool-supported). + +:::example Process/Tool Requirement Example +``` +It shall be checked that safety requirements (Safety != QM) can only be linked +against safety requirements. +``` +This is a process requirement that drives tool implementation in the +Docs-as-Code build. +::: + +Process Requirements are verified by **reviewing the process description** rather +than by functional testing. + +## 2.7 Requirement Types + +Every requirement — regardless of level — carries a **type** attribute that +determines how it is verified and how it participates in traceability: + +| Type | Definition | Verification method | +|------|-----------|---------------------| +| **Functional** | Describes a behaviour that can be demonstrated by test | Unit test, integration test | +| **Interface** | Defines an API or protocol; does not itself describe a behaviour | Review / analysis | +| **Process** | Describes a process activity or constraint; sub-type of Non-Functional | Review of process description | +| **Non-Functional** | All other quality constraints (performance, capacity, …) | Review / analysis | + +:::important Type Affects Linkage Rules +The `type` attribute controls which architecture and safety linkage rules apply. +For example, safety requirements of type Functional must eventually be linked to +a test that exercises the functional behaviour. A Process requirement linked to a +Functional safety requirement would be flagged as a linkage violation. +::: + +:::collapsible Interface requirements — when are they needed? +Use the **Interface** type when a requirement defines a contract between two +parties (e.g., an API signature, a protocol format, a data format) rather than a +behaviour. Interface requirements are important for safety analysis because they +define the boundaries across which faults can propagate — they often appear as +inputs to DFA (Dependent Failure Analysis) and TARA. +::: + +:::quiz module-2-check + +- q: "A requirement states: 'The feature shall use JSON formatted strings according to RFC-8259 for configuration.' At which requirement level does this belong?" + options: + - text: "Stakeholder Requirements" + - text: "Feature Requirements" + correct: true + - text: "Component Requirements" + - text: "Process Requirements" + feedback: >- + Correct: B. The requirement describes behaviour at feature (platform integration) + level — it specifies the format the feature uses without naming a specific component. + Stakeholder requirements would be even more abstract; component requirements would + name the implementing component and its API. + +- q: "An integrator is building a vehicle product using an S-CORE platform component. They receive a document listing the conditions their application must satisfy to use the component safely. What type of requirement is this?" + options: + - text: "Stakeholder Requirements" + - text: "Process Requirements" + - text: "Assumptions of Use (AoU)" + correct: true + - text: "Functional Requirements" + feedback: >- + Correct: C. Assumptions of Use (AoUs) define boundary conditions for the user + of a software element. They are exportable to integrators precisely so they can + be incorporated into the integrator's own requirements management system. + +- q: "Which requirement type is verified by reviewing the process description rather than by functional test execution?" + options: + - text: "Functional" + - text: "Interface" + - text: "Process" + correct: true + - text: "Non-Functional" + feedback: >- + Correct: C. Process requirements describe activities in the development process + and are verified by reviewing the process description (or checking that tooling + enforces them). They cannot be verified by running a functional test. +::: diff --git a/process/trainings/trainings_requirements_engineering/source/content/module-3.md b/process/trainings/trainings_requirements_engineering/source/content/module-3.md new file mode 100644 index 0000000000..9bf5a98070 --- /dev/null +++ b/process/trainings/trainings_requirements_engineering/source/content/module-3.md @@ -0,0 +1,227 @@ +--- +# ******************************************************************************* +# Copyright (c) 2026 Contributors to the Eclipse Foundation +# +# See the NOTICE file(s) distributed with this work for additional +# information regarding copyright ownership. +# +# This program and the accompanying materials are made available under the +# terms of the Apache License Version 2.0 which is available at +# https://www.apache.org/licenses/LICENSE-2.0 +# +# SPDX-License-Identifier: Apache-2.0 +# ******************************************************************************* +# AI Disclosure: This file was largely AI-generated. The AI-generated +# portions are made available under CC0-1.0 and not subject to the +# project's license. The human contributor has reviewed and verified +# that the code is correct. +# SPDX-License-Identifier: CC0-1.0 +# Assisted-by: Claude Sonnet 4.6 +# ******************************************************************************* +id: module-3 +title: "Requirement Attributes and Quality" +breadcrumb: "Module 3: Requirement Attributes and Quality" +day: 1 +module_number: 3 +duration: "~45 min" +standard: Requirements +quiz_pass_mark: 70 +prev: + url: module-2.html + label: "Module 2: Requirement Levels and Types" +next: + url: module-4.html + label: "Module 4: Workflows and Work Products" +--- + +# Requirement Attributes and Quality + +A requirement without well-defined attributes is not a requirement — it is a +wish. S-CORE mandates a specific attribute set for every requirement and +automates part of its population. This module covers all attributes, versioning +rules, and the formulation principles that make requirements verifiable. + +## 3.1 Manual Attributes + +Every S-CORE requirement must have the following attributes set by the author +before a pull request can be merged: + +| Attribute | Values / Format | Purpose | +|-----------|----------------|---------| +| **Unique ID** | `___` | Stable identifier used for all traceability links | +| **Status** | `valid` \| `invalid` | Only `valid` requirements are accepted in main branch | +| **Title** | Free text, expressive | Human-readable label | +| **Description** | Free text | The actual requirement statement | +| **Version** | Integer (1, 2, 3, …) | Bumped on every *significant* change | +| **Rationale / Linkage** | Free text \| derived_from link | Stakeholder reqs need a rationale; derived reqs link to parent | +| **Safety** | `QM` \| `ASIL_B` | Safety integrity level of this requirement | +| **Security** | Boolean / free text | Whether the requirement has security relevance | +| **Type** | `Functional` \| `Interface` \| `Process` \| `Non-Functional` | Determines verification method and linkage rules | + +:::important No "Draft" Status in Main Branch +S-CORE intentionally has no `draft` status value. A requirement is either +`valid` (merged) or it lives in a pull request / feature branch. This forces +engineers to complete a requirement before integrating it rather than +accumulating technical debt in the form of unfinished requirements. +::: + +## 3.2 The Safety Attribute in Detail + +The `safety` attribute is the cornerstone of ISO 26262 compliance. S-CORE +currently supports two values: + +| Value | Meaning | +|-------|---------| +| `QM` | Quality Management — no ASIL claim; standard software quality processes apply | +| `ASIL_B` | Automotive Safety Integrity Level B — requires ASIL-B process measures, verification rigour, and traceability | + +:::important ASIL Decomposition Is Not Used +S-CORE does not currently apply ASIL decomposition, so ASIL_A, ASIL_C, and +ASIL_D are not required. Only QM and ASIL_B are defined. All safety-relevant +requirements must be classified ASIL_B — a safety-relevant requirement that is +incorrectly marked QM is a safety defect. +::: + +The tooling enforces linkage rules: an ASIL_B requirement may only be linked to +other ASIL_B requirements or to QM requirements with a documented rationale. + +## 3.3 Auto-Generated Attributes + +The Docs-as-Code build populates three attributes automatically, eliminating +manual maintenance overhead and ensuring the attributes are always current: + +| Attribute | How it is populated | Tool | +|-----------|---------------------|------| +| **Derives** | Automatically inserted into the parent requirement when a child requirement references it via `derived_from` | Docs-as-Code | +| **Implemented by** | Source files are scanned for a defined tag containing the requirement ID; matching code locations are linked | Docs-as-Code | +| **Verified by** | Test files are scanned for a defined marker containing the requirement ID; matching test cases are linked | Docs-as-Code | + +:::example How Implemented by Works +A developer adds the following tag in C++ source code: + +```cpp +// [feat__json_config__parse_body] +void ConfigParser::parseBody(const std::string& json) { ... } +``` + +During the docs build, the tool finds this tag, resolves `feat__json_config__parse_body` +to the corresponding feature requirement, and automatically links the source +file and line to the `implemented_by` attribute. +::: + +This automatic population means that the traceability matrix is always +regenerated from the actual code and test artefacts — it cannot be manually +falsified or forgotten. + +## 3.4 Requirement Versioning + +### Significant vs. Non-Significant Changes + +Not every edit to a requirement warrants a version increment. S-CORE defines +precisely which changes are significant: + +| Attribute | Significant change | Non-significant change | +|-----------|-------------------|----------------------| +| **Description** | Functional content change or rewrite affecting meaning | Typo corrections, layout, notes | +| **Safety** | Any change | — | +| **Security** | Any change | — | +| **Type** | Any change | — | + +:::important Version Mismatch Is a Build Error +Child requirements reference their parent requirement with an explicit version number +(e.g., `derived_from: stkh__platform__config_files[version==2]`). If the parent +requirement's version is later bumped, all child derivation links become stale and +the docs build emits a warning that **blocks merging** until the child requirements +are updated. This ensures that a change in a parent requirement always triggers a +review of all its children. +::: + +### Versioning Sets of Requirements + +Individual requirement versioning covers single-requirement changes. For +**baselines** — frozen sets of requirements used as the basis for a release or +for a safety case — S-CORE uses standard version control tagging: a git tag +applied to the repository records the exact state of all requirement files. + +## 3.5 Requirement Quality and Formulation + +A well-written requirement has four properties: + +| Property | Test question | +|----------|--------------| +| **Atomic** | Does the requirement describe exactly one thing? | +| **Verifiable** | Can we write a test or review criterion that definitively confirms conformance? | +| **Unambiguous** | Is there exactly one valid interpretation? | +| **Traceable** | Does the requirement link upward to a parent (or have a rationale) and downward to implementation and test? | + +:::important Notes Are Not Requirements +A note in a requirement (marked as such in the Docs-as-Code tool) is **not part of +the requirement** itself. Notes provide additional explanation or context but +must not contain normative content. Reviewers must check that normative +statements are in the description, not buried in notes. +::: + +## 3.6 Requirement Reviews + +Requirements that cannot be checked automatically require a manual inspection. +The S-CORE process supports two kinds of review: + +1. **Peer review (PR review)** — every requirement passes through a pull request + where Committers (`rl__committer`) and Project Leads (`rl__project_lead`) review it before it is merged to `main`. +2. **Formal inspection** — triggered explicitly when a contributor wants a + thorough review of a set of requirements. Uses a structured inspection + checklist (`gd_chklst__req_inspection`) that may be integrated into requirements/version management tooling. + +:::collapsible What does the inspection checklist cover? +The inspection checklist verifies: + +- Completeness: all mandatory attributes are populated +- Consistency: no contradictions between requirements at the same level +- Feasibility: the requirement can realistically be implemented and tested +- Traceability: every requirement is derived from a parent or has a documented rationale +- Safety/security classification: safety attribute is correct relative to safety analysis +- Formulation quality: atomic, verifiable, unambiguous +::: + +:::quiz module-3-check + +- q: "A developer edits a requirement's description to fix a typo and improve layout, with no change to its functional meaning. Should the version attribute be incremented?" + options: + - text: "Yes — any edit to a requirement must increment the version" + - text: "No — only significant changes (functional content, safety, security, type) trigger a version increment" + correct: true + - text: "Yes — the version must be incremented so child links are re-validated" + - text: "No — versions are only managed by git tags, not per-requirement" + feedback: >- + Correct: B. S-CORE explicitly distinguishes significant changes (content changes, + safety/security/type attribute changes) from non-significant ones (typos, layout, + notes). Only significant changes require a version bump so that child requirement + links are re-validated. + +- q: "Which attribute is automatically populated by the Docs-as-Code build when test files contain a defined marker with the requirement ID?" + options: + - text: "Derives" + - text: "Implemented by" + - text: "Verified by" + correct: true + - text: "Status" + feedback: >- + Correct: C. The build scans test files for a defined marker containing the + requirement ID and automatically links matching test cases to the 'verified_by' + attribute. This makes the traceability matrix always current without manual + maintenance. + +- q: "A requirement is marked safety=QM but a safety analysis has determined it is ASIL_B relevant. What is the consequence?" + options: + - text: "Nothing — QM and ASIL_B requirements can be freely mixed" + - text: "The build will flag a linkage violation and the requirement is a safety defect" + correct: true + - text: "The requirement is automatically upgraded to ASIL_B at build time" + - text: "A note is added to the requirement by the tool" + feedback: >- + Correct: B. An incorrectly classified safety attribute is a safety defect. The + S-CORE tooling enforces linkage rules so that ASIL_B requirements may only be + linked to other ASIL_B requirements (or QM with documented rationale). A wrong + safety attribute would allow a safety-relevant element to be inadequately + verified and could invalidate the safety case. +::: diff --git a/process/trainings/trainings_requirements_engineering/source/content/module-4.md b/process/trainings/trainings_requirements_engineering/source/content/module-4.md new file mode 100644 index 0000000000..4964694b04 --- /dev/null +++ b/process/trainings/trainings_requirements_engineering/source/content/module-4.md @@ -0,0 +1,241 @@ +--- +# ******************************************************************************* +# Copyright (c) 2026 Contributors to the Eclipse Foundation +# +# See the NOTICE file(s) distributed with this work for additional +# information regarding copyright ownership. +# +# This program and the accompanying materials are made available under the +# terms of the Apache License Version 2.0 which is available at +# https://www.apache.org/licenses/LICENSE-2.0 +# +# SPDX-License-Identifier: Apache-2.0 +# ******************************************************************************* +# AI Disclosure: This file was largely AI-generated. The AI-generated +# portions are made available under CC0-1.0 and not subject to the +# project's license. The human contributor has reviewed and verified +# that the code is correct. +# SPDX-License-Identifier: CC0-1.0 +# Assisted-by: Claude Sonnet 4.6 +# ******************************************************************************* +id: module-4 +title: "Workflows and Work Products" +breadcrumb: "Module 4: Workflows and Work Products" +day: 1 +module_number: 4 +duration: "~45 min" +standard: Requirements +quiz_pass_mark: 70 +prev: + url: module-3.html + label: "Module 3: Requirement Attributes and Quality" +next: + url: quiz-1.html + label: "Checkpoint Quiz" +--- + +# 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 + +| Workflow ID | Workflow name | Responsible | Approved by | +|-------------|---------------|-------------|-------------| +| `wf__req_stkh_req` | Create/Maintain Stakeholder Requirements and SW-Platform AoU | Contributor `rl__contributor` | Project Lead `rl__project_lead` | +| `wf__req_feat_req` | Create/Maintain Feature Requirements | Contributor `rl__contributor` | Project Lead `rl__project_lead` | +| `wf__req_feat_aou` | Create/Maintain Feature AoUs | Contributor `rl__contributor` | Project Lead `rl__project_lead` | +| `wf__req_comp_req` | Create/Maintain Component Requirements | Contributor `rl__contributor` | Committer `rl__committer` | +| `wf__req_comp_aou` | Create/Maintain Component AoUs | Contributor `rl__contributor` | Committer `rl__committer` | +| `wf__req_tool` | Create/Maintain Tool/Process Requirements | Contributor `rl__contributor` | Committer `rl__committer` | +| `wf__monitor_verify_requirements` | Monitor/Verify Requirements | Committer `rl__committer` | Committer `rl__committer` | + +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` + +:::example Triggering this workflow +A project lead opens a change request: *"The platform shall support OTA software +updates for individual components."* A contributor writes the stakeholder +requirement and the SW-Platform AoU (the conditions the OEM integrator must +satisfy to use OTA safely). The project lead reviews and approves the PR. +::: + +**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` + +:::important AoU and Architecture Are Coupled +AoUs cannot be written without the architecture work product because AoUs +emerge from the safety concept: once the architecture defines the isolation +boundaries and safety mechanisms, the AoUs state what conditions must hold +*outside* those boundaries for the safety concept to be valid. +::: + +## 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. + +| Work Product | ID | Compliance tags | +|-------------|-----|-----------------| +| Stakeholder Requirements | `wp__requirements_stkh` | ISO 26262 §8/6.5.1, ISO/SAE 21434 §10.5.1 | +| Feature Requirements | `wp__requirements_feat` | ISO 26262 §8/6.5.1, ISO/SAE 21434 §10.5.1 | +| Component Requirements | `wp__requirements_comp` | ISO 26262 §8/6.5.1, ISO PAS 8926 §4.5.2.1, ISO 26262 analysis annex, ISO/SAE 21434 §10.5.1 | +| SW-Platform AoU | `wp__requirements_sw_platform_aou` | ISO 26262 §8/6.5.1, ISO/SAE 21434 §10.5.1–2 | +| Feature AoU | `wp__requirements_feat_aou` | ISO 26262 §8/6.5.1, ISO/SAE 21434 §10.5.1–2 | +| Component AoU | `wp__requirements_comp_aou` | ISO 26262 §8/6.5.1, ISO PAS 8926 §4.5.2.1, ISO/SAE 21434 §10.5.1–2 | +| Process/Tool Requirements | `wp__requirements_proc_tool` | (internal process lifecycle) | +| Requirements Inspection | `wp__requirements_inspect` | ISO 26262 §8/6.5.3 | + +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 +``` + +:::important Traceability Is Automatically Maintained +The `implemented_by` and `verified_by` links are populated automatically by the +Docs-as-Code build. This means **the traceability matrix is always regenerated +from the real artefacts** — it cannot drift from the code. Auditors can trust +that a requirement shown as "verified by test X" genuinely corresponds to a test +that references that requirement ID. +::: + +## 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. + +:::tip Getting Started +The Requirements Engineering concept (`doc_concept__req_process`) and Getting +Started guide (`doc_getstrt__req_process`) describe the exact steps for creating +a new requirement, deriving child requirements, and triggering a formal inspection. +The workflow diagram in the getting started guide maps every step to the +corresponding workflow ID listed in Section 4.1. +::: + +:::collapsible Linking requirements to code and tests — practical steps +1. **Find the requirement ID** in the generated HTML portal or in the RST source. +2. **Add the implementation tag** in the source file as a structured comment: + `// []` (exact syntax depends on the Docs-as-Code version). +3. **Add the verification marker** in the test file using the framework-specific + marker (e.g., a pytest mark or a comment annotation). +4. **Run the docs build** (`bazel run //:docs`). The build will now populate + `implemented_by` and `verified_by` in the HTML output. +5. **Verify coverage** in the generated requirements traceability report. +::: + +:::quiz module-4-check + +- q: "A contributor wants to create new Component Requirements. Which approval chain applies?" + options: + - text: "Written by Safety Manager, approved by Project Lead" + - text: "Written by Contributor, approved by Committer" + correct: true + - text: "Written by Committer, approved by Project Lead" + - text: "Written by Contributor, approved by Safety Manager" + feedback: >- + Correct: B. Component Requirements are created by any Contributor and approved + by a Committer. Project Lead approval is required for Stakeholder and Feature + level requirements; Committer approval is sufficient for Component level because + this is an implementation-specific concern. + +- q: "Feature AoU requirements have an additional input compared to Feature Requirements. What is it?" + options: + - text: "wp__requirements_stkh (Stakeholder Requirements)" + - text: "wp__requirements_comp (Component Requirements)" + - text: "wp__feature_arch (Feature Architecture)" + correct: true + - text: "wp__issue_track_system (Issue Tracker)" + feedback: >- + Correct: C. AoUs at feature level emerge from the safety concept defined in + the Feature Architecture. Without the architecture there is no basis for + determining what boundary conditions must hold outside the software element. + +- q: "An auditor asks: 'How do you guarantee that the traceability matrix between requirements and test cases is up to date?' What is the correct S-CORE answer?" + options: + - text: "The traceability matrix is maintained manually by the Safety Manager and reviewed quarterly" + - text: "Traceability is managed in an external ALM tool which is synced monthly" + - text: "The Docs-as-Code build automatically regenerates the verified_by links from test file markers on every build, so the matrix cannot drift from the actual test artefacts" + correct: true + - text: "Developers are required to update the traceability spreadsheet when they add tests" + feedback: >- + Correct: C. The 'verified_by' attribute is auto-populated by scanning test files + for the requirement ID marker on every build. This means the traceability matrix + is always regenerated from the real artefacts — it is impossible for it to show + a test link that does not exist in the codebase. +::: diff --git a/process/trainings/trainings_requirements_engineering/source/content/quiz-1.md b/process/trainings/trainings_requirements_engineering/source/content/quiz-1.md new file mode 100644 index 0000000000..b0aeff3fb1 --- /dev/null +++ b/process/trainings/trainings_requirements_engineering/source/content/quiz-1.md @@ -0,0 +1,174 @@ +--- +# ******************************************************************************* +# Copyright (c) 2026 Contributors to the Eclipse Foundation +# +# See the NOTICE file(s) distributed with this work for additional +# information regarding copyright ownership. +# +# This program and the accompanying materials are made available under the +# terms of the Apache License Version 2.0 which is available at +# https://www.apache.org/licenses/LICENSE-2.0 +# +# SPDX-License-Identifier: Apache-2.0 +# ******************************************************************************* +# AI Disclosure: This file was largely AI-generated. The AI-generated +# portions are made available under CC0-1.0 and not subject to the +# project's license. The human contributor has reviewed and verified +# that the code is correct. +# SPDX-License-Identifier: CC0-1.0 +# Assisted-by: Claude Sonnet 4.6 +# ******************************************************************************* +id: quiz-1 +page_type: quiz +title: "Requirements Engineering Checkpoint Quiz" +breadcrumb: "Requirements Engineering Checkpoint Quiz" +description: >- + 10 questions covering all four modules — Module 1 through Module 4. + Read each question carefully. Some questions are scenario-based. + Instant scoring with explanations on submission. +stats: + - "📋 10 Questions" + - "⏱ ~20 min" + - "🎯 Pass mark: 70% (7/10)" + - "📖 Covers Modules 1–4" +pass_mark: 70 +certificate_title: "Requirements Engineering Certified" +certificate_desc: "You have successfully passed the S-CORE Requirements Engineering Training." +certificate_name: "S-CORE Requirements Engineering Training — Eclipse Foundation" +prev: + url: module-4.html + label: "Module 4: Workflows and Work Products" +next: null +questions: + + - q: "Why is structured requirements engineering mandated in S-CORE rather than left to individual project discretion?" + options: + - text: "It is required because requirements management tools are already available in the platform." + - text: "ISO 26262, ASPICE SWE.1, ISO/SAE 21434, and ISO PAS 8926 all require a documented, traceable requirements hierarchy as a precondition for certification; without it a safety and security release is not possible." + correct: true + - text: "It is only needed for ASIL_D projects; QM-only projects can skip structured RE." + - text: "Requirements engineering is optional — projects can substitute it with comprehensive test coverage." + feedback: >- + Correct: B. All applicable standards in S-CORE (ISO 26262, ASPICE, ISO/SAE 21434, + ISO PAS 8926) require a documented, traceable requirements hierarchy. There is no + standards-compliant path to certification without it, regardless of test coverage. + + - q: "In S-CORE, any Contributor may write a requirement. Which of the following statements about the approval process is correct?" + options: + - text: "Contributors may directly merge requirements without review if the safety attribute is QM." + - text: "All requirements are approved exclusively by Safety Managers." + - text: "Stakeholder and Feature requirements must be approved by the Project Lead; Component requirements must be approved by a Committer." + correct: true + - text: "Requirements are approved by the Feature User because they are the primary consumer." + feedback: >- + Correct: C. The approval authority depends on the requirement level. Project Lead + approval is required for Stakeholder and Feature level (visible to all platform users); + Committer approval is sufficient for Component level (implementation-specific). Safety + and Security Managers provide support but do not hold the approval role. + + - q: "A requirement states: 'The platform shall support JSON-based configuration.' At which level does this belong, and why?" + options: + - text: "Component Requirements — because it describes a concrete implementation detail." + - text: "Stakeholder Requirements — because it describes a platform-level capability at high abstraction, without specifying how any component implements it." + correct: true + - text: "Feature Requirements — because JSON is a specific technical format." + - text: "Process Requirements — because it describes a process constraint." + feedback: >- + Correct: B. Stakeholder Requirements describe what the platform must contain from + the customer's perspective at the highest abstraction level. This requirement names + a platform capability without specifying which component implements it or how — + that decomposition happens at Feature and Component levels. + + - q: "An S-CORE component is released for integration into a vehicle OEM project. The OEM needs to know the boundary conditions their application must satisfy for the component to behave correctly under safety constraints. Which S-CORE work product delivers this information?" + options: + - text: "wp__requirements_comp (Component Requirements)" + - text: "wp__requirements_feat (Feature Requirements)" + - text: "wp__requirements_comp_aou (Component Assumptions of Use)" + correct: true + - text: "wp__requirements_proc_tool (Process/Tool Requirements)" + feedback: >- + Correct: C. Component Assumptions of Use (AoU) define the boundary conditions the + user of a component must fulfil. They are exported in the Module Safety Manual so + integrators can include them in their own requirements management systems, satisfying + ISO 26262 and ISO/SAE 21434 requirements for SEooC integration. + + - q: "Which values are currently defined for the 'safety' attribute in S-CORE requirements?" + options: + - text: "QM and ASIL_B only, because ASIL decomposition is not used in S-CORE." + correct: true + - text: "ASIL_A, ASIL_B, ASIL_C, and ASIL_D to cover the full ISO 26262 range." + - text: "QM, ASIL_A, and ASIL_B for the subset of ISO 26262 levels used in automotive OSS." + - text: "Safety classification is not an attribute in S-CORE requirements." + feedback: >- + Correct: A. S-CORE currently defines only QM and ASIL_B as valid safety attribute + values. ASIL decomposition is not applied, so ASIL_A, _C, and _D are not needed. + A safety-relevant requirement incorrectly marked QM is a safety defect. + + - q: "A developer edits a Component Requirement by changing its description to fix a typo and rewrites one sentence for clarity — the functional meaning is identical. Must the version attribute be incremented?" + options: + - text: "Yes — any edit to description requires a version bump." + - text: "No — only functional content changes, or changes to the safety, security, or type attribute, are significant and require a version increment." + correct: true + - text: "Yes — otherwise child requirement links become invalid." + - text: "No — version increments are only required for ASIL_B requirements." + feedback: >- + Correct: B. S-CORE distinguishes significant changes (functional content changes; + any change to safety, security, or type attributes) from non-significant changes + (typos, layout, notes). Only significant changes require a version bump and + trigger re-validation of child requirement links. + + - q: "Which of the three auto-generated attributes is populated by scanning source code files for a defined tag containing the requirement ID?" + options: + - text: "Derives" + - text: "Implemented by" + correct: true + - text: "Verified by" + - text: "Status" + feedback: >- + Correct: B. 'Implemented by' is populated by scanning source code files for a + defined tag containing the requirement ID. 'Verified by' comes from test files. + 'Derives' is automatically inserted into parent requirements when a child uses + 'derived_from'. 'Status' is a manual attribute. + + - q: "A contributor wants to create Feature AoU requirements. Compared to a plain Feature Requirements workflow, which additional input is required?" + options: + - text: "wp__requirements_stkh (Stakeholder Requirements)" + - text: "wp__requirements_proc_tool (Process/Tool Requirements)" + - text: "wp__feature_arch (Feature Architecture)" + correct: true + - text: "wp__requirements_inspect (Requirements Inspection)" + feedback: >- + Correct: C. AoUs at Feature level emerge from the safety concept defined in the + Feature Architecture. The architecture defines isolation boundaries and safety + mechanisms; AoUs express the conditions that must hold outside those boundaries. + Without the Feature Architecture there is no basis for writing Feature AoUs. + + - q: "A safety auditor asks how S-CORE ensures that a requirement shown as 'verified by Test_X' in the documentation genuinely corresponds to a test that references that requirement. What is the correct answer?" + options: + - text: "The Safety Manager manually cross-checks the traceability matrix against the test repository each sprint." + - text: "The Docs-as-Code build scans all test files for requirement ID markers on every build and regenerates the 'verified_by' links automatically, so the documentation can never show a test link that does not exist in the codebase." + correct: true + - text: "An external ALM tool is synchronised monthly to keep the traceability matrix current." + - text: "Developers are required to update the traceability spreadsheet whenever a new test is added." + feedback: >- + Correct: B. The 'verified_by' attribute is auto-populated on every docs build by + scanning actual test files. The traceability matrix is therefore always regenerated + from real artefacts — it cannot be manually falsified, forgotten, or allowed to + drift. This is a key argument in the S-CORE safety case for requirements coverage. + + - q: "A new feature is being specified. The correct end-to-end flow in S-CORE is:" + options: + - text: "Write Component Requirements first to anchor implementation, then derive Feature and Stakeholder Requirements bottom-up." + - text: "Write Stakeholder Requirements first, then derive Feature Requirements, then derive Component Requirements top-down, linking each level to its parent with a versioned derived_from reference." + correct: true + - text: "Write Feature Requirements first, then both Stakeholder Requirements and Component Requirements independently." + - text: "Only Stakeholder Requirements and Component Requirements are needed; Feature Requirements are optional in S-CORE." + feedback: >- + Correct: B. S-CORE follows the standards' top-down derivation model. Stakeholder + Requirements describe what the platform must contain; Feature Requirements break this + down to integration level; Component Requirements specify individual component + behaviour. Each level links to its parent using a versioned 'derived_from' + reference. Process Requirements are a separate, parallel concern derived from the + process description, not a step that precedes stakeholder requirements. + +--- diff --git a/process/trainings/trainings_requirements_engineering/source/requirements.txt b/process/trainings/trainings_requirements_engineering/source/requirements.txt new file mode 100644 index 0000000000..fa9e00fa92 --- /dev/null +++ b/process/trainings/trainings_requirements_engineering/source/requirements.txt @@ -0,0 +1,3 @@ +markdown +pyyaml +jinja2 diff --git a/process/trainings/trainings_requirements_engineering/source/template.html b/process/trainings/trainings_requirements_engineering/source/template.html new file mode 100644 index 0000000000..a03f681699 --- /dev/null +++ b/process/trainings/trainings_requirements_engineering/source/template.html @@ -0,0 +1,176 @@ + + + + + + +{{ title }} | S-CORE Process Training + +{% if page_type == 'quiz' %} + +{% endif %} + + + +
    + + +
    + Course Overview + {% if breadcrumb %} + › + {{ breadcrumb }} + {% endif %} +
    + +
    + + {# ════════════════════════════════════════════════════════════════════ + MODULE PAGE + ════════════════════════════════════════════════════════════════════ #} + {% if page_type == 'module' %} + +

    {{ title }}

    +
    + {% if duration %}⏱ {{ duration }}{% endif %} + {% if module_number %}📖 Module {{ module_number }} of 4{% endif %} + {% if standard %}🗂 {{ standard }}{% endif %} +
    + + {{ content }} + {{ quiz_html }} + + {# ════════════════════════════════════════════════════════════════════ + STANDALONE CHECKPOINT QUIZ PAGE + ════════════════════════════════════════════════════════════════════ #} + {% elif page_type == 'quiz' %} + +
    +

    {{ title }}

    +

    {{ description | default('') }}

    +
    + {% for s in (stats | default([])) %}{{ s }}{% endfor %} +
    +
    + +
    + {{ questions_html }} + +
    + +
    +
    🏆
    +

    {{ certificate_title | default('Quiz Complete') }}

    +

    {{ certificate_desc | default('You have successfully passed this quiz.') }}

    +
    {{ certificate_name | default(title) }}
    +

    + Eclipse S-CORE Training Program · +

    +
    +
    + + {# ════════════════════════════════════════════════════════════════════ + INDEX / OVERVIEW PAGE + ════════════════════════════════════════════════════════════════════ #} + {% else %} + + {{ content }} + + {% endif %} + + +
    + {% if prev %} + ← {{ prev.label }} + {% endif %} + {% if next %} + + {{ next.label }} → + + {% endif %} +
    + +
    +
    + + + + + + diff --git a/process/trainings/trainings_templates/content/index.md b/process/trainings/trainings_templates/content/index.md new file mode 100644 index 0000000000..66aa0b3d1b --- /dev/null +++ b/process/trainings/trainings_templates/content/index.md @@ -0,0 +1,73 @@ +--- +# ******************************************************************************* +# Copyright (c) 2026 Contributors to the Eclipse Foundation +# +# See the NOTICE file(s) distributed with this work for additional +# information regarding copyright ownership. +# +# This program and the accompanying materials are made available under the +# terms of the Apache License Version 2.0 which is available at +# https://www.apache.org/licenses/LICENSE-2.0 +# +# SPDX-License-Identifier: Apache-2.0 +# ******************************************************************************* +# AI Disclosure: This file was largely AI-generated. The AI-generated +# portions are made available under CC0-1.0 and not subject to the +# project's license. The human contributor has reviewed and verified +# that the code is correct. +# SPDX-License-Identifier: CC0-1.0 +# Assisted-by: Claude Sonnet 4.6 +# ******************************************************************************* +id: index +page_type: index +title: "[PROCESS AREA] Training" # e.g. "Requirements Engineering Training" +breadcrumb: "" +prev: null +next: + url: module-1.html + label: "Module 1: [First Module Title]" +--- + +# [PROCESS AREA] — Training Overview + +A focused training on the **[PROCESS AREA]** process as defined in the +Eclipse S-CORE Process Description, covering its concepts, roles, workflows, +and work products. + +| | | +|---|---| +| Duration | ~X hours | +| Structure | N Modules + Quiz | +| Format | Self-paced | +| Standards | [e.g. ISO 26262, ASPICE SWE.x, ISO/SAE 21434] | + +## Modules + +| Module | Title | Description | Duration | +|--------|-------|-------------|----------| +| Module 1 | [[Module 1 Title]](module-1.html) | [Short description] | ~XX min | +| Module 2 | [[Module 2 Title]](module-2.html) | [Short description] | ~XX min | +| Module 3 | [[Module 3 Title]](module-3.html) | [Short description] | ~XX min | +| Module 4 | [[Module 4 Title]](module-4.html) | [Short description] | ~XX min | + +**[[Quiz Title]](quiz-1.html)** +[N] questions covering all modules. Pass mark: 70%. Instant scoring with explanations. (~20 min) + +## About This Course + +[Describe what this training is based on, who it is for, and the organizational context.] + +:::tip How to use this portal +Work through the modules in order. After completing all modules take the Checkpoint Quiz. +Your progress is saved in your browser (no server required). +::: + +## Learning Objectives + +After completing this training you will be able to: + +- [Objective 1] +- [Objective 2] +- [Objective 3] +- [Objective 4] +- [Objective 5] diff --git a/process/trainings/trainings_templates/content/module-N.md b/process/trainings/trainings_templates/content/module-N.md new file mode 100644 index 0000000000..a5b105705a --- /dev/null +++ b/process/trainings/trainings_templates/content/module-N.md @@ -0,0 +1,119 @@ +--- +# ******************************************************************************* +# Copyright (c) 2026 Contributors to the Eclipse Foundation +# +# See the NOTICE file(s) distributed with this work for additional +# information regarding copyright ownership. +# +# This program and the accompanying materials are made available under the +# terms of the Apache License Version 2.0 which is available at +# https://www.apache.org/licenses/LICENSE-2.0 +# +# SPDX-License-Identifier: Apache-2.0 +# ******************************************************************************* +# AI Disclosure: This file was largely AI-generated. The AI-generated +# portions are made available under CC0-1.0 and not subject to the +# project's license. The human contributor has reviewed and verified +# that the code is correct. +# SPDX-License-Identifier: CC0-1.0 +# Assisted-by: Claude Sonnet 4.6 +# ******************************************************************************* +id: module-N # replace N with 1, 2, 3, … +title: "[Module Title]" +breadcrumb: "Module N: [Module Title]" +day: 1 +module_number: N # integer, e.g. 1 +duration: "~XX min" +standard: "[ProcessArea]" # short tag displayed in header, e.g. "Requirements" +quiz_pass_mark: 70 +prev: + url: index.html # or module-(N-1).html + label: "Course Overview" # or "Module N-1: [Prev Title]" +next: + url: module-2.html # or quiz-1.html for last module + label: "Module 2: [Next Title]" # or "[Quiz Title]" +--- + +# [Module Title] + +[One-paragraph introduction: what this module covers and why it matters in the +context of the process area and applicable standards.] + +## N.1 [First Section Title] + +[Content paragraph.] + +:::definition [Key Term] +[Definition of the key term, referencing the applicable standard where relevant.] +::: + +[More content paragraphs, tables, lists.] + +## N.2 [Second Section Title] + +[Content paragraph.] + +:::important [Key Point Label] +[The most critical takeaway from this section — keep it to 2-3 sentences.] +::: + +[Tables are useful for comparing concepts:] + +| Concept A | Concept B | Notes | +|-----------|-----------|-------| +| ... | ... | ... | + +## N.3 [Third Section Title] + +[Content paragraph.] + +:::example [Example Label] +[A concrete worked example with a realistic scenario from the automotive/S-CORE context.] +::: + +:::collapsible [Click-to-expand Section Title] +[Detailed background information or extended explanation that is useful but not +essential on the first read.] +::: + +## N.4 [Fourth Section Title] (optional) + +[Additional content if needed.] + +:::tip [Tip Label] +[A practical hint for applying this concept day-to-day.] +::: + + +:::quiz module-N-check + +- q: "[Question 1 text — tests understanding of Section N.1]" + options: + - text: "[Correct answer]" + correct: true + - text: "[Distractor 1]" + - text: "[Distractor 2]" + feedback: >- + Correct: A. [Brief explanation linking back to the module content.] + +- q: "[Question 2 text — tests understanding of Section N.2]" + options: + - text: "[Distractor 1]" + - text: "[Correct answer]" + correct: true + - text: "[Distractor 2]" + feedback: >- + Correct: B. [Brief explanation.] + +- q: "[Question 3 text — scenario-based, covering Section N.3 or N.4]" + options: + - text: "[Distractor 1]" + - text: "[Distractor 2]" + - text: "[Correct answer]" + correct: true + feedback: >- + Correct: C. [Brief explanation.] +::: diff --git a/process/trainings/trainings_templates/content/quiz-N.md b/process/trainings/trainings_templates/content/quiz-N.md new file mode 100644 index 0000000000..34c2546f8d --- /dev/null +++ b/process/trainings/trainings_templates/content/quiz-N.md @@ -0,0 +1,151 @@ +--- +# ******************************************************************************* +# Copyright (c) 2026 Contributors to the Eclipse Foundation +# +# See the NOTICE file(s) distributed with this work for additional +# information regarding copyright ownership. +# +# This program and the accompanying materials are made available under the +# terms of the Apache License Version 2.0 which is available at +# https://www.apache.org/licenses/LICENSE-2.0 +# +# SPDX-License-Identifier: Apache-2.0 +# ******************************************************************************* +# AI Disclosure: This file was largely AI-generated. The AI-generated +# portions are made available under CC0-1.0 and not subject to the +# project's license. The human contributor has reviewed and verified +# that the code is correct. +# SPDX-License-Identifier: CC0-1.0 +# Assisted-by: Claude Sonnet 4.6 +# ******************************************************************************* +id: quiz-N # replace N with 1, 2, … +page_type: quiz +title: "[Process Area] Checkpoint Quiz" +breadcrumb: "[Process Area] Checkpoint Quiz" +description: >- + [N] questions covering all modules. Read each question carefully. + Some questions are scenario-based. Instant scoring with explanations on submission. +stats: + - "📋 [N] Questions" + - "⏱ ~20 min" + - "🎯 Pass mark: 70% ([N*0.7]/[N])" + - "📖 Covers Modules 1–[M]" +pass_mark: 70 +certificate_title: "[Process Area] Certified" +certificate_desc: "You have successfully passed the [Process Area] Training Quiz." +certificate_name: "S-CORE [Process Area] Training — Eclipse Foundation" +prev: + url: module-N.html # last module before this quiz + label: "Module N: [Last Module Title]" +next: null # set to next quiz or null if end of course +questions: + + # ── Question 1: Module 1 topic ────────────────────────────────────── + - q: "[Question testing Module 1 concept]" + options: + - text: "[Correct answer]" + correct: true + - text: "[Distractor 1]" + - text: "[Distractor 2]" + - text: "[Distractor 3]" + feedback: >- + Correct: A. [Full explanation (2-3 sentences) referencing the module content.] + + # ── Question 2: Module 1 topic ────────────────────────────────────── + - q: "[Question testing another Module 1 concept]" + options: + - text: "[Distractor 1]" + - text: "[Distractor 2]" + - text: "[Correct answer]" + correct: true + - text: "[Distractor 3]" + feedback: >- + Correct: C. [Explanation.] + + # ── Question 3: Module 2 topic ────────────────────────────────────── + - q: "[Question testing Module 2 concept]" + options: + - text: "[Distractor 1]" + - text: "[Correct answer]" + correct: true + - text: "[Distractor 2]" + - text: "[Distractor 3]" + feedback: >- + Correct: B. [Explanation.] + + # ── Question 4: Module 2 topic ────────────────────────────────────── + - q: "[Question — scenario-based, Module 2]" + options: + - text: "[Distractor 1]" + - text: "[Distractor 2]" + - text: "[Distractor 3]" + - text: "[Correct answer]" + correct: true + feedback: >- + Correct: D. [Explanation.] + + # ── Question 5: Module 3 topic ────────────────────────────────────── + - q: "[Question testing Module 3 concept]" + options: + - text: "[Correct answer]" + correct: true + - text: "[Distractor 1]" + - text: "[Distractor 2]" + - text: "[Distractor 3]" + feedback: >- + Correct: A. [Explanation.] + + # ── Question 6: Module 3 topic ────────────────────────────────────── + - q: "[Question testing another Module 3 concept]" + options: + - text: "[Distractor 1]" + - text: "[Correct answer]" + correct: true + - text: "[Distractor 2]" + - text: "[Distractor 3]" + feedback: >- + Correct: B. [Explanation.] + + # ── Question 7: Module 4 topic ────────────────────────────────────── + - q: "[Question testing Module 4 concept]" + options: + - text: "[Distractor 1]" + - text: "[Distractor 2]" + - text: "[Correct answer]" + correct: true + - text: "[Distractor 3]" + feedback: >- + Correct: C. [Explanation.] + + # ── Question 8: Module 4 topic ────────────────────────────────────── + - q: "[Question testing another Module 4 concept]" + options: + - text: "[Distractor 1]" + - text: "[Distractor 2]" + - text: "[Distractor 3]" + - text: "[Correct answer]" + correct: true + feedback: >- + Correct: D. [Explanation.] + + # ── Question 9: Cross-module scenario ─────────────────────────────── + - q: "[Scenario-based question spanning multiple modules]" + options: + - text: "[Correct answer]" + correct: true + - text: "[Distractor 1]" + - text: "[Distractor 2]" + - text: "[Distractor 3]" + feedback: >- + Correct: A. [Explanation drawing on multiple modules.] + + # ── Question 10: Cross-module scenario ────────────────────────────── + - q: "[Final integrative scenario question]" + options: + - text: "[Distractor 1]" + - text: "[Correct answer]" + correct: true + - text: "[Distractor 2]" + - text: "[Distractor 3]" + feedback: >- + Correct: B. [Explanation.]