ASPICE v4.0 Stakeholder Requirements for reqmd

ASPICE BP2 of each requirements analysis process requires structuring requirements. reqmd supports this via directory-based document grouping, configurable ID prefixes in x-reqmd.id-prefix, and dynamic requirement level discovery from the first heading with an attr block. Requirements can be organized hierarchically into documents (directories) and sub-requirements via heading level nesting.

ASPICE BP1 of each requirements analysis process requires specifying requirements according to defined characteristics. reqmd's JSON Schema 2020-12 validation enforces required fields, allowed values (enums), types, and additional property constraints per document directory.

ASPICE requires structuring requirements in a hierarchy. reqmd's dynamic reqLevel discovery lets authors use any heading level (#, ##, ###) for requirements. A heading at reqLevel + 1 with an attr block becomes a child of the preceding reqLevel requirement, with automatic ParentID assignment and graph edge creation.

Multiple ASPICE base practices across SYS, SWE, and HWE require bidirectional traceability between successive refinement levels. reqmd's trace attribute supports upstream-only trace declarations, with the graph builder automatically computing bidirectional (inbound/outbound) relationships. Cross-document trace resolution uses absolute path lookups through x-reqmd.upstream.sources.

ASPICE traceability BPs require consistency checking of trace relationships. reqmd's graph checker performs 10 distinct checks: broken reference (WARNING), circular dependencies (ERROR), untraced requirements (WARNING — suppressed for V-model top boundary, external:true, disposition:set, and sub-requirements), no-downstream (WARNING — suppressed for V-model bottom boundary and disposition:set), disposition without reason (WARNING), mandatory disposition (ERROR), ID prefix mismatch (ERROR), ID prefix collision (ERROR), duplicate requirement ID (ERROR), and ambiguous trace reference (ERROR).

ASPICE verification processes require bidirectional traceability between requirements and verification measures (BP4), specification and selection of verification measures with sufficient coverage (BP1/BP2), and recording of verification results including pass/fail status with evaluation (BP3). reqmd's V-model document chain supports requirements tracing to verification measures (requirements with a verify attribute). The --results flag loads ephemeral verification results from CTRF JSON reports (automated tests) and manual-results markdown (review/inspection/analysis), synthesizes result pseudo-requirements that trace to their measures, and runs outcome-gated checks: missing-verdict (approved measure with no result, WARNING), failing-verdict (latest result is fail, ERROR), and version-pin (stale result pin via ~N, reused from the existing check). Results are not persisted in the spec repo — they are loaded per invocation to keep CI run-to-run churn out of git.

ASPICE SUP.10 requires traceability between change requests and affected work products. reqmd's built-in version attribute tracks version changes at the individual requirement level. The disposition and disposition-reason attributes document the resolution state. Change request IDs can be referenced via the trace attribute to establish explicit links.

ASPICE SUP.1 requires quality assurance of work products and resolution of non-conformances. reqmd's validation pipeline (parse → schema validate → graph build → trace check) produces structured results with severity levels (ERROR, WARNING, INFO). The --json flag outputs machine-readable reports suitable for CI integration. Exit codes distinguish success (0), validation errors (1), and parse errors (2).

ASPICE requires communicating requirements status (SYS.1.BP4), verification results (SYS.5.BP5, SWE.6.BP5, VAL.1.BP5), and configuration status (SUP.8.BP6) to affected parties. reqmd's HTML export generates self-contained documentation with: card-based requirement layout showing all attributes, a tree TOC sidebar with scroll-spy navigation, trace chain tab strip showing the V-model hierarchy, dark mode toggle, and search/filter toolbar.

ASPICE REU.2 requires selection and provision of reusable products. reqmd supports this through the external: true flag on document directories, which marks requirements as external references. External requirements participate in the graph for trace validation (they can be traced to/from) but are exempt from certain checks (untraced suppression). The ASPICE v4.0 base practices (00-aspice/) are themselves expressed as external reqmd requirements, demonstrating this pattern.

ASPICE requires communicating agreed requirements and impact analysis to affected parties across all engineering domains. reqmd's HTML export generates self-contained .html files with inline CSS and JS — no server or network dependencies. The doc-level trace chain tab strip visually communicates the V-model context. The tree TOC sidebar with scroll-spy provides navigation. CSV export enables spreadsheet-based distribution for non-technical stakeholders.

ASPICE requires selection of verification measures with sufficient coverage at each V-model level. reqmd's multi-level document structure (stakeholder → system → software → tests) mirrors the V-model directly. Each document directory has its own schema, ID prefix, and upstream trace target. The HTML export's trace chain tab strip renders the V-model chain (e.g., Stakeholder → System → Software → Tests) with the active document highlighted as an inactive span, providing visual context for the current level.