I work for a very small business analysis team in a very large organization, and was recently asked by a project sponsor to support their request for having a Business Analyst as part of their project.
Here’s what I wrote (generalized a bit to anonymize it)
Simple answer is time and experience.
A Business Analyst will have spent time to learn the techniques and tools that work well to elicit requirements from subject matter experts (SMEs), and capture them in a way that facilitates additional discussion and verification by the SMEs, and communication to the teams that will be building the solutions (e.g. developers). Others can learn these techniques too, but there is a big difference between learning a technique and applying it day in and day out over several years…. Similar to when I worked with the your branch in the past, I know technically how to do many of the tasks your team does, but I’m sure my results wouldn’t be as good.
Additionally an experienced BA will have worked on multiple projects, and can often use their experience to recognize situations (patterns) you will likely need to address within your own project, and can often reuse previous material to help speed up your project. I do this a lot right now with the projects I work on, and was starting to do this with your branch before I was moved to other things.
Finally, in general I’ve found SMEs are not the best people to write requirements or do analysis, typically they don’t stop to ask themselves why the do something, and end up providing requirements based on how things have “always been done”, again a experienced BA tracks down why something happens, and gets the SMEs to question their assumptions.
The BA team is starting to capture metrics on how we reduce project time through reuse of requirements from previous projects, and estimating savings when we “kill” bad requirements. Bad requirements are when an SME states something they want, and through BA techniques we determine that isn’t what they actually need.