Topic · requirement lifecycle

Requirement lifecycle

Gist

Requirement lifecycle is the status a shall is in: draft, review, approved, deprecated, retired, superseded. Proof moves it with proof req status SYS-REQ-010 --to review. A Slack “done” is not that state. BABOK still owns the knowledge area. Jama still authors.

proof req status SYS-REQ-010 --to review

Keep IIBA if you already teach Requirements Life Cycle Management. Keep Jama if you author shalls. Proof will not treat a draft on a merge branch as reviewed.

Request demo Last Slack done vs this record

01 · The silent draft

A merge-ready branch that still says draft.

The YAML landed. The PR is green. The status field still means authoring.

BABOK calls this Requirements Life Cycle Management: trace, maintain, prioritize, approve. That is a knowledge area. Proof's status field is narrower. It is not cosmetic. It changes validation, whether the requirement is active, and whether retire or supersede is even legal.

The motivating miss is mechanical. The branch adds SYS-REQ-501 and SYS-REQ-502. Both stay draft. Implementation matches what the author last typed. Six weeks later a reviewer cannot tell whether the wording was negotiated or guessed. Downstream traces still point at unreviewed text.

The command is deterministic. It does not run a BABOK workshop. It records one hop in the state machine. There is no single-step jump from draft to approved.

proof req status SYS-REQ-501 --to review --by CR-042 --reason "ready for review"
proof workflow check --stage spec --verbose

The first command writes the hop. The second fails the spec stage when a changed .req.yaml on this branch is still draft. A green suite after a silent draft is how the guessed shall shipped.

02 · The exhibit

Same PR. A Slack done, or this record.

The files changed. The status did not. Click the tabs.

The PR

Said two new SYS-REQs, tests pass
Status draft on both files
Merge authoring text is now the baseline

Suite green

This hop

No review status. No --by. No reason. No history entry. The shall is still being written, on main.

No record

The PR

Keep the YAML. Keep the tests. They are not the lifecycle hop.

Keep the files

Proof

Ask did this branch leave a changed shall in draft
Out fail until each hop is recorded

A Slack done is not review

Same PR. A Slack done, or this record. Click the tabs.

Surface	What they do	What Proof does	What we lose
BABOK / IIBA	Teach Requirements Life Cycle Management as five tasks.	Record one hop: `proof req status --to review`. Fail the spec stage when a changed file is still draft.	Not the knowledge area. Keep the course they already run.
Jama / DOORS	Author and store the programme. IBM DOORS stays a mention on Proof vs Jama.	Jama still authors. Proof holds the status so CI can fail when the hop is missing.	Not an ALM. Jama still authors.
Software baseline	A named snapshot of the graph. software baseline.	This URL is the status of one shall, not the snapshot of the set.	Not a second lecture on the baseline.
SRS	The artefact that lists the shalls. software requirements specification.	The hop on each file, not the compiled document.	Not NPR 7150 SRS generation.
Stakeholder requirements	Whether L0 files exist at all. stakeholder requirements.	Status of a shall that already exists. Different command.	Not `stakeholder_requirements_exist`.

The teaching graph is still a draft on a merge branch. Walk draft to review with a reason and a change record. Then approve as a second event, with a role. Collapsing the two hops would lose either the authoring provenance or the reviewer attestation. --force on retire only collapses approved to deprecated to retired. It does not skip draft to review to approved.

id: SYS-REQ-501
status: draft
description: Operators can apply a quota without restarting the gateway

proof req status SYS-REQ-501 --to review --by CR-042 --reason "ready for review"
proof approve SYS-REQ-501 --role reviewer --comment "wording negotiated"
proof workflow check --stage spec --verbose
proof help requirement-lifecycle

Active statuses are draft, review, approved. Terminal statuses are retired and superseded. Do not delete the file when you mean retired. Use proof req retire with a reason. Use proof req supersede when a replacement id exists. Use proof req tombstone only for a never-authored numbering gap.

03 · The honest loss

Proof names the hop. It does not run the workshop.

A review status is not a proof of the Go. Jama still authors.

Proof does not implement BABOK, IIBA, or a Visure lifecycle dashboard. It does not certify that the reviewer in the YAML is a real person. It does not treat approved as proof the code matches the shall. We have not scored this against a frozen BABOK pack. The loss is named, not scored.

changed_requirements_reviewed stays on this URL as the CI floor, not a twin. The snapshot of the set stays on software baseline. The compiled shalls stay on software requirements specification. Jama still authors.

Request demo How the install is bought

04 · Nearby questions

What people type next.

What is a requirement lifecycle? Same question. Same URL.

What is requirements life cycle management? Same cluster. BABOK's name for the knowledge area. Keep the course. This URL is the hop.

Can I jump draft to approved? No. Walk review first, then approve as a second event.

Deprecated vs retired? Deprecated means stop using it soon. Retired means it is no longer active. Do not delete the file.

Superseded vs retired? Supersede when a replacement id exists. Retire when it simply leaves the active set.

What is a software baseline? The snapshot of the graph, not the status of one shall. software baseline.

What is a software requirements specification? The artefact that lists the shalls. SRS.

Is Proof a Jama alternative for lifecycle authoring? No. Jama still authors. Proof vs Jama.