A Belief I Held for Years
Early in my career, I thought a requirements document was the thing that saved a program. Write it carefully enough, get every stakeholder to sign it, and the design that follows just has to satisfy what is written down. I spent a lot of hours making sure every requirement was testable, traceable, and worded so there was no room for argument later.
I do not believe that anymore. Not because requirements do not matter. They do. But I used to think the document itself was the safety net. Now I think the document is a snapshot of a conversation, and the conversation is the actual safety net.
What Changed My Mind
The shift happened on a program where the requirements were, by every metric we used to judge these things, excellent. Clear language. Full traceability matrix. Every box checked in the review. And the design still drifted away from what the customer actually needed, because the people writing the requirements and the people building to them were not talking to each other between milestones.
Nobody had violated the document. The document was fine. The problem was that we treated it as a handoff instead of a thread that stays live. Once it was signed, people went back to their own work and assumed the words on the page would carry the intent forward on their own.
They do not. Words carry less intent than the people who wrote them think they do. I read a requirement I wrote six months earlier and sometimes have to think hard about what I meant.
What I Do Differently Now
I still write careful requirements. I have not stopped doing that. But I no longer treat the review that approves them as the end of the job. A few things I do differently:
I schedule check-ins that have nothing to do with a milestone. Not a formal review, just a short conversation with the engineers building to a requirement, asking them to tell me back what they think it means. The gaps between what I meant and what they heard show up fast, and they are almost never about the wording. They are about context that never made it into the document because it felt too obvious to write down.
I write down the “why” next to the “what.” A requirement that says a component has to survive a certain vibration load is less useful than one that also notes why that load matters for the mission. When the why is attached, an engineer who hits a conflict downstream can reason about it instead of treating the number as sacred or negotiable at random.
I expect requirements to change, and I built that into the schedule. Early on I saw a change request as a sign something had gone wrong upstream. Now I see it as a normal part of a program learning what it actually needs. I budget review cycles for it instead of treating every change as an exception that has to be justified twice.
The Part I Still Get Wrong Sometimes
I will say honestly, I still catch myself reading a well-formatted requirements document and feeling more confident than I should. Good formatting is persuasive. It looks like rigor. But formatting and shared understanding are not the same thing, and it is easy to mistake one for the other when a review goes smoothly.
The question I ask myself now, every time a requirements review wraps up clean, is whether the room actually agrees on what we just approved, or whether we agree the words are acceptable. Those are different outcomes, and only one of them holds up six months later when someone is building hardware against a sentence I wrote on a different day, under different assumptions, for a reader I was imagining instead of the one actually reading it.
Why This Matters Past the Document Itself
None of this is really about paperwork. It is about where I put my trust. I used to put it in the artifact. I put it in the relationship now, and treat the artifact as a record of where that relationship stood on a given day. The document still gets written. It just is not doing the job alone anymore.