You can't test (or build) anything if the requirements are not very clear. They must never be ambigious, incomplete or very vague (or even incorrect).
Mind that: the reason why specifications are not clear can be because of an enormous amount of different causes. But that is not the point, they should always be as clear as possible. Otherwise the software testers can't do their jobs.
"When I deliver facts to the developers and test team, then my results will be based on facts as well..."
And that is just NOT true!
The fact that Business Analysts worked 2 months to get the requirements clear, is NEVER a guarantee that the results of the testing on monday, will produce the exact same results if the tests would be repeated on tuesday.
(Testers need clear requirements more then anything, but.... they are not able to predict the future!!).
And the reasons why a test result on monday can have a different outcomes on the next day, is also enormous... But that is just not the point here... The main thing to understand is: Test results are NEVER facts...
It's better to see them just as 'a picture taken on a certain time, from a certain angle, with certain movement, that all in all give you some idea of what the status is.'
Try to understand:
Software testers need FACTS to be able to do their job, but the results of their work is NEVER a fact!