Requirements Governance: Who Approves What, and When

Nine items on a status ladder, four approval gates and ten logged changes replayed against a change policy. Reviewed is a rung below approved.

Numbers in this note carry source tags ([POLICY], [THREADS n=10], [MINE]). What the tags mean.

This piece uses the returns case published on this site: damaged-delivery refunds at a mid-size online retailer, built only from public sources, namely a published returns policy [POLICY], help centre articles [HELP], ten public complaint threads I selected myself [THREADS n=10], consumer law [LAW] and a walk through the published customer journey [WALKTHROUGH]. No client, no engagement, no interview. The case has three dated versions and two review sessions, so it has a real change history to test against.

Requirements governance is the set of written rules that say, for each kind of change to a requirement, whose approval makes it count, at which event that approval is due, and what happens if it never comes.

The RACI piece covered who approves, one rule at a time. This one covers when, and for which kind of change.

In short

• Governance needs a status for every item, not only for the document. The case says "Reviewed". Inside it, nine requirements and rules each sit on their own rung, most held there by a named open question.
• "When" is a list of events more than dates. The case's open questions give four gates: a decision date, the baseline, build start and the first week of access. Each has a written fallback.
• The case records ten changes between v1.0 and v1.2. Replayed against a change policy, three needed only the author. Seven needed someone with authority, and none of the seven has that yes.
• Peer review and approval are different steps. Two peers with no access to the retailer read the case, which is why its status stops at "Reviewed" and the register has never been baselined.

Why is a RACI matrix not enough?

A RACI says whose yes counts on a row. It does not say when that yes is due, whether a later edit cancels it, or which edits are small enough to skip it. Without those answers, every change goes back to everyone, or no change goes back to anyone.

Wikipedia's article on requirements management describes it as "documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders". Governance is the agreeing and the controlling of change, and both need a reference point. The configuration management definition of a baseline supplies it: "an agreed description of the attributes of a product, at a point in time, which serves as a basis for defining change." Before a baseline there are no changes, only drafts. So governance starts with a status.

The ladder, and where the case stands on it

The rungs are mine [MINE], not a standard. They are the smallest set that tells a reader what has happened to a document:

1. Drafted. One person wrote it.
2. Self-reviewed. The author ran a written test against it, with time in between.
3. Peer-reviewed. Someone else tried to break it, and the objections are logged.
4. Approved. A person with authority to make it true said yes, for each item that needs one.
5. Baselined. One version is frozen, and every later edit is a change with a record.

The case sheet in the case dates three of them: v1.0 drafted on 24 March 2026, v1.1 after self-review against the scorecard on 31 March, v1.2 after external review on 9 April. Its front matter says status: "Reviewed". Open question OQ-03 is due "before the register is baselined", which only makes sense if the baseline has not happened.

The items inside the document are spread across the ladder:

Two readings of that table matter.

Three items were written after the reviewers left. The review sessions are dated 2 and 6 April 2026. REQ-015, REQ-017 and BR-12 entered in v1.2, dated 9 April. They answer the objections, but no reviewer has read them in their final form. The log's summary line says "Reviewed version: v1.2", which is true of the document and not of every item in it. A governance rule that marks status per item catches this. One that marks it per document does not.

Observed and proposed rules need different approvals. BR-04, BR-07 and BR-11 already exist, because the company published them. The analyst cannot approve them and does not need to. The task is to find whose they are, so they can be changed on purpose. That is OQ-03. BR-12 does not exist until someone adopts it, so there approval is what creates the rule. The register keeps the two apart in its Status column, which the case calls "the one most registers leave out, and leaving it out is how a rule that somebody proposed on a Tuesday becomes a rule that 'has always been there'." For an observed rule the owner confirms. For a proposed rule the owner adopts. A policy that says "approved by the rule owner" covers both with one word and gets one wrong.

When is each approval due?

The case has no governance section, but its open questions register already holds a calendar. Each question has a due point, and three of the four due points are events. Grouped, they become approval gates:

Events outlast dates. "Before build starts" stays correct however far the plan moves. The one fixed date, 30 April, belongs to a decision the summary asks for directly, so there the date is the event.

One question has two clocks. The summary asks the Head of Customer Care to name the rota owner and confirm weekend cover by 30 April. The register gives OQ-04 "before build starts". The summary simply asks early, but a policy should say which one binds. I would make the register's due point the deadline and the summary's date the request.

The fallback makes the gate real. Without one, a missed gate means nothing happens. The case puts it in one line: "An open question without a fallback is a wish."

Ten changes, replayed against a change policy

A change policy sorts edits into classes and gives each class one approver. These classes are mine [MINE]. I wrote them, then ran every logged change from v1.0 to v1.2 through them.

The replay, from the register's Status fields and the review log:

Three of the ten needed only the author. Seven needed someone with authority, and none has said yes. That is the gap between "Reviewed" and "Approved", and the log's summary names its cause: "two peers, two sessions, neither with access to the retailer."

The biggest edit needed the fewest signatures. BR-11 went from one line to a page, the change the log calls the one "that produced an artifact rather than an edit". Under the policy it is editorial: the rule statement and the figure did not move. The page adds the rationale, labelled as my inference, the open owner slot and the review trigger, all the author's to write. Sort changes by size and this one goes to a Finance owner nobody can name yet, and waits.

The smallest model edit created two items that need approval. Drawing the parked branch describes what already happens, so it is the author's change. REQ-015 and BR-12 came out of it, and both need someone else's yes. Classify each change where it lands, not where it started. That is the same walk a traceability matrix does when a change request arrives.

Does governance stop at the baseline?

No, it moves into the system. Criterion 3 of REQ-018: "Every automated approval records the rule version that approved it, so a later change to BR-11 can be traced to the cases decided under the old one." Once the pre-check pays refunds on its own, "which version of the rule was in force?" is a question about money already paid, and a policy that ends at the baseline leaves it with no owner.

One more finding, against the scorecard. Check 14 asks that every requirement carry "an id, a version and the date it last changed". The Status fields give a version, such as "v1.2, criterion 2 rewritten after review", but no date. The date is one step away, in the case sheet. That passes by reference only, and a register copied out without its case sheet would fail.

The governance card, filled in

One page next to the register, written before the baseline. The fields are my proposal [MINE]; every value comes from the case.

The governance card, empty

Fill in the "has the approver said yes?" column for your own history before the card. It tells you which rung you are really on.

All field notes · The portfolio guide · More in Requirements That Survive Review