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

  , …
• 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

EARS Patterns

Choose the pattern that best fits the model behavior:

Examples — Model Concepts to EARS Requirements

Rules

• Write requirements using EARS patterns — pick the pattern that matches the model behavior
• Use block/subsystem names only in

  Rationale

  or provenance notes, not in the requirement

  Summary

• When referencing a numeric value, include the workspace variable name and resolved value:

  VarName (value)

  . If the model uses a literal with no variable, record the numeric literal directly
• Put the WHY in

  Rationale

  , not in the requirement statement
• One subsystem may support zero, one, or several behavioral requirements — don't force a 1:1 mapping

Backend Decision Gate

Choose once at the start, then stay on that path.

.slreqx

.slreqx

.yaml

.yaml

Probe (run via

evaluate_matlab_code

hasSlreq = ~isempty(which('slreq.new'));
if hasSlreq, try, slreq.find(Type="Link"); catch, hasSlreq = false; end, end
disp(hasSlreq)

Workflow

1. Understand the model — use

   model_overview

   and

   model_read

   to understand subsystems, interfaces, control logic.

2. Extract parameters — use

   model_query_params

   /

   model_resolve_params

   for thresholds, gains, sample times that should appear in requirement text. Record both variable names and resolved values.

3. Build a capture table (backend-neutral):

   Id	ParentId	Summary	Description	SourceBlock	Rationale	ASIL	Priority	Keywords

4. Run the backend path (A or B below).

5. Review using the gate below.

Path A — Requirements Toolbox (

.slreqx

)

Use when probe succeeds. For full API patterns see

reference/slreq-patterns.md

model = "CruiseControl";
load_system(model);
rs = slreq.new(model + "_Requirements");

% Add requirements with hierarchy — note behavioral "shall" statements
req = add(rs, Id="REQ_CC_001", ...
    Summary="If throttle command exceeds ThrottleMax (1.0) or falls below ThrottleMin (0.0), then the controller shall clamp the output to the valid range.", ...
    Description="Derived from CruiseControl/ThrottleCmd.");
req.Rationale = "Prevents invalid actuator commands that could damage the throttle body.";
req.Keywords = ["draft","auto-generated","control","safety"];

child = add(req, Id="REQ_CC_002", ...
    Summary="When brake pedal input exceeds BrakeThreshold (0.0), the controller shall disengage cruise control.", ...
    Description="Derived from CruiseControl/BrakeLogic.");
child.Keywords = ["draft","auto-generated","safety","brake"];

% Create traceability links: source=block, dest=requirement → auto Implement
lnk = slreq.createLink(model + "/ThrottleCmd", req);
slreq.createLink(model + "/BrakeLogic", child);

save(rs);
% Save all link sets
linkSets = slreq.find(Type="LinkSet");
for i = 1:numel(linkSets), save(linkSets(i)); end

Link rules:

• Source = model element, destination = requirement → link type is automatically

  Implement

• Prefer subsystem-level links; use block-level only when the requirement is block-specific
• Every model-derived requirement must have at least one traceability link
• The model must be loaded (

  load_system

  ) before creating links with block paths

Path B — Structured YAML fallback

Use when Requirements Toolbox is unavailable. For schema and field rules see

reference/yaml-requirements.md

1. Generate a

   <model>_requirements.yaml

   file from the capture table
2. Set

   status: Draft

   and include

   draft

   in

   keywords

   for every requirement
3. Self-review: all required fields set,

   asil

   /

   status

   /

   priority

   use valid values, IDs sequential,

   derived_from

   references valid IDs or is

   null

4. Validate:

python -c "import yaml, sys; yaml.safe_load(open(sys.argv[1])); print('OK')" path/to/requirements.yaml

Guardrails

.slreqx

VarName (value)

.slreqx

.yaml

load_system

.slreqx

Review Gate

Before finishing, verify (both backends):

• Every requirement has

  Id

  ,

  Summary

  , and

  Description

• Every requirement is marked as DRAFT (via Keywords or status field)
• Summaries use EARS patterns, not block-topology restatements
• Numeric values include parameter name + value where a workspace variable exists
• IDs are stable and sequential; existing IDs preserved on regeneration

slreq path only:

• Model-derived requirements have a traceability link to the source model element
• Link direction is model element → requirement (not reversed)
• Subsystem-level linking preferred over block-level
• Requirement set and all link sets are saved

YAML path only:

• File parses without errors

• asil

  and

  priority

  use valid enum values (or

  Unset

  when unknown)

References

• reference/slreq-patterns.md

  — Requirements Toolbox API cookbook

• reference/yaml-requirements.md

  — Structured YAML schema and field rules

• reference/examples/slreq_from_model.m

  — End-to-end slreq example

• reference/examples/requirements.yaml

  — Structured YAML example