As the name suggests the Project Manager (PM) does indeed manage the project. In the case of software development the PM will manage the SDLC or Software Development Life Cycle which usually includes: Design Development Testing and Implementation.
The Business Analyst (BA) will be involved with all aspects of the SDLC starting with the Design phase. The Design phase will usually generate a Specification. Normally the BA acts as the author/editor of the Specification which may have several sections. The first section the Business Requirement is where the BA will be most prominent in the process. Its is the BA's job to work with the end users to formulate the Business Requirements. This process usually involves becoming an expert in the workflows of the end users thru interviews observations and analysis of the systems and /or tools used. The BA will document the business requirements but must always be sure they they have the end users concurrence that they have correctly defined the "WHAT". The WHAT being what the workflow or problem is.
Next in the Specification is the Functional Requirement. This is where the BA working with the end users and the developers begins to actually design the system that will satisfy the Business Requirement this is the "HOW". This Function Requirement will layout the various screens and features that will allow the end users to satisfy the Business Requirements i.e. HOW the system will satisfy the WHAT.
The next section of the Specification is the Technical Requirement. Normally the BA will assist the development team with advise but will not write the Technical Requirements. The Technical Requirement will lay out the databases tables and processes that will be used to run the system.
The first 3 sections of the Specification are clearly part of the Design phase of the SDLC but the final section of the Specification will be utilized in the Testing phase of the project. The final section of the Specification is the Test Script. This is where the BA gets to show that their work in the Business Requirement section was well thought out. Only if you have a good grasp of what it is supposed to accomplish the WHAT can describe how to test something
Of course most projects have very large Specifications which may have dozens of unique Business Requirements and multiple BA's may author these various threads of functionality. In those cases often the PM will act as an editor to the entire Specification ensuring the various BA's work fits together in a cohesive document.
