Most projects do not fail because of the software. They fail on unclear requirements and poorly specified interfaces. Requirements engineering is the answer: translating what business units want into specifications a development team can implement without guessing. My working principle, stated on the interim project management page: better to specify one week longer than to fix three months of errors in production.
I have done this translation work for years in the Projectile ecosystem. As an official Information Desire Software GmbH partner, I have been capturing customer requirements since 2016 and refining them iteratively into implementable specifications, for rollouts, extensions and interfaces. The case study is on the references page.
From requirement to specification
A usable specification answers four questions: What does the data model look like? Which business rules apply? What happens in the exception case? And how do you know it works? The standard case is usually quick to describe; the substance sits in the exceptions: cancellations, edge cases, faulty input. Whatever you leave unspecified, you will meet again in production. Why a classic requirements document does not replace this work is covered in Why the Requirements Document Is the Most Expensive Mistake.
Documenting data flows
For interfaces, I document every data flow along the same pattern: source, target, mapping, error handling. Only when all four are answered is an interface specified; anything less is a statement of intent. This pattern has produced interfaces to DATEV, Salesforce, Atlatos, Diamant and Rex in the Projectile ecosystem, implemented via REST API, shadow tables or file export, with data mapping as the core task every time. How deep that can go is shown by the Projectile-DATEV interface, whose specification I documented in a freely available 9-page whitepaper, including posting logic and error scenarios.