BABOK V2.0 Section 1.2 starts:
Business analysis is the set of tasks and techniques used to work as a liaison among
stakeholders in order to understand the structure, policies, and operations of an organization,
and to recommend solutions that enable the organization to achieve its goals.
Business analysis involves understanding how organizations function to accomplish
their purposes, and defining the capabilities an organization requires to provide products
and services to external stakeholders. It includes the definition of organizational
goals, how those goals connect to specific objectives, determining the courses of action
that an organization has to undertake to achieve those goals and objectives, and defining
how the various organizational units and stakeholders within and outside of that
organization interact
Doesn't seem that complicated to me. Or that 'masses are asses'-ish either. One of the keys I find crucial to understanding the BABOK is the need to be "method neutral". If there only one TRUE method, presumably market forces would drive it to the fore. And then the names would be changed by everyone seeking to show that they were unique. The BABOK does a pretty good job of setting out some, umm, requirements that bound the BA scope.
At the highest level, I think there are two important aspects of the scope:
The BA results derive from a liason role: Understanding the function may be an good goal, but is unachievable without being able to speak fluently with both the business and technical domains, understanding and translating the wants, needs and concerns of both to the other. Further, to be successful it is necessary to observably align these domains in the solution. Now, in terms of importance, the deliverables are 100% of the job. If a data flow diagram is it (rundtion and how it they relate) is enough, then you're done. 98% of the effort to get to that deliverable may be in organizing, interviewing, facilitating, reviewing, and actually doing analysis to dig down to the root causes and business level solutions.
The BA in effect drives a sub-project: Planning, organizing, coordinating are important. It's possible to go off the rails here and either equate the BA with an PM or dismiss it as not relevant. The distinction, I think, is between 'internal' and 'external' management. The PM is a governance role 'external' to the actual work of the project: A manager everyone reports to. The BA role is 'internal' to the actual work of the project: A coordinator who reports to everyone. :) A focus on the planning, organizing, and communication skills misses this distinction driven by the liason role. (Note that this simple view can be complicated on large projects where there is a Sr BA acting as PM for the BA team. Aggregating the team as the BA role leaves the same distinction.)
I'm really curious what the lecture notes say. Can you share?