Generate Requirement Drafts

Generate draft requirements from Simulink models using the richest artifact the environment supports. All outputs are drafts requiring human review and approval before baselining.

When to Use

• Drafting or updating requirements from a Simulink model
• Creating .slreqx or .yaml requirements artifacts
• Establishing model-to-requirement traceability

When NOT to Use

• Importing requirements from an existing source of truth (ReqIF, DOORS, Word, Excel), use Requirements Toolbox import APIs directly
• Writing or running tests, use the testing-simulink-models skill
• Free-form prose notes with no saved artifact
• User explicitly wants a different text format (markdown, Word)

Output Conventions

• Default file names: <Model>_Requirements.slreqx or <model>_requirements.yaml
• Stable IDs: REQ_<SYSTEM>_001, REQ_<SYSTEM>_002, …, use one consistent project-wide prefix with sequential integers across all requirements, even when they derive from different subsystems. Do not switch to per-subsystem prefixes or hierarchical decimal numbering (e.g. CB-1.1, TP-1.1).
• Follow repo conventions if .slreqx or .yaml files already exist
• When updating an existing artifact, preserve existing IDs, append new IDs, never renumber
• Every generated requirement must be marked as draft, use "draft" in Keywords (slreq) or status: Draft + keywords: [draft] (YAML)

Writing Good Requirements

Requirements must express behavioral intent (WHAT the system shall do), not restate model topology (HOW it is implemented). Put the WHY in Rationale. Use EARS (Easy Approach to Requirements Syntax) patterns:

EARS Patterns

Choose the pattern that best fits the model behavior: