Requirements

Requirements as governed records.

Every requirement is a versioned, controlled item with its own identity, lifecycle, and state — scored for quality and checked for compliance as you write, not after the fact. And they are the anchor of the thread that ties your whole program together.

TraceUnified Requirements view

The requirement workbench — identity, workflow state, quality and compliance checks, and every field in one controlled record.

What it does

Written under control, measured, and checked.

A requirement is not a row of text. It is a controlled record — and three kinds of governance keep it trustworthy from the first draft.

Lifecycle & states

Draft, review, approved, and beyond — each transition governed by a workflow that decides who can move a requirement, from which state, and what the move requires. A status here means something an auditor can rely on.

Quality scoring as you write

Writing quality and ALCOA+ data-integrity expectations are scored during authoring, so a weak or ambiguous requirement is caught while it is cheap to fix — not discovered downstream.

Compliance checks inline

Framework-specific rules run as you author, so the record is trustworthy by the time it is approved rather than corrected in a scramble before a submission.

Versions & history

Item types and fields give every requirement a consistent shape; versions and history capture every change, so the record’s full evolution is accountable.

On the thread

The anchor everything else connects to.

Requirements are where traceability begins. The quality of the requirement record propagates through everything linked to it.

verified by → Tests

Test cases reference the requirements they prove, so coverage and suspect status stay live.

realized by → Architecture

SysML model elements trace to the requirements they realize, in the same database.

referenced by → Risk

Hazards and FMEA entries link to the requirements they threaten or mitigate.

Derive with AI

Turn requirements into the rest of the thread.

Point the governed derivation engine at a set of requirements and it proposes the downstream work products they imply — grounded, cited, and yours to accept. Nothing is written until you do.

RequirementsTestsRequirementsArchitectureRequirementsActors
See how derivation is governed →

Start with requirements you can trust.

Author them under control, measure them as you write, and let the rest of your program trace back to them.