The translation is a legitimate skill that should not be underestimated. Especially when you add in that there ought to be flow the other way as well. As an engineer, I want to be involved early in the business processes, because as we all know sometimes business people assume that very hard things are easy, but sometimes there is something I can offer them that they don't have any idea is easy. It's best to work through the cost/benefit process together, rather than the business people huddling in a corner before flinging over a set of requirements to engineering as Holy Writ.
(Kinda struggling with that now; I'm peripherally involved in a project with big monetary implications. The "solution" is to build a big system as quickly as possible and run around making super-high-priority requests across a whole lot of teams, almost all of which need to be in place before any value is obtained, and which consequently is behind schedule and dragging out. On the other hand, a week, some database queries, and a reasonable amount of manual labor could get about 50-75% of the value now. But none of the project managers are interested in that fact, which frankly boggles my mind. I'm not sure if they just don't understand what I'm saying, or are just so stuck on the solution they designed that they've lost all ability to think outside it. One thing I have confirmed is that it isn't just that I don't have a full picture of the problem, which is the usual situation; I'm quite confident what I'm thinking would work.)
However, while that skill is not necessarily something you need a graduate degree for and 20 years dedicated experience, and engineers can pick it up, there are engineers who don't have it yet, or even won't pick it up because they despise it. The list of skills required to be an engineer is already pretty long, requiring this to be added as well raises the bar even higher.