When the analysis phase of an application development project ends, a manager should know what the application looks like, how it functions, and how it is designed. The extensive information gathering and analysis of this phase provides extensive details on each of these aspects of the project. The final stage of the analysis phase is to organize this information into documents that will guide the work during the rest of the project.
The three important deliverables created during this phase are:
The business requirements report.
The conceptual systems design plan.
The strategy documents.
The business requirements report lays out the business criteria of the project and includes any work associated with process and data models. The conceptual systems design plan is the transition from business requirements to the more detailed technical design. The plan contains high-level architecture diagrams, screen design, and report layouts.
The strategy documents describe the overall direction of the project in a number of areas, including testing, training, data conversion, and implementation. These are direction-setting documents that can be worked on with the business client and provide the overall direction to the more detailed planning that occurs later in the design phase.
The analysis phase
Tom Mochal’s series on this aspect of project management has covered the following topics:
The nature of business requirements
Techniques for gathering requirements
Guidelines for process modeling
Business requirements report
The business requirements report ties together the requirements and the modeling done earlier in the process. It describes the requirements in several formats that can be understood by the project team and the business clients and should include the following pieces of information:
High-level requirements—This section defines the big-picture requirements that are common to the entire solution. An example of a general requirement is that everyone in the company must have access to the data. Each requirement should be numbered and prioritized. The numbering scheme can be used to track the requirements through the testing process.
Functional requirements—These are the more specific requirements. If the solution includes a number of major functional subprocesses, the requirements for each piece should be listed separately in this section. For example, functional requirements might state that all finance users have update access to the information, while users from the marketing department have read-only access. These requirements should also be numbered and prioritized for tracking during testing.
Acceptance criteria—This section should describe the client’s criteria for accepting the application, if it has not already been described elsewhere.
Process model—If you created process models of the solution, they should be included here, along with the appropriate descriptions.
Data model—If you created data models, they should be included here, along with any explanations.
Additional information—Depending on the project and the particulars of the analysis phase, you may also need to include any assumptions made in the analysis process and other models, such as context diagrams, process decompositions, and entity diagrams.
Conceptual systems design plan
The conceptual systems design plan provides a bridge between the business-focused requirements document and the IT-focused technical design document that will be created in the design phase. The business client is normally not very involved in the design phase, so the conceptual document is the client’s chance to ensure that the application is designed as it should be. Sections in this document include the following:
High-level technical architecture—This is a place to start laying out the technical solution. It should be diagramed at a high level that the business customer can understand.
Screen layouts—In the past, the IT team would lay out the screen design based on the easiest way to program the layout. However, a better way is to work with the business client to define what the screens should look like and then design and code to those general specifications.
Report layouts—The rules here are the same as the ones for designing screen layouts. Work with your clients to define the reports that are needed and the general columns and selection criteria of the reports.
Interfaces—At this point, you should have a general idea of the internal and external interfaces needed for the solution. For each interface, define in general terms the information that is passed and the timing of when it will be passed. If the other side of the interface already exists, the actual layout can be included.
High-level strategy documents
During the analysis phase, high-level strategies are put into place that will guide the detailed planning documents that are created later. These strategies typically include the following:
Testing strategy—The purpose of the testing strategy is to define the overall context for the entire testing process. The process depends on the specific characteristics of your solution. In many respects, this is the most important part of the testing process since all future testing decisions will be made within the overall context of the strategy. The testing strategy can include an overview, risks, milestones, testing approach, and the overall testing environment.
Training strategy—This document lays out the overall strategy for the training that will take place later in the project. The information includes a training overview, the training needs of the stakeholders, the types of training to be offered, and how the training will be built and delivered.
Data conversion strategy—In this document, you describe at a high level how data will be converted from the current applications to the new application. This would include an overview of the data conversion needs, the systems involved, the timing and the general approach to the conversion process, and the backup plan if the conversion does not work as it should.
Implementation strategy—When your application is completed, it may need a formal deployment strategy. This document provides a general overview of deployment, when it will occur, the complexities and risks, any assistance at the deployed sites, and other relevant details.
Critical products of the analysis phase
The analysis phase of your project should result in three important deliverables: a business requirements report, a conceptual system design plan, and high-level strategy documents for the entire process. These documents will guide the rest of the project and ensure that all work supports the end goal of producing an application that fits the client’s needs.
Project management veteran Tom Mochal is director of internal development at a software company in Atlanta. Most recently, he worked for the Coca-Cola Company, where he was responsible for deploying, training, and coaching the IS division on project-management and life-cycle skills. He's also worked for Eastman Kodak and Cap Gemini America and has developed a project-management methodology called
