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, and Approved, 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. Later states such as Released exist only if your workflow defines them.

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 Approved 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. Reaching a controlled state can require an electronic signature (depending on how the workflow is configured), and a record in a controlled state is locked against casual edits so it can’t be quietly changed. To revise a controlled requirement you create a new version, preserving exactly what was approved.

A controlled-state lock is not the only kind of lock a record can be under. An explicit freeze and a baseline or release lock are separate mechanisms — see Authoring for the difference.

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.