Requirements

Every requirement in traceunified is a controlled record with its own identity, lifecycle, and state — checked for writing quality on demand and verified against your organization’s compliance rules. Requirements are the anchor of the thread: tests verify them, risks reference them, and architecture realizes them.

This section covers authoring requirements, the item types and fields that structure them, how they’re versioned, and the governance — lifecycle, quality, and compliance — that keeps them trustworthy.

Requirements as controlled records, with quality and compliance checks

A requirement in traceunified is not a row of text — it’s a controlled record with its own identity, lifecycle, and state, checked for writing quality when you run the quality checks and verified against your organization’s compliance rules, rather than in a cleanup pass before an audit. Catching a weak or ambiguous requirement early is far cheaper than discovering it downstream, and seeing the compliance result on the record means gaps are visible before it’s approved, not merely corrected later.

The anchor of the thread

Requirements are where traceability begins. Tests verify them, risks reference them, and architecture realizes them — so the quality of the requirement record propagates through everything connected to it. That central position is why the structure matters: item types and fields give each requirement a consistent shape, and versions and history capture every change so the record’s evolution is fully accountable.

Lifecycle, quality, and compliance built in

Three kinds of governance keep requirements trustworthy. Lifecycle states move a requirement through draft, review, approved, and any later states your workflow defines under controlled transitions. Quality scoring evaluates wording against EARS, INCOSE, and IEEE 29148 language rules when you run the checks. Compliance checks apply the verification rules your organization configures. Together they mean a requirement isn’t just written — it’s written under control, measured, and checked, which is what lets the rest of the thread depend on it.

What’s in this section

• Authoring requirements — creating and editing under control
• Item types & fields — the structure of a requirement
• Versions & history — every change, captured
• Lifecycle & states — draft, review, approved, and beyond
• Quality scoring — EARS, INCOSE, and IEEE 29148 language checks
• Compliance checks — org-configured verification rules
• Author a requirement — a step-by-step walkthrough from draft to clean quality and compliance