Ngenaire Docs
Log inSign up free

Requirement Baselines

A baseline is a point-in-time snapshot of the requirement set. Baselines are immutable: once captured, the requirements they contain never change, even as the live requirements evolve. They are how you say "this is what we agreed to at SRR" and keep a record you can return to and diff against.

Location: Define → Requirements → Requirement Baselines (/system-definition/requirements/baselines).

What a baseline contains

  • Name — the label you find it by later. By convention, use the review name: SRR, PDR-snapshot, CDR-frozen.
  • Description / notes — optional context: scope, decisions, who attended the review.
  • State — draft, approved, or rejected. Approved baselines carry an approver and approval timestamp.
  • Item count — the number of requirements captured.
  • Module scope (optional) — capture only the requirements in a single module instead of the full set.
  • Parent baseline (optional) — chain baselines so you can trace lineage (PDR was based on what was approved at SRR).

Walkthrough

1. Create a baseline

  1. Click New baseline.
  2. Pick a name (e.g. PDR), an optional description, and an optional module scope.
  3. Optionally select a parent baseline to record lineage.
  4. Click Capture. The snapshot is immediate.

2. View lineage

Open a baseline to see its lineage — the chain of parent baselines it descends from — so you can follow how the set evolved review to review.

3. Diff two baselines

In the comparison panel, pick a From baseline and a To baseline. The diff shows every requirement that was added, changed, or removed, with an inline word diff on the changed fields. A summary at the top counts each change type so the impact is visible at a glance.

4. Run the approve and verify gates

If your project requires explicit approvers, an authorized user runs the approve gate; the page records the approver and timestamp. The verify gate confirms the snapshot against the current set. These gates make a baseline a signed-off artifact suitable for a formal review.

Change control

Baselines underpin change control. After a baseline is captured, proposed edits to its requirements are managed through Engineering Change Requests (ECRs) filed against that baseline — see Engineering Change Requests.

Tips

  • Name baselines after the review, not the date. CDR is easier to find later than 2026-04-12.
  • Use module-scoped baselines for fast-moving subsystems. Lock a stable module independently while the rest churns.
  • Baseline before a large refactor. A pre-change snapshot makes the diff afterward obvious.

Related