Ambiguous information is better than no information at all and sometimes it is the best you can hope for in the early stages of requirements elicitation. The professional business analyst needs to improve on this condition because re-communicating ambiguous information adds little value to "shared understanding" goals. In fact, it damages "shared understanding" because each stakeholder can easily have a different idea about what was communicated, understood and agreed upon.
Example: The system shall ensure that the correct amount of product is maintained in inventory in order to ensure that orders can be fulfilled.
So what is "the correct amount" really? How does a software developer craft a calculation within the system to fulfill this requirement? How does a software test for "the correct amount"? If the requirement above is not rewritten before the set of requirements are baselined, you run a significant risk that the produced product will NOT fulfill customer / end user expectations or needs.
One method to fight the negative impact of ambiguous information is to teach everyone that contributes to the requirements repository about ambiguous information. In this setting, you are avoiding the condition and that helps reduce the effort the business analyst has to exert to clarify information.
Most people want to contribute to group efforts they believe in and they value attempts to make themselves more productive towards the combined efforts of everyone else. I don't know that I would hold a class on ambiguity but you can hold a workshop on requirements lifecycle and best practices along the way.
The BABOK Third Edition has a section that has some very interesting things to say about teamwork (9.5.3). I think the following is a viewpoint that might help the idea of holding a training workshop or town hall on crafting good requirements.
"Knowing and adapting to how and when a team is progressing through a project's life cycle can lower the negative influences that impact a team."