It has been a feature of the push towards new ways of delivering solutions to business stakeholders that the role of Business Analyst has been evolving, or perhaps even fragmenting.
If we look at the engagement descriptions we have had over the past 12 months, they include:
• Business Analysis - Technical
• Business Analysis - Data Specialist
• Agile Business Analysis
• Digital Business Analysis
• Digital Agile Business Analysis (!)
• Mobility Business Analysis
• Business Analysis - Oracle eBusiness
Of course, some of these descriptions are just specifying the domain knowledge required by the Business Analyst; however, there is now a trend in describing not just what the Business Analyst knows but also the way they work. It has long been pointed out that there is not a specific role title of "Business Analyst" in the Scrum framework and that this is somehow significant - but there are a lot of other roles which are not called out by name; Scrum is not saying that these skills are not needed as part of the process but that they may not need to be specialised individuals within the team.
Of course, a Business Analyst in an Agile team has to work in a fairly different way to that in a more "traditional" team. Agile has increased the collaborative nature of teams. It has also sought to create a shared language across teams - for instance, with Behaviour Driven Development (BDD).
The objective is to take complex functionality and clearly communicate how it's meant to work in language that non-technical people can understand. However, those of you with reasonable memories, will know that unambiguous, precise descriptions of requirements have long been the goal (you may remember UML for instance or even Z language!). Agile has also driven a change in the timing and amount of analysis being completed. There is more of a lean "just in time" approach to analysis. Only doing what is needed, when it's needed. This ensures there is no waste in the analysis process.