As a BA on a Scrum project, I do all the same things I would do on any other project. I identify stakeholders and their interests. I don't necessarily have to write it down, but I do have to determine who are the pigs and who are the chickens. I get to the root of what the business really needs and produce a list of actors and features. I coordinate requirements gathering sessions, both formal and informal, with the development and testing team present along with the users. With my list of features as my guide, I use BA techniques as old as time to prod and poke until everyone understands a handful of small tasks that need to be accomplished. A question I end up asking a lot is, "Do you know what you need to know in order to complete the task assigned to you?." If the answer is yes, I take a picture of my whiteboard and move on. If the answer is no, I either poke and prod some more, or I guide the team to make a decision about whether or not it's okay that we don't know this thing yet, whatever it might be. If someone starts gold-plating, I steer the team back to the original feature list. If someone suggests doing something that contradicts something else we decided two sprints ago, I tell them so.
I could go on, but you get the picture. It's the same stuff, the same techniques, but the deliverables are different. Whether you tack up index cards, or you use a software tool, it's really nothing new under the sun. What you actually produce as deliverables is really up to the stakeholders, but user stories are typical. In my organization, we produce something closer to a use case than a user story. The important part is that the entire team fully understands what is expected.
Your next question may be, "Why can't the developers do this?" Well, they can. However, in my experience, most developers want to develop, not lead this kind of interaction or get too involved in the big picture. Management prefers it that way, as well. When you're churning out a shippable product in 4 weeks, you want the developers to be doing more of what they do best.