The only sure way is to dive in and develop. Prior experience can be a guide, but design theory tells us that there are some requirements that don't come from the outside (the market) but from the product itself. You don't discover those until you make them. This is the whole foundation of Agile and of the theory of emergent requirements.

Reduce your risk by developing in small batches (incremental development) on regular, short time scales (iterative development).

I want to believe it's possible to use linguistic metrics (e.g. G. Lami with QuARS) to find out if a requirement explained as a sentence written, say for example, in English contains implicit meaning potentially hiding tacit knowledge.