Like most things, quality checking of requirements is an incremental and iterative process. As you develop each set of of requirements following a discussion, interview, workshop or whatever, invite some stakeholders to review what you've written to ensure that they are accurate and sufficiently complete. Don't wait until you think you're "done" gathering requirements to solicit feedback. This incremental approach works with any development lifecycle (traditional, agile, hybrid).

Whether you use a formal sign-off process for your requirements sets is up to your situation and culture. Higher-risk projects demand more formality and commitment. Certainly, you need to reach an agreement regarding when a set of requirements is considered ready for implementation, whether that set represents 1% or 100% of the product's functionality.

If you do use a formal sign-off, make sure everyone involved understands the implications and what they are saying with their signature. I discuss all this on pages 38-41 of my book "Software Requirements, 3rd Ed."

I'm not sure if it sucks to be a BA, but it is certainly a challenging role!