Writing software isn't the same as producing physical goods but instead is similar to designing a product.
Therefore I'd recommend design thinking and the double diamond model for design processes: 1. Explore the problem space. 2. Narrow down to the actual problem you want to solve. 3. Explore the solution space. 4. Develop and deliver the appropriate solution from that space. 5. Rinse and repeat.
These aren't rigid methodologies but rather general approaches.
Furthermore, proactive, goal-oriented communication is essential.
The people / roles responsible for designing and developing the deliverables should also be the ones to gather requirements and talk with the users. Additional layers of organizational indirection such as dedicated business analysts often are detrimental rather than beneficial.
Relevant communication should be recorded digitally and relentlessly.
Requirements only exist if they're available to everyone through some sort of digital system, such as JIRA and Confluence, which are tremendously useful and usable tools if configured for enabling communication rather than for imposing some rigid and often inappropriate process.
Big software projects just means that the above mentioned task is dauntingly big. Constant update and refining is needed as the project moves forward and there are a lots of unknowns and lots of different people to talk to. This work needs some kind of a system which includes documenting the communications and upgrading the tasks with new input.