[mysterydip]

I recently took a model-based systems engineering course that opened my eyes to some helpful methods.

Use UML, SysML, etc to diagram out your requirements (starting at high level at first, more granular as the system matures). Now build a high-level model of your system design (software and hardware if required). Match parts of your system to the requirements. This lets you see gaps in two directions: requirements you haven't addressed (because they aren't connected as "satisfied by" anywhere on your model), and questions to ask for more detail on a given requirement that could drive the design.

As others have said, there will always be late requirements that change things, so it won't resolve those. It can, however, show stakeholders how much changing a requirement can cost in terms of rework/time by showing how the model has to change to accommodate.

The caveat with this is: the model needs to reflect your actual design, and you need to keep it up to date. The times I've used it so far it has been a useful exercise.

[Pamar]

UML? Really? Most Business Users want to discuss the UI and (if you are lucky) the data structures, two things that UML is not really very concerned with. In my experience, UML has been a really bad choice to work on requirements for corporate sw.

[mysterydip]

Agreed, it's not what business users want to (or should) see. This is an aid for what your team does internally, instead of just lists and documents.