Menu
Requirements engineering patterns and workflows for EN 50128 railway software compliance
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Project management and coordination for EN 50128 railway software development
Project management and coordination for EN 50128 railway software development
Software quality assurance techniques and auditing for EN 50128 railway software
Software testing methodologies with coverage analysis for EN 50128 C programs using Unity test framework
Software verification with static analysis and coverage for EN 50128 railway software per Section 6.2
V&V Manager coordination and independent V&V authority for SIL 3-4 EN 50128 projects
| name | en50128-requirements |
| description | Requirements engineering patterns and workflows for EN 50128 railway software compliance |
| license | Proprietary |
| compatibility | opencode |
| metadata | {"standard":"EN 50128:2011","domain":"railway-software","language":"C"} |
This skill provides the REQ agent with authoritative reference data, the SRS generation algorithm, quality rules, traceability rules, and defect remediation logic. Load this skill before performing any REQ activity.
| What you need | Where to find it |
|---|---|
| Phase 2 activities, deliverable paths, completion criteria | activities/phase-2-requirements.yaml |
| Item 6 doc ID, template path, SIL obligations, user_approval flag | activities/deliverables.yaml lines 164–205 |
| Annex C Table C.1 — full deliverable ownership catalogue | DELIVERABLES.md |
| Traceability rules T1–T15 (human-readable) | TRACEABILITY.md |
| Traceability obligations T1–T15 (machine-readable, agent consumption) | activities/traceability.yaml |
| Authority structure, two-track loop, rework path | WORKFLOW.md |
| Independence matrix (REQ = No at all SIL levels) | ORGANIZATION.md |
| §7.2 SRS requirements, Table A.2 techniques, §7.2.4.5 traceability | std/EN50128-2011.md |
| SRS template (primary artifact for item 6) | [PROJECT_ROOT] deliverables/requirements/Software-Requirements-Specification-template.md |
| SAF phase footprint, Hazard Log ownership | tasks/SAFETY_ENGINEERING.md |
| Canonical document paths at runtime | CM query-location |
REQ is the primary agent for Phase 2 only.
| Annex C Item | Document | Owner | Phase |
|---|---|---|---|
| 6 | Software Requirements Specification (SRS) | REQ | 2 |
| 7 | Overall Software Test Specification | TST | 2 |
| 8 | Software Requirements Verification Report | VER | 2 |
user_approval_required: true — user/customer must approve before Track B (VER).ORGANIZATION.md).Follow these 15 steps in order. Do not skip steps.
Invoke CM query-location via task tool with --doc srs. Record the canonical path.
Never proceed with a hard-coded path.
Read .workspace to confirm active project name, SIL level, and base path.
Verify Phase 2 prerequisites (§7.2.2): locate the four system documents:
Load the SRS template from [PROJECT_ROOT] deliverables/requirements/Software-Requirements-Specification-template.md.
Fill the Document Control block (doc ID = DOC-SRS-YYYY-001, version = 0.1 DRAFT).
Fill the Approvals table using project SIL level to determine required signatories:
Extract functional requirements from the System Requirements Specification.
Assign IDs: REQ-FUN-NNN (3-digit zero-padded). Each requirement must include:
description, rationale, acceptance criteria, verification method.
Extract performance requirements. Assign IDs: REQ-PERF-NNN.
Include timing constraints, resource limits, WCET requirements where applicable.
Extract interface requirements. Assign IDs: REQ-INT-NNN.
Specify hardware/software interfaces, protocols, data types (use fixed-width C types:
uint8_t, uint16_t, uint32_t).
Invoke SAF via task tool: request hazard analysis output for Phase 2.
Extract safety requirements from SAF's Hazard Log output. Assign IDs: REQ-SAFE-NNN.
SAF is the hazard authority — do not independently classify or close hazards.
Assign SIL levels to each requirement. Base the assignment on hazard traceability (SAF-provided SIL classification). Document the rationale for each SIL assignment.
Establish backward traceability for each requirement:
R) — include if availableHR) — include; document reason if omittedM) — every requirement MUST have a system req or hazard parent
Format: Traceability: SYS-REQ-NNN [, HAZ-NNN]Apply Table A.2 techniques per SIL level (see Section 6 below). Document in the SRS which technique(s) were applied and where (section reference).
Verify quality attributes for every requirement using the 8-attribute checklist in Section 4 below. Fix any failing requirements before submission.
Verify modal verb usage per resources/shall-should-may.md:
SHALL = mandatory requirementSHOULD = highly recommendedMAY = optionalWILL as a requirement keyword.Write the completed SRS to the canonical path from Step 1. Set version 0.1 DRAFT.
Return the path and a summary (requirement count by type, SIL distribution) to PM.
Every requirement MUST satisfy all 8 attributes:
| Attribute | Criterion |
|---|---|
| Unambiguous | Single interpretation only; no vague terms ("reasonable", "adequate") |
| Testable | Can be verified with an objective, repeatable pass/fail criterion |
| Clear | Understood by a qualified engineer on first reading |
| Correct | Accurately reflects the stated stakeholder or system need |
| Feasible | Technically achievable within project constraints |
| Atomic | States one and only one thing; cannot be split into smaller requirements |
| Necessary | Would be missed if omitted; no gold-plating |
| Implementation-free | Does not prescribe a solution; specifies WHAT not HOW |
Requirement ID format: REQ-[TYPE]-[NNN]
Types: FUN (functional), PERF (performance), INT (interface), SAFE (safety)
Source of truth: activities/traceability.yaml (machine-readable, T1–T15) and TRACEABILITY.md (human-readable diagrams). Summary for REQ:
| SIL | Obligation | What to trace |
|---|---|---|
| 0–1 | R | SW req → system req (include if available) |
| 2 | HR | SW req → system req; document reason if any omitted |
| 3–4 | M | SW req → system req AND/OR hazard; 100% coverage required |
Backward traceability (REQ owns): every software requirement traces to a system
requirement or hazard. Embed in each requirement block: Traceability: SYS-REQ-NNN.
Forward traceability (DES/TST own): requirements → design elements → test cases. REQ does not produce forward traceability links; those are produced by DES and TST.
RTM format: Embedded traceability fields in the SRS are sufficient for SIL 0–3.
For SIL 3–4 projects, PM may request a standalone Requirements Traceability Matrix
(docs/requirements/Requirements-Traceability-Matrix.md). If requested, REQ generates
it as a Markdown table: REQ-ID | Description | SYS-REQ | HAZ | Design | Tests | Code.
EN 50128:2011 Table A.2 — requirements specification techniques:
| # | Technique | Ref | SIL 0 | SIL 1–2 | SIL 3–4 |
|---|---|---|---|---|---|
| 1 | Formal Methods | D.28 | – | R | HR |
| 2 | Modelling | Table A.17 | R | R | HR |
| 3 | Structured Methodology | D.52 | R | R | HR |
| 4 | Decision Tables | D.13 | R | R | HR |
At least one technique SHALL be selected and applied. For SIL 3–4, document which
technique(s) were used and in which SRS section(s) they appear. See std/EN50128-2011.md
§7.2 and Annex D for authoritative technique descriptions.
When PM routes QUA findings to REQ, apply this table:
| Finding Code | Description | Action | Confidence |
|---|---|---|---|
T001 | Document ID format incorrect | Reformat to DOC-SRS-YYYY-001 | HIGH — auto-fix |
T002 | Document Control block missing/incomplete | Insert standard block from template | HIGH — auto-fix |
T003 | Approvals table missing or wrong roles | Replace with SIL-correct approvals (see Step 5) | HIGH — auto-fix |
T004 | Required section absent | Add section heading + TBD marker | HIGH — auto-fix |
Q001 | Requirement ID missing or malformed | Assign next available ID in sequence | HIGH — auto-fix |
Q002 | SIL level not assigned | Add project SIL level with rationale | HIGH — auto-fix |
Q003 | Modal verb missing (no SHALL/SHOULD/MAY) | Rewrite requirement with correct keyword | MEDIUM — flag for review |
Q004 | Verification method absent | Add Test, Review, or Inspection | MEDIUM — flag for review |
C001 | Traceability field missing (SIL 3–4) | Escalate to PM — requires SAF input | LOW — escalate |
C002 | Acceptance criteria not testable | Escalate to PM — requires stakeholder input | LOW — escalate |
Escalation rule: LOW-confidence findings MUST be escalated to PM with a written description of the gap. REQ MUST NOT invent traceability links or acceptance criteria.
Phase 0 system docs (S1–S4)
└─► REQ reads: System Requirements Spec, System Safety Requirements Spec
│
├─► SAF: hazard analysis → REQ-SAFE-xxx safety requirements
│
└─► REQ writes: SRS (item 6)
│
├─► DES reads: SRS → Software Architecture Specification
├─► TST reads: SRS → Overall SW Test Specification (item 7) [TST owns]
└─► VER reads: SRS → Software Requirements Verification Report (item 8) [VER owns]
REQ provides to: DES (forward traceability base), TST (testability requirements), VER (item 6 for verification), VAL (2nd-check on item 6).
REQ receives from: System documents (Phase 0), SAF (Hazard Log, SIL assignments), PM (task assignment, defect routing, user approval confirmation).
REQ does NOT contact: QUA or VER directly. All submissions go through PM.