Scott Ambler, the practice leader of agile development for the IBM Methods Group and author of several books on software project management and agile development, says that first and foremost, business analysts (or as he terms it, business systems analysts, or BSAs) are responsible for communication and collaboration between the business and IT.

"The most important responsibilities of a BSA are to act as a communication conduit between the stakeholders and the team," Ambler says, "to represent the stakeholder community to the development team if the developers themselves don't have direct access, and to translate the business needs for the team.

Ambler developed a list of eight activities that business systems analysts will usually perform on a traditional software development project:

1. Scope the system. At the outset of a project, business analysts may be the only "software development staff" assigned to the project, Ambler writes. And at this point, they work with key project stakeholders and business people to formulate and communicate the business vision for the project, map out initial requirements and the scope of the project.

"Their fundamental goal is to get the project focused early by translating the initial high-level vision into something realistic," Ambler writes.

2. Interpret business needs. A critical responsibility of business analysts is "to work with project stakeholders to translate their requirements into something that developers can understand as well as to translate the resulting questions that the developers have into something the stakeholders can understand," Ambler writes. A key skill needed in this part of the process is the business analyst's ability to distill the differing messages and needs of project stakeholders into a single, consistent vision.

"This task often includes significant negotiation and political maneuvering," Ambler writes. Business analysts will "often find themselves spending significant time in meetings, thereby saving the rest of the development team from this inefficient use of their time."

3. Translate technical issues. Business analysts also have the arduous task of breaking down technical and architectural complexities so that project stakeholders can easily understand any issues that crop up, such as "why your HTML-based application can't have as slick of a user interface as a Visual Basic application," Ambler writes. "BSAs often explain what the developers are doing and why they need to do it, including explanations of the basis of schedules and estimates."

4. Spell out the project details and requirements. "BSAs will often work with project stakeholders to identify, model and then document their requirements and business domain details," Ambler notes.

5. Put development team in touch with the right people. "BSAs typically have very good connections within the business community," he writes, "and therefore are in a position to help development teams find the right people to work with."

6. Political guide. "BSAs often help project teams through the political minefields within their organizations, particularly when the BSA has worked within the same organization for several years," Ambler notes.

7. Test and validation. Business analysts work with project stakeholders to "validate their requirements and analysis models via techniques such as reviews, walkthroughs and play acting," he writes. "BSAs will often aid in writing user acceptance test (UAT) cases and will be a liaison between project stakeholders and your testing organization during UAT."

8. Represent project stakeholders throughout the process. If project teams don't have direct access to their project stakeholders, which is never a good situation, business analysts have to act as "stakeholder surrogates," Ambler suggests. "Typically developers will treat a BSA as the 'customer' from which requirements, domain information and business priorities are provided. The BSA, in turn, will work with the stakeholders to obtain information and to verify decisions."