With years of my career evolution as a testing and automation professional, I’ve developed my own practical view about requirements, their role, and how to deal with them in a context-driven, heuristic way.

1. I’m completely satisfied with the requirements provided by Business. I never require them to be 100% clear and precise, and never complain about changing requirements.
2. I use these requirements to develop a holistic view of the product, and prioritize testing of my team.
3. Of course, the holistic view is not limited to input from one source, as map is not the same as territory, – we will be proactively obtaining information through any other sources available (conversations with all those involved in the project plus customer support, version in production, public and legal claims, over-arching statements, and other, and other) – putting everything together, identifying concerns, and presenting it all back to Business.
4. Moreover, if we discover any behavior in the product that (potentially) threatens its value, we’ll make sure that Product Owner is aware, and we’ll conduct any additional investigation that might be needed.
5. Finally, I’m absolutely willing to share and collaborate with Business and Development teams, so that our mutual holistic view nurtures the bonds between the teams, contributes to sense of ownership and accountability, – and helps to avoid many problems before they unfold.

Disclaimer. Sometimes, for some reasons, collaboration is a heavy challenge itself. For situations like that I found that revolutionary approach is troublesome – introducing too much changes without trust earned is risky. So the first step is to successfully merge into the project, then gradually earn trust by demonstrating value and commitment, and only then bring up possibilities of the further improvement. So this may take a while.