Business Analyst

There are several other pages that discuss and define "analysis" (WhatIsAnalysis, WhatIsAnalysisContinued and to some extent BigDesignUpFront) but it seems to me that the context of these discussions assumes that the project has already reached a stage of commitment by management and that the client "has a clue" about the business process they are supporting. In developing a methodology based on XP, we are incorporating a BusinessAnalyst role to provide the information management needs to make a committment and help the client look at alternative solutions before the development project begins. To that end we have proposed the following roles for the BusinessAnalyst:

Over the life of the project the Business Analyst will:

Perform a high-level analysis of the problem domain from a business value perspective to determine the feasibility of constructing the application
Re-engineer business processes and assist the client with the development of new process flows, documents, forms and administrative processes.
Produce initial project scope, schedule and budget,
Act as arbiter between client and developer with respect to project implementation issues,
Conduct analysis at a sufficient level of detail to determine the essential functionality of the application expressed as use cases or user stories,
Capture information flows and determine general data storage and retrieval requirements,
Efficiently transfer the high-level analysis products, use cases and process diagrams, to the development team.
Assist clients with transition planning, data migration, administrative process redesign and implementation support.

Conversely, the Business Analyst is not tasked with:

Developing a comprehensive design document specifying detailed requirements of the application like form layouts and navigation, data models, entity relationship diagrams and other design artifacts.
Managing the project schedule

To clarify, the Business Analyst may use whatever design tools necessary to understand the problem domain in order to execute their responsibility of defining functional requirements for a system, but it is not important or desirable to derive the models to the detail level. The primary importance of the Business Analyst is to insure that the business processes being automated are correctly engineered and to mitigate inter and intra organizational conflicts.

I wonder how XP practitioners would view this - as being part of the XP process or as a pre-cursor?

-- RonDace

According to the TgpMethodology the BusinessAnalysts are incorporated into the development process. The BusinessProfessionals (formally called "Technical Business Analyst" TBAs) are BusinessAnalysts that take responsibilities in the development process (TgpProcess). Actually, the TGP methodology transform the BusinessAnalysts into Non Programmer Developers that take an active role in the design, configuration and testing the software. They are using the same FrameWork the programmers are using. -- OriInbar

Good description indeed.

BusinessAnalyst is the correct intermediate between users (and so they were in charge of the process change management) and the IT guys involved in a project. They are often responsible of this very difficult mapping between the world of the users (where software is somehow a strange esoteric thing to play with) and the world of IT.

For the link between the BusinessAnalyst and ProjectManagement activities, it can depend on the context. I think there are two kinds of contexts :

One shot project : your BusinessAnalyst can do both RequirementsAnalysis and ProjectManagement ;
Multiple projects contexts in a company that makes its core business softwares evolved by release : your BusinessAnalyst should be responsible of ReleaseManagement of a particular functional area. In that case, he may not be in charge of ProjectManagement concerns (except if the projects allow him to keep a long horn vision of the functional area he is in charge of). -- OlivierRey