My frustration as a BA is the lack of clarity between "Requirements" that are testable units and "Design" which, when created as part of the requirements actually BECOME requirements. When the business signs off on a low-fi or a high-fi wireframe, they have made that visual their requirement. Now I'm writing testing scripts to ensure that the wireframe is generating exactly as shown in the picture. Talk about granularity!!Requirements should be about the FUNCTION of the application, not the visual design unless the design has a legitimate business need to covered - like ADA, Marketing standards, or identified productivity enhancements.
More often than not, business and developers rely on the visual because they cannot conceptualize their end product without it. It's the difference between reading a book and watching the video of those requirements. It's a slippery slope of getting married to a design and the business starting to dictate "how" that design should act (save buttons, error messaging, data collection, navigation, etc.) As much as developers should not be dictating UX, neither should the business, unless they are in the business of UX and design and then I'd wonder why they aren't writing code themselves.
The big groan is often gather and document requirements faster so development can start which begs the question of why write them out at all? If developers cannot read requirements and start to structure development without design, then it seems likely that they don't care about reworking data and design rework is far more uncomfortable to change. Being agnostic to requirements gathering means open opportunity for agnostic design - design not tied to a platform and it's constraints. Creating the process of signing off on wireframes, you are setting the business up to accept what you are willing to give them instead of giving them what they need. Then the process ends up about the pretty pictures and not about the function of the application.