This raises some good questions.
Just who does need to sign up to a requirements spec? And what does it mean?
The specificaiton is a detailed work order, and so the real signatory to this artefect is the person who is paying the money: the project sponsor.
There is a common habit of sponsors initiating projects and hen delegating everything else to theor operational managers. Frontline and middle managers are not always aligned to higher level goals, and so may load up a project with other agendas, resist change, etc.
You need to see that the sponsor/senior customer is the signatory, and that everyone else is a proxy.
As others have indicated, having the BA sign off on a document that presumably they created does nothing to realize the end goal of the project (provide a product that is effective at satisfying the user's needs) and adds additional risks to the BA as well as to the rest of the development effort.
If the business people who will use the product are reluctant to sign off on the document you need to dig deeper into determining the reasons for such actions. Perhaps they are worried about being 'locked in' to a set of requirements that cannot change after signoff (or not changeable without going through an onerous change request process). Maybe they do not feel like they had enough engagement in the requirements gathering process, and thus don't think the document reflects their true needs. Whatever the reason, engaging with the business to make sure that the project is ultimately a success is key.
Craig:
A broader question related to yours is: Just what can be realistically expected from a review cycle? Fortunately, the BABOK 2.0 provides a clear, concise answer to this question.
In case you have not noticed it, the BABOK 2.0 is essentially a functional requirements spec in of itself. While a typical functional requirements spec essentially states what tasks (typically called functions in a software spec) a software system will do and how those tasks interrelate, the BABOK 2.0 states what tasks a BA is to do and how all those tasks interrelate. Granted, the implementation mechanism is different between a typ software spec and the BABOK 2.0, but that of minor important; in essence, both docs are statements of "what" needs to be done.
So look at the BABOK 2.0. But not at what it says; instead look at how it was developed. Ask yourself: How clear and smooth flowing is the BABOK 2.0? Next, look at the number of reviewers of the handbook. Consider also that the reviewers of the BABOK 2.0 were all BA experts who clearly understand the importance of reviews.
This will give you an excellent understanding of what realistically a BA can expect from a requirements spec review cycle.
Tony
And we forgot to mention the"'conditional approval."
I collected one of these today.
"We accept on the condition that you fix x within y days"
brought to you by enabling practitioners & organizations to achieve their goals using: