I think creating an example API, going back to your customers, asking customers for feedback rinse and repeat is far better than a formal requirements analysis phase.
The best documention from a Devs perspective are interactive sandboxes with examples.
Functionally that ticks boxes, but it won't tick non-functional boxes of security, resilience, performance, ..., ..., ...
It's very immature to suggest that this is Agile and persists the myths that Agile as a hackathon exercise is okay as a business methodology.
Requirements analysis done properly it involves more than just checking boxes, there are exploratory exercises like https://www.agilealliance.org/glossary/storymap/ which allow stakeholders, customers and the development team to work together to voice requirements and concerns.
http://agilemanifesto.org/history.html
"The Agile movement is not anti-methodology.."
Agile is not about hacking, and the manifesto is not about replacement of one with the other, but about the balance of how you adopt them.
Formal requirements analysis might be too much process, but then on a financial system, it would likely warrant a necessity on accountability requirements put in place by regulators.
Looser story mapping alone might be an appropriate balance for a Beer Catalog.
I'm not a fan of a agile, but can we stop recharacterising it as not doing process.
*Not a fan: Having a 3 month support ticket, with multi-level signoff, 100% test coverage, cost codes and invoices per change is a bit much for text change on a website, so Agile does help solve a problem that really does exist in places. But is individual and interactions before process appropriate on medical systems? Agile may fit somewhere in the middle ground (between computer games and nuclear control systems), but it is definitely not a catch all for appropriate ways to work, especially in high risk environments.
The best documention from a Devs perspective are interactive sandboxes with examples.