Is a Business Analyst supposed to have domain knowledge?

If they don't have domain knowledge in the business they work with (for example, retail logistics), then how can they be effective in doing their work of analyzing the business problem (seeing the big picture, the root cause problem and dependecies, all the stakeholder groups, possible bottlenecks known in similar businesses, etc) and devising a good business solution? This only seems possible for trivial or general business problems, something like creating a web-site of average complexity.

4 Answers 4


Is a Business Analyst supposed to have domain knowledge?

Yes, a BA needs to have domain knowledge, otherwise they won't be efficient in interacting with stakeholders, creating business analysis and requirements, or identifying problems, opportunities and solutions for the business.

It's not very different than developers needing to understand the business they work in. BAs and developers have certain skills, but those skills aren't practiced in a vacuum, but inside a business context. So they need to understand the domain enough, in order to be efficient and effective at their work (in this case, a BA more than a developer because of the actual nature of the work of business analysis).

But of course, depending on the experience of the BA, there are situations where the BA might be new to the domain, or maybe new to the job of BA itself, in which case it will take some time for them to learn the business. But learn it they must.


There are a lot of other knowledge and skill requirements a BA, or any role really, needs to have besides some degree of expertise in the domain. Every individual who claims a job role will have varying degrees of expertise in those knowledge and skill requirements. Depending on the demand of that BA job, you may require someone who presents with deeper knowledge and skill on another key area and less in another, including domain. So taking advantage of those knowledge areas and skills while assuming the risk in another are appropriate choices.

If your project has multiple BA positions, then diversifying skill sets is a smart thing to do instead of "requiring" all of them to have domain knowledge. Of course, if you are able to diversify while maintaining deep domain knowledge, that's great but making it a requirement where you may end up filtering out someone you need could very well be a fool's errand.

From my experience, albeit anecdotal, I have watched a lot of consultants thrive outside their published sort of scope area and vice versa. I have come to the conclusion that a lot of our hiring predictors are rather useless so hard and fast rules, like what you are trying to establish here, are ill-advised.


No, a Business Analyst does not need domain knowledge.

The key reason is that the Analyst's work is focused on business which, according to an applicable definition means, "to arrange one's affairs." "Arranging work" requires an understanding of how to inquire with the actual subject matter expert about their business. Further, domain knowledge may impede the Analysts work because they will be distracted by their own personal interpretation of the business.

The "root cause" point is interesting - one might think that domain expertise is required, and it is, but only in so far as there is someone to answer the line of questioning or methodology imposed by the Business Analyst. In these situations asking the right questions, facilitating the discussion, and asking the domain expert about how they organize their business is a key to success.

In cases where "domain expertise" is required, the request for a Business Analyst will result in a frustrating search. To be clear, domain expertise is vital to most projects but in assembling a team or searching for the right fit, that person will be much more than just a business analyst. This is why we have engineers of various types, architects, data scientists, etc. who are the true domain experts.

  • Thank you, @Sam! So you mean that BA's job is asking the customer about their needs, decomposing them and writing them down? But this can be done by a Project Manager, a developer, or QA engineer. Why do we need a special employee for that? And why are they called Business Analysts, and not Requirements Analysts then?
    – Daniel
    Commented Jan 5, 2021 at 16:59
  • @Daniel - how you label position description for HR purposes and the function or role that they fill is really up to what you want to hire (hiring a PM to do BA work can be a bit costly). My contention is that the primary BA role is "business" not "domain"; a combination of both can be very useful, but I contend that the former is more important than the later.
    – Sam
    Commented Jan 11, 2021 at 18:18

"Business analysis" is really much more of a human- communications task, than a technical one. The enterprise already understands its physical business. What it needs from you is the design of a software system that will actually be understandable and useful to them in their daily physical work.

"Their business," being human, is infinitely adaptable, in a way that humans are able to do without even realizing that they've done it. But, "computer technology" is the exact opposite: "digital computers are still ones and zeroes." Your business role is to bridge that gap. Software implementation demands precision that "human processes" inherently do not have. Your task will necessarily consist of compromises. Expect it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.