AI Requirements Generation (ReqGen)
Video transcript
00:04 — Two ways to start
Requirements begin one of two ways. Generate with AI drafts the entire document from a single prompt — every applicable category of the V-model in one pass. Or build it yourself, from a blank document or a CSV import, with the agent on call to interview you and draft, category by category. Either way you end up with the same structured, change-controlled document.
00:36 — A complete, categorised document
Here is a generated document. Requirements come out grouped by category — functional, power, safety, thermal, EMC, environmental and more — and every one carries a stable, traceable ID from the moment it is written, checked against design-input standards. A day of writing becomes a ninety-second draft that a reviewer refines.
01:07 — Refine, under change control
Refine it however you like — edit inline, add from the category cards, or set Document Info, the purpose and scope every export carries. And every document is change-controlled: branch a follow-on to explore a change, and every save is a revision you can compare — the diff panel shows exactly what was added, removed or edited, line by line.
01:35 — The agent, pinned to your document
And the agent is always on call, pinned to whatever document you have open. Ask it to interview you, draft requirements, or trace them up to their parents. It batches its changes into a follow-on you review in the diff panel and merge — never a silent edit. Requirements you can trust, from the first line to the last.
What it does
Given a hierarchy node and a short natural-language prompt, ReqGen produces a structured set of requirements aligned to the node's level (system, subsystem, assembly, subassembly, component or part on a new system, which uses the NASA product breakdown; older systems keep their five levels, system to subassembly), grouped into more than 40 categories (functional, safety, EMC, thermal, security, etc.).
Requirements are grouped by category and carry stable IDs (SYS-AQF-FR-001) from the moment they are drafted, so traceability links survive every later edit.
Why it matters
A typical engineer spends 8–12 hours producing the first-pass requirements set for a new subsystem. ReqGen does it in 90 seconds, with category coverage that exceeds what most engineers produce manually.
How it works
- Pick a hierarchy node (e.g., Battery Management Subsystem under EV Powertrain).
- Type a short prompt: "Lithium-ion BMS for 400V automotive pack, ASIL-D."
- Choose categories (defaults are level-aware). A category you choose is generated even when it is not one of the level's defaults, such as power requirements on a sub-assembly.
- ReqGen calls the LLM with a level- and category-composed template, returns a structured JSON document.
- Engineers review, comment, and iterate — every change tracked.
Key capabilities
- Per-category granularity: 30+ category modules including ASIL-driven safety, EMC, biocompatibility, sterilization (medical), automotive EMC.
- Hierarchy-aware: Inherited context from parent nodes flows in automatically.
- Derive from any artifact: Generate from an ICD, a block diagram, a risk register or any other artifact on the hierarchy; the requirements record what they were derived from.
- Follow-ons with marked changes: ask for changes in a follow-on, see what it added and modified (marked in colour), and merge it when it is right.
- Flow down the hierarchy: from the System Hierarchy page, a cascade generates requirements down a system's nodes. Cascades are metered on their own: 5 a day on Free and Professional, 10 on Team, 25 on Enterprise.
- Review-first workflow: Submit for review, route to assigned reviewers, accept/reject per comment.
Requirement quality checks
Generating requirements quickly is only useful if they are good requirements, so every requirement is linted against deterministic quality checks drawn from AS9100 8.3.3 (design inputs must be complete, unambiguous and non-conflicting) and DO-178C review objectives:
- missing acceptance criteria (the requirement is unverifiable as written)
- missing verification method
- placeholder text left behind (TBD / TODO / ???)
- vague or subjective wording
- exact duplicates of another requirement
Findings are severity-calibrated by how certain the defect is. Clear-cut defects are blocking — they surface as review comments, and open critical or major comments prevent baselining. Heuristic nudges are advisory, so a reviewer can accept them and move on. The checks are deterministic rather than model-driven, so the same text always produces the same result — which is what makes them defensible in an audit.
Traceability
Requirement IDs are unique on their node. A second requirements document on the same node continues the numbering after the first (SUB-ELE-FR-006 after SUB-ELE-FR-005), and a requirement added later takes the next free number on the node, so an ID always names one requirement.
The trace matrix keeps one row per requirement. A requirement added in a merge gets a row of its own, and a deleted one takes its row with it.
Requirements carry typed traceability links to their parents, children and related artifacts. Links created by AI generation are reconciled into a single authoritative link store alongside links you create by hand or import, so the coverage views — VCRM, validation matrix, cross-level traceability — reflect one consistent picture rather than three partial ones.
Usage limits
Generation is metered per tool, per plan:
| Plan | Limit |
|---|---|
| Free | 10 per day, the same as Professional. Free work must sit on a hierarchy node |
| Professional | 10 per day |
| Team | 25 per day |
| Enterprise | 100 per day |
Free-plan artifacts are public. Setting an artifact private requires a paid plan. Editing, reviewing and exporting are not metered — only AI generation is.