Hi all,
Here's a contrarian opinion, but when practicing product development, I don't think you should be using requirements documents at all.
This may provoke a reaction and you may be asking, "But how will your align a team, prevent miscommunication, and work to a common understanding?"
I'm not advocating for a lack of documentation (although I prefer to keep things light), but I am advocating that you use the term "feature specification" instead of "requirements".
The reason why, is that "requirements" carries a strong connotation to it, that if you meet the requirements, you'll have done a good job. This may be fair if you're working to a contract, but in product development, the goal should be product success, not contract fulfillment. There's a term used to illustrate the point, called "achieving failure". It's when you build everything, exactly as intended, and it turns out to be a giant flop. The "requirements" may have been met, but it's not what the market or the customer wanted or needed at all.
That's why I prefer the term "feature spec". It's what you're agreeing to build. Hopefully, nobody's requiring you to do anything and you're here of your own free will.
To dive a little deeper, my mental model associates "requirements" with a traditional waterfall development model: requirements --> design --> implementation --> test / integration --> deployment.
I far prefer a "discovery/delivery" model of development that starts with a problem. Then the team, through a process of exploration and lightweight testing, figures out what features they bet will solve the problem. So I'm not opposed to documentation along the way, I just prefer to use terms like "problem framing", or "one pager", or "one paragraph description of what you're trying to do that even the sales team could understand", and then collaboratively figure out what we need to do to arrive at a feature spec.
The "figuring it out" portion is where you use UX mocks, prototypes, simulations, and all sorts of other tools to try to reduce risk in what you're going to build, before making a feature spec that will commit serious engineering resources.
And yes, for my readers who are hardware engineers, there is a heavy bias to an Agile style of software development in what I just wrote. For a lot of hardware, the "figuring out the features" portion of the project has to be done early, in the prototyping phase, and you get fewer chances to tinker and explore. Hardware bets are a little bigger. "Hardware is hard" is the saying.
So the next time you find yourself using the term "requirements", take a step back, and ask if that's what you really mean. Feature spec is much friendlier.
cheers!
Sam
aka THE Awkward Engineer
p.s. I have no objection to the terms "regulatory requirements" or "legal requirements". Those really are requirements :-).