BA's don't fit in core UX/UI technology flow but in core software development flow.
Some main functions of the BA are to understand requirements and after that to devise the logical architecture of a solution.
These two tasks are intimately related to UX/UI and impact UX.
We read "Know Thy User" everywhere in UX copy. Well, the BA is the one in the right position to research the user's needs. The BA is at the fringe of both worlds, the IT people and the normal people.
Another UX mantra is the need for user research, not the ex-post user testing but up-front gathering of information. This is also what the BA does.
Depending on how waterfall or agile the company process is, the BA would gather and jot down detailed information, or get a general idea and delve into the details of only the first parts to be tackled.
devise a solution
Whenever the BA has collected enough information, she will be in a position to apply Jakob's Nielsen first rule of usability.
This means to apply her professional knowledge in order to devise a set of logical IT constructs that might not do exactly what the users ask for but solve their needs in a maybe lateral thinking fashion.
Alan Cooper explains it brilliantly in this 6' video.
In short, it's the BA's responsibility to devise the solution. Not the programmers', the visual designers', whatever: the BA together with the PO (Product Owner) and if possible away from marketing requirements (at the end, nothing markets better than something with a remarkably good UI).
what does the BA do?
As was stated in previous answers, the BA writes.
Depending on the company culture she might write User Stories, Use Cases, or requirements laundry lists.
If she does laundry lists then she's not doing UX but I don't care bacause she's not browsing this list. The solution has a significant chance to be late, exceed budget, and finally be useless.
On the other hand, if the BA is writing USs or UCs, then there is a chance that she was doing Interaction Design.
It is her responsibility, but she can share it with an UX guy if available.
It is in the writing of the interaction steps of the user against the system that the interaction is defined, better by UCs than by USs (but she can use both).
This is of paramount importance for the application (or web page, or whatever) to be usable.
Later on the visual design will surely add its part, but at the outset the application needs to have a reasonably good interaction design in order for the users not to get lost in the meanders of the actions required to use it with efficiency, efficacy and satisfaction.
It's so important because the interaction bloopers found later when doing user testing will not be fixed because it's so expensive, and nobody will have the nerve to tell the investor about the additional time and money it would require.
The BA owns the interaction design thing because at the outset she talked with the users, saw how they work, learned about their goals and needs.
during the development stages
The mission of the BA is to ensure that what the programmers are programming and what the designers are designing is aligned with her vision of the solution.
Additionally, if they are running an agile process (like the usual Scrum) she will be working full time on writing User Stories so the development teams don't starve (run out of backlog) and a great number of other duties.
But I mention the USs thing because it should convey the interaction design, or leave it to the programmers to get Dilbert-style results.
usability vs. UX
For the experience to be good to the user, the UI firstly has to be usable. This is what the BA has to provide.
After, it can become an "experience", but if the usability is not good then it will never be such a good experience for the user to feel the way we wanted in the first place.