How do I install the Requirements Engineering skill?

Run npx skillmds@latest add ksmyl/requirements-engineering in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Requirements Engineering safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Requirements Engineering?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Requirements Engineering free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Requirements Engineering?

ksmyl (@ksmyl) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Requirements Engineering by ksmyl — Agent Skill

Name: Requirements Engineering
Author: ksmyl

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.

ksmyl b249532 3 files · 5.8 KB Updated Sep 17, 2026

File contents

Requirements Engineering for ASPICE

Writing Good Requirements

Every requirement must be:

Atomic. One requirement = one testable statement. "The system shall measure voltage AND current" is two requirements.
Unambiguous. No subjective terms ("fast," "reliable," "user-friendly"). Use quantified criteria ("within 100ms," "accuracy +/-5%").
Testable. An independent party can verify it passes or fails. If you can't write a test for it, rewrite it.
Uses "shall." The keyword "shall" indicates a mandatory requirement. "Should" and "may" indicate recommendations and options.
Has verification criteria. Every requirement needs a verification_criteria attribute explaining HOW it will be verified and what constitutes pass/fail.
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:

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.

---name: requirements-engineeringdescription: 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.---# Requirements Engineering for ASPICE## Writing Good RequirementsEvery 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 RuleASPICE 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:```bashuv run doorstop link SWRS001 SYSRS001 # Parent linkuv 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`.

Frequently asked questions