# Requirements Engineering

> How to write and manage ASPICE-compliant requirements. Use this skill when creating stakeholder requirements (STR), system requirements (SYSRS), or software requirements (SWRS). Also use when analyzing requirements for quality (atomicity, testability, ambiguity), establishing bidirectional traceability, writing verification criteria, performing consistency checks, or when you see references to SYS.1, SYS.2, SWE.1, or any requirement-related base practices (BP1-BP8). Especially important for the SWE.1.BP6 cross-link requirement between SWRS, SYSRS, and SYSARCH.

- Skill: `ksmyl/requirements-engineering` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add ksmyl/requirements-engineering`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ksmyl/requirements-engineering/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: ksmyl (https://skillmd.com/u/ksmyl)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ksmyl/requirements-engineering

---


# Requirements Engineering for ASPICE

## Writing Good Requirements

Every requirement must be:

1. **Atomic.** One requirement = one testable statement. "The system shall measure voltage AND current" is two requirements.
2. **Unambiguous.** No subjective terms ("fast," "reliable," "user-friendly"). Use quantified criteria ("within 100ms," "accuracy +/-5%").
3. **Testable.** An independent party can verify it passes or fails. If you can't write a test for it, rewrite it.
4. **Uses "shall."** The keyword "shall" indicates a mandatory requirement. "Should" and "may" indicate recommendations and options.
5. **Has verification criteria.** Every requirement needs a `verification_criteria` attribute explaining HOW it will be verified and what constitutes pass/fail.
6. **Has a verification method.** One of: `test` (dynamic execution), `analysis` (calculation/simulation), `inspection` (review/walkthrough), `demonstration` (operational showcase).

## The SWE.1.BP6 Cross-Link Rule

ASPICE SWE.1.BP6 requires bidirectional traceability between **both:**
- System requirements (SYSRS) -> Software requirements (SWRS).
- System architecture (SYSARCH) -> Software requirements (SWRS).

Doorstop only supports one parent per document, so SWRS has SYSRS as its parent. The SYSARCH link must be added as an explicit cross-link:

```bash
uv run doorstop link SWRS001 SYSRS001     # Parent link
uv run doorstop link SWRS001 SYSARCH001   # Cross-link (SWE.1.BP6)
```

Also set the `allocated_from_sysarch` custom attribute on each SWRS item.

## Detailed References

- For the requirement template, common assessor findings table, and structuring guidance, read `references/requirement-quality.md`.
- For bidirectional traceability details, consistency checking, and verification criteria (WP 17-50) guidance, read `references/traceability-rules.md`.