Writing a software requirements specification has a reputation for being slow and corporate. In our experience it is the opposite: it is the cheapest week of the project, and skipping it is what makes the expensive weeks expensive.
The value is not the document itself. It is that writing it forces every ambiguous decision to surface while changing your mind is still free. What happens when two branches edit the same record? What should the system do when the payment gateway times out halfway through? These questions get answered eventually — the only variable is whether they are answered in week two on paper, or in week ten in production.
We write to IEEE-standard SRS practice, which mainly means each requirement is specific enough to be testable. A requirement you cannot write a check for is not a requirement, it is a hope. That discipline pays off directly at the testing stage, where every item in the specification has a matching verification rather than a general assurance that things seem fine.
It also changes the nature of scope conversations. When requirements change mid-project — and they usually do — there is a document to amend, with a visible cost in time and money attached. Nothing gets quietly absorbed, and nothing gets quietly dropped. That protects the client at least as much as it protects us.