I’d recommend you train your wider team, particularly the Business Analysts, to look for potential quality problems in the text of your software requirements. That way, they can help you to test the quality of requirements, even if they don’t have much knowledge of coding. I suggest you encourage your team to look at the language of requirements for ambiguities, complexities, omissions, duplicates and inconsistencies.
I find that testing the quality of requirements reveals how they can be made more complete, which helps teams to reduce rework, reduce time spent on responding to scope changes and deliver software faster.
I’ve put together some thoughts on which part of the requirement is the most important to test for quality, which might help you to get started with your training project. You can read my suggestions in my article that uses examples from BDD. Scroll down to the section called ‘BDD user stories could handle who and what more effectively’: https://www.linkedin.com/pulse/could-bdd-user-story-quality-improved-colin-hammond/
Could training your team to find quality issues in the text of requirements be helpful?