Engineering Change Requests
An Engineering Change Request (ECR) is a structured proposal to modify requirements after a baseline has been captured. ECRs are how change is managed against an approved baseline: every proposed edit goes through review before it lands.
Location: Define → Requirements → Engineering Change Requests (
/system-definition/requirements/change-requests).
What an ECR contains
- Code — auto-assigned identifier (e.g.
ECR-0007). - Title — short description of the change.
- Rationale — the "why": drivers, risks, alternatives considered.
- Baseline — the baseline this change is filed against.
- Proposed changes — one entry per affected requirement, with the new field values.
- Approval stages — ordered review steps, each with its own outcome (optional; for staged review).
- State — see the workflow below.
The ECR workflow
draft → submit → begin review → approve → apply
↘ reject
| State | Meaning |
|---|---|
| Draft | Author is still editing; reviewers can't see it yet. |
| Submitted | Author has handed it off (submit); review hasn't started. |
| Under review | Review has started (begin review) and any approval stages are in progress. |
| Approved | The change is authorized but not yet merged into the requirements. |
| Rejected | A reviewer rejected the ECR; it does not become Applied. |
| Applied | The proposed changes are now live on the affected requirements. |
A rejected ECR can be revised and re-submitted, but its trail (who rejected, when, why) is preserved.
Staged approval
Approval can be staged: an ECR may carry ordered review stages, each with its own approve / reject gate. Stages execute in sequence — a later stage can't approve until the earlier one has — and each stage records its approver, timestamp, and any comment. This lets you model, for example, a Technical Review stage followed by a Change Control Board stage.
Walkthrough
1. Create the ECR
- Click New ECR.
- Pick the baseline the change is filed against.
- Add a title and rationale.
- Add one or more proposed changes — pick a requirement, choose the change type (modify / add / remove), and fill in the new field values.
2. Submit and begin review
Click Submit when the draft is ready, then Begin review to open the approval gates to reviewers.
3. Approve or reject
Each reviewer (or each stage's approver) clicks Approve with an optional comment, or Reject with a reason. Staged ECRs advance stage by stage.
4. Apply the change
Once approved, an authorized user clicks Apply. The proposed field values are merged into the live requirements and the ECR moves to Applied. The originating baseline is unchanged — it remains the historical record.
Permissions
In projects that use strict-approver mode, the right to approve is held only by designated approvers rather than every editor — so the people who can write requirements and the people who can sign off a change can be kept separate. See Roles and permissions.
Tips
- Keep ECRs small. One coherent change per ECR is easier to review than a sweep of unrelated edits.
- Write the rationale once. A few sentences explaining why the change is necessary saves every reviewer from reconstructing the context.
- Don't delete rejected ECRs. A rejection with a reason is a useful record of why a change idea didn't happen.