Get Requirements Sign-Off — Requirements Engineering, Part 10

Requirements Engineering · Part 10

A signature is cheap and a decision is not. The whole value of sign-off is that it moves disagreement to the cheapest place to have it — before the build — and a rubber-stamped sign-off does the opposite: it buries the disagreement under names and lets it detonate in week nine.

This tutorial runs the process that produces the real thing. For why the incentives push everyone toward the fake version, see requirements sign-off without the theater. This is the running of it.

Illustrative composite concluding the support-tooling example from Parts 1–9. Figures are illustrative, not measured.

Before You Start

• A requirements document carrying a version identifier — the artifact Parts 2 through 8 built: use cases and their flows, INVEST-checked stories, the traceability matrix, the MoSCoW ordering, the prototype findings, and the NFR set. You sign off a version, not a title.

• An open-questions log where every entry is closed or has an owner and a date. Anything decided verbally in the Part 6 workshop but never written into the document — the split-tender rule was ours — goes in before you schedule anything.

• Approvers named and mapped to sections in advance, each able to say no without checking with anyone: finance for money movement, support for workflow and SLA, engineering for the Part 8 NFRs, design for accessibility.

• The change-request process from Part 9, live and linkable. Step 10's last line needs somewhere to point, and it's the line that makes the sign-off a boundary.

• A change log, so the T-1 reissue is reviewable as a diff rather than a fresh read.

• Block seven calendar days end to end for the T-7 to T-0 schedule, including 60–90 minutes for the walk-through and 30–45 for the sign-off itself.

What You'll Build

A sign-off record naming a version, mapping approvers to the scope they own, listing conditions, and closing every open question — plus the conversation that makes it real.

Step 1: Check the Preconditions Honestly (10 min)

Do not schedule sign-off until all four are true:

• The document is stable — not being edited this week

• Reviewers have had at least a week — with the document, not a summary

• Open questions are closed or owned — each with a name and a date

• The signers have authority — they can say no without checking

Ours failed the third. The split-tender rule had been decided in the workshop but never written into the document — it existed in meeting notes. A sign-off with a live open question isn't a sign-off; it's an agreement to disagree later, at build prices.

Check: your open-questions log is empty or every entry has an owner and a date. Any entry reading "TBD" is a defect you're about to approve.

Step 2: Distribute With a Specific Ask (T-7 days)

Attached: Refund Queue R1 requirements, v1.1.

Sign-off is Thursday 14th, 30 minutes.

Please read section 4 (refund routing) and section 6 (SLA ordering)
in particular — those are where the trade-offs are. If anything is
wrong, I'd much rather hear it before Thursday than after.

Naming the two contentious sections is what converts "please review" into something a busy person can act on in fifteen minutes.

The whole schedule, and what each step is protecting against:

When	What happens	What breaks if you skip it
T-7	Document out, with the sections to scrutinise named	People read it the morning of, and approve what they skimmed
T-5	Walk-through — questions taken, concerns noted, nothing resolved live	Signatures without engagement; concerns surface in build
T-3	Written feedback window, each item accepted / declined / deferred	Feedback vanishes, and nobody bothers giving it next time
T-1	Revised version reissued with a change log	Approvers sign different versions and call it consensus
T-0	Sign-off, per person, per scope, with violations named	You collect names instead of decisions

Check: your cover note names the specific sections each reader should scrutinise. A generic "please review" produces generic approval.

Step 3: Hold the Walk-Through (T-5 days, 60–90 min)

Walk the major sections. Take questions. Note concerns — do not resolve them in the room; resolving live produces decisions the absent will contest.

This is where engagement actually happens. Skip it and you'll collect signatures on a document people skimmed on the morning.

Check: at least one concern was raised. A silent walk-through means people are waiting for the meeting to end, and you'll hear the concerns in build instead.

Step 4: Run a Real Feedback Window (T-3 days)

Three business days for written feedback. Each item gets one of three responses, in writing: accepted (document changed), declined (with the reasoning), or deferred (with an owner and a date). Reissue with a change log.

Check: every piece of feedback has a visible disposition. Feedback that vanishes teaches people not to give it next time.

Step 5: Ask the Question That Separates Agreement From Performance (during sign-off)

This is the step that decides whether any of the rest mattered. For each load-bearing requirement, ask the approver:

"What would have to happen in the build for you to consider this requirement violated?"

An approver who genuinely engaged answers immediately, because agreement is holding a concrete picture of what wrong looks like. Ours, from finance, on split-tender:

"If a partial refund pays the card before the gift-card balance is exhausted, that's wrong — we're paying processing fees on money that never left the business."

That's a real sign-off: she's holding an acceptance test in her head, and it can be written down and verified.

The performed version sounds like: "Well — it should just work correctly." No failing case, because there's no concrete model underneath. No nameable violation, no real approval. You can hear the difference in one exchange, and the person saying it is not being lazy — they simply haven't formed the picture yet, and now is when that's cheap to fix.

