requirements-baselining

Verify the entry criteria checklist first: formal review completed, action items resolved, unique requirement IDs, priorities assigned, and stakeholder sign-off obtained. Then create a baseline record, route it for approval by the product owner, tech lead, PM, and QA lead, and apply a version label such as Version 1.0 approved.

Use the format Version X.Y draft Z for working drafts and Version X.Y approved for baselines. Increment the major version for significant scope changes, the minor version for approved changes within a release, and the draft number for unapproved working copies.

A document is ready when all entry criteria pass: formal review done, all action items closed, TBDs resolved or deferred with rationale, requirements uniquely identified and testable, traceability established, and all sign-off authorities approved. If more than 10% of requirements have open issues, delay baselining.

Yes, but only through a formal change control process. Submit a change request, perform impact analysis, obtain CCB approval, then update the requirements and create a new baseline version such as Version 1.1 approved. The original baseline remains immutable.

Premature baselining produces immediate change requests that undermine the baseline and waste change control overhead on issues that review should have caught. Verify entry criteria rigorously and avoid baselining while requirements remain volatile.