| name | aspice-requirements-analysis |
| description | Full SWE.1 requirements engineering workflow for ASPICE 4.0 CL2 automotive embedded software. Use when performing requirements elicitation, writing or reviewing an SRS, classifying requirements by ASIL level, ensuring SMART criteria, building traceability to SYS-REQ and tests, or preparing requirements for SWE.1 milestone review. Guides from raw feature description to APPROVED SRS with complete traceability table. |
| argument-hint | Feature, module, or SRS document to analyse (e.g., 'Exterior Lighting Control' or paste existing requirement text) |
| user-invocable | true |
ASPICE Requirements Analysis Skill (SWE.1)
When to Use
- Starting a new software feature or module and need to write requirements from scratch
- Reviewing an existing SRS for ASPICE CL2 and ISO 26262 compliance
- Deriving
SWE-REQ-XXXX IDs from SYS-REQ-YYYY system requirements
- Classifying requirements by ASIL level and adding safety mechanism annotations
- Preparing the SRS for milestone review and approval
- Auditing requirements for SMART criteria compliance
Workflow
Phase 1 — Elicitation and Context Setup
-
Ask for (or extract from input):
- Module/feature name and purpose
- ECU domain (Body/Lighting, General, etc.)
- Available
SYS-REQ-YYYY inputs (or confirm originating SW requirements)
- Platform (AUTOSAR Classic / Adaptive / bare-metal)
- Target ASIL level (QM / A / B)
-
Set up the SRS status header:
Document/File ID : SRS-<PROJECT>-v0.1
Status : DRAFT
ASIL : <highest ASIL in document>
Phase 2 — Requirements Elicitation
For each feature or function, derive requirements using this structure:
- One behaviour per requirement — split compound statements
- Measurable criterion — replace qualitative words with numeric values
- ASIL assignment — tag every requirement:
@ASIL: QM | A | B
- Safety mechanism (ASIL A/B) — tag:
@Safety-Mechanism: <type>
- Derivation — tag:
← SYS-REQ-YYYY or N/A
Apply the SMART checklist to every requirement before recording it.
Phase 3 — Requirement Classification
Group requirements into four types:
| Type | Criteria |
|---|
| Functional | Observable system behaviour, input → output relationships |
| Non-Functional | Timing, memory, CPU, availability — must have numeric constraints |
| Safety | Freedom-from-interference, FTTI, safety mechanisms — ASIL A/B |
| Interface | Signal names, data types, bus protocols, port connections |
Phase 4 — Quality Gate: SMART Validation
For each requirement, check all five SMART criteria.
Flag failures with ⚠️ SMART-FAIL: <criterion> — <reason> and provide a corrected version.
Phase 5 — Traceability Matrix Construction
Build the traceability table:
| SYS-REQ-ID | SWE-REQ-ID | Type | ASIL | Verified By (TBD) |
|---|
| SYS-REQ-0015 | SWE-REQ-0042 | Functional | A | TBD |
Flag:
⚠️ ORPHAN SYS-REQ: SYS-REQ-YYYY not derived by any SWE-REQ — architecture gap⚠️ ORIGINATING: SWE-REQ-XXXX has no SYS-REQ parent — mark with N/A if intentional
Phase 6 — SRS Document Assembly
Assemble the full SRS following the structure from swe1-requirements-analysis.instructions.md:
- CL2 status header
- Scope and system context
- Definitions and abbreviations
- Functional requirements (SWE-REQ-XXXX blocks)
- Non-functional requirements
- External interface requirements
- Traceability matrix
- Blank review record table
Phase 7 — Self-Review Before Handover
Run a final quality check:
Report the check results and any open findings before handing over the SRS.
Output Artefacts Produced
SRS-<PROJECT>-v0.1 document (DRAFT status, ready for human review)- SMART compliance annotation per requirement
- Traceability matrix (
SYS-REQ → SWE-REQ)
- List of open findings requiring human resolution
References