Check: for each of your two or three most important requirements, at least one approver can state the violation without hedging. Count them. That fraction — not the number of signatures — is your real sign-off rate.

Step 6: Take Sign-Off Explicitly, Per Person (30–45 min)

Not a round-the-room nod. Name the person and the scope they own:

"Priya, you're signing off on the money-movement rules — section 4,
including gift-card-first ordering on split-tender. Yes?"

"Marcus, the agent workflow and the SLA ordering — section 6. Yes?"

Mapping each name to a section is what stops one signature standing in for expertise the signer doesn't have. Finance is not approving the accessibility bar; design is not approving refund routing.

Check: nobody signed off on a section they couldn't be questioned about.

Step 7: Write the Record (5 min, live)

## Sign-Off Record — Refund Queue R1
Document: v1.2  ·  Hash: 4b91c7e  ·  Date: 14 Nov

Approvers (by scope)
- Priya N. (Finance)     — §4 money movement          — Approved
- Marcus L. (Support)    — §6 agent workflow, SLA      — Approved
- Dana O. (Engineering)  — §7 NFRs                     — Approved
- Sam R. (Design)        — §5 accessibility            — Approved with condition

Conditions
- Sam R.: WCAG approach revisited at increment 2 (owner: Sam, 12 Jan)

Named violations recorded
- §4: card charged before gift-card balance exhausted
- §6: at-risk refunds not surfaced above others on queue load

Open questions: none

The version identifier is not bureaucracy. Without it, six people approved six slightly different documents and called it consensus — the document was edited the night before, and someone read Tuesday's copy.

Check: the record names a version and a hash or date. "The requirements" is a title, not a version.

Step 8: Record Conditions as Commitments (varies)

A conditional approval is a real approval plus a real obligation. Capture both — the sign-off and the condition, with an owner and a date.

An uncaptured condition returns in three months as a brand-new objection, and the stakeholder will be right that they raised it.

Check: every condition has an owner and a date, and lives somewhere that gets read — not only in the sign-off record.

Step 9: Handle a Refusal Properly (varies)

If someone won't sign, find out which kind of problem it is:

• Substantive — they've spotted something real. Fix the requirement. This is the process working; a refusal here is cheaper than the alternative by an order of magnitude.

• Process — they didn't get time, or the wrong person was asked. Fix the process and re-run.

• Positional — they're protecting something outside the document. Escalate to whoever owns that.

Do not paper over it. An unsigned approver who "went along with it" is the person who will say that's not what I meant at the worst possible moment.

Check: you can name which of the three you're dealing with. If you can't, you haven't asked enough.

Step 10: Publish, and Point at the Change Process (1 day)

Refund Queue R1 requirements are approved (v1.2, 14 Nov).

- Document + sign-off record: [link]
- Conditions being tracked: [link]
- Build starts 18 Nov

Anything that changes from here goes through the change request
process: [link]

That last line is what converts sign-off from a ceremony into a boundary. After this point, changes aren't arguments — they're priced requests with a named displacement.

Check: the announcement names where changes go. Without it, the next change arrives in a corridor and the sign-off you just earned quietly stops meaning anything.

You're Done When

• Your sign-off record names a version and a hash or date, and every approver on it is mapped to a specific section rather than to the document as a whole.

• Every condition on the record has an owner and a date, and each one also exists in a tracker someone will open next month.

• Your open-questions log reads "none," and for your two or three most load-bearing requirements you have a violation written down in an approver's own words.

If This Goes Wrong

• The document is still being edited this week. Freeze it and restart the clock at T-7. Running sign-off over a moving document produces approvals of different versions, and afterwards you can't tell which.

• An approver can't name a violation — "it should just work correctly." Don't record the approval. Walk them through one concrete failing case for that requirement and ask again. If it still doesn't come, mark the section unapproved with their name against it as an open question.

• The walk-through was silent. Treat it as a failed step, not an efficient one. Go back to the two contentious sections your cover note named and ask each reader directly what they would change.

• Someone refuses to sign. Classify it before you respond — substantive, process, or positional — then act on the class: fix the requirement, re-run with the right person or more time, or escalate to whoever owns the thing being protected. Never convert a refusal into a verbal "went along with it."

• A conditional approval arrives with no owner or date. Get both before you write the record, and put the condition into something that gets read — a tracked item, not only the sign-off record.

Common Failure Modes

Pressure sign-off. "Just sign so we can start." You get a signature and no commitment, and it unwinds later at full price.

No version identifier. Several people approve several documents and everyone believes there was consensus.

Skipped walk-through. Signatures on a document nobody read.

Uncaptured conditions. A remembered concern becomes a new objection months later.

Wrong signers. Someone approves a section they have no standing to judge, and the real owner never saw it.

No boundary afterwards. Changes resume arriving informally and the sign-off becomes decorative.

Continue the Requirements Engineering path

• Previous — Part 9: Manage a Requirements Change

Part of the Requirements Engineering learning path.