Feature Deduction
The problem
You have what Chris Matts calls an “Order Taker” as your business analyst. This individual is occasionally your only access to the people that actually understand what’s needed, yet they’ve been positioned as the gatekeepers of knowledge.
Consider this tactic
Combine “The 5 Why’s” and “Feature Injection” and see if you can deduce the real information that led to a specific requirement or change.
The basis
The thing is, the person the BA is talking to likely does Feature Injection, even if they don’t know they’re doing it. They’ve created their mental model (or “understanding”) of what problems this software they’ve asked for will solve. Something comes along and breaks the model (or “Doesn’t quite match what we’re doing”), and they change the model (or “submit a change request”).
If you look at the outputs of this (the delta, or the specific change), you’ll observe that they probably share a common theme or two. If you keep asking “why” on the changes, you’ll accomplish two things. You’ll be able to understand what sort of learning occurred, and the further “why’s” will either lead to better answers (less “telephone” effect) or more questions for the actual business owner. Second, you’ll probably frustrate the hell out of the order taking BA, and there’s a tiny chance they’ll learn to act differently.
Either way, you probably understand the intent of the changes better, which means you can do a better job providing value.
btw, please please please try and fix the organizational structure first, but if you can’t do so, then you can begin finding the right ways to work around the impediments.