Sorry mate, for most software development jobs it's part of the profession to tweeze out requirements from business people - both the sales types that can only think in "fluffy concepts", and the specialists who can't generalize that blue and red are two 'colours', since they are experts in every single shade of blue between 'navy blue' and 'egyptian blue'.
So, if you don't know what to do, you have to do some workshops and interviews, or just have a quick chat with "Bill, the salesguys". But to be honest, you probably already have a good hunch of what to do, you just want to make a point that there are a lot of people that have authority and with better pay than you, and they don't have a clue of what they really want or need.
I'll admit, most business do it wrong, since they think it's like designing steam engines or belt buckles , or something, and the "requirements process" is eventually leading to the "design process" which when completed, would spin up the code factory where hordes of talentless code monkeys would read the design specification and translate that into a working program, like a 1:1 mapping. Preferably in India. Or at least in the basement.
Hint: it's not how it works, and the reason for that it's not working like that is a combination of information theory (hey its thermodynamics!), emergence in systems theory, and how our brains work (our cogninitive abilitiies)
Ideally, work together with the business specialists, avoid "requirement specialist" and BA-types, since they add little or no value. Get rid of useless design documents that have no target audience , but create a common model (in your heads) and a common language, and develop and maintain (condensed) business rules and references that would actually be used when working with the system in the future. Pay attention to people that try to hide their incompetence by requiring more and more documentation.
Accept that the reality is surprisingly complex.