A quick example to illustrate my point; when RE’s talk about quality the phrase “complete and accurate” comes up very quickly. In BA discussions the emphasis is on “understanding and effective communication.”
Both groups are talking to the same point, but one is focusing on the artefacts while the other is focusing on the people. The ‘quality artefact’ approach will be more important in highly formal and contractual environments, while the people (outcomes) based approach will be more effective when the team is working in a more informal or united way (e.g. less likely to be a cross-functional or client-vendor team.)
Another point to note is that the business analyst is not just a requirements manager. Requirements management is a critically important job and a key part of the business analyst’s role, but the BA looks beyond the requirements to a wider range of issues that orbit the business problem the project is there to address.
Business analysts are looking deeply at the business problem, and the requirements are just part of the solution. In particular there is the constraints of the environment, the change management-effort required and benefits realisation, not to mention things like enterprise analysis, developing project business cases, project portfolio management, stakeholder management and the many other things BAs do in the course of delivering the project.
The IIBA’s BABOK spends much of its content going through the requirements management process and rightly so because requirements management is a large part of a project BA’s life, but just like the contents of the BABOK it’s not the exclusive content.
The bottom line of all this is that Requirements engineering is just one of the many things a business analyst gets involved in. Requirements management is a key part of a business analyst’s role, but not all BAs are managing requirements and not all requirements managers are BAs.