Lifecycle & states

A requirement doesn’t just exist; it moves through a defined lifecycle. Its state records where it is in that lifecycle, and its workflow governs how it gets from one state to the next. This is what turns a draft into trustworthy, approved evidence.

States

Each requirement sits in a state — for example Draft, In Review, Approved, and Released, with paths for Rejected and Obsolete. The exact set is defined by the workflow your organization configures, so the lifecycle matches your process rather than a fixed one.

Transitions

Movement between states happens through named transitions — Draft to In Review, In Review to Approved, and so on. Transitions are deliberate: a workflow defines which moves are allowed, in what order, and what must be true to take them. You can’t skip from Draft straight to Released if the workflow doesn’t permit it.

Who can move a requirement

Transitions are governed by role. A contributor might submit a requirement for review while only a quality manager can approve it, so the lifecycle enforces separation of responsibilities rather than relying on convention.

Controlled states

Some states are controlled — typically Approved and Released. Reaching a controlled state can require an electronic signature, and records in a controlled state are frozen so they can’t be quietly changed (see Authoring on frozen records). To revise a controlled requirement you create a new version, preserving exactly what was approved.

Rejection and retirement

A requirement that doesn’t pass review can be moved to Rejected and sent back for rework, and one that’s no longer applicable can be made Obsolete. Both are recorded transitions, so even retirement is part of the requirement’s documented history.

Where workflows are configured

The states, transitions, signature requirements, and role rules all come from the workflows defined in Administration. This section describes how a requirement behaves; the Administration section covers how to design that behavior.