 |
 |
 |
 |
410.0 ANALYSIS PHASE
Have you ever worked on a project where the final deliverables did not meet client expectations? If so, in many cases the project team did not adequately understand the expectations of the client. Understanding the expectations cannot be done while you are constructing and testing the solution. The expectations must be understood up front - first in the high-level Project Charter, but more importantly in the more detailed business requirements.
The Analysis Phase is where the project lifecycle begins. The Analysis Phase is where you break down the deliverables in the high-level Project Charter into the more detailed business requirements. The Analysis Phase is also the part of the project where you identify the overall direction that the project will take through the creation of the project strategy documents.
Gathering requirements is the main attraction of the Analysis Phase. The process of gathering requirements is usually more than simply asking the users what they need and writing their answers down. Depending on the complexity of the application, the process for gathering requirements has a clearly defined process of its own. This process consists of a group of repeatable processes that utilize certain techniques to capture, document, communicate, and manage requirements. This formal process, which will be developed in more detail, consists of four basic steps.
-
Elicitation – I ask questions, you talk, I listen
-
Validation – I analyze, I ask follow-up questions
-
Specification – I document, I ask follow-up questions
-
Verification – We all agree
Although gathering requirements is the main focus during the Analysis Phase, there are other important activities during this phase as well. One is to create a Requirement Management Plan to define how the requirements will be documented, communicated, tracked and changed throughout the rest of the project lifecycle. This plan will specifically address establishing a baseline, a change control process, and a way to track the requirements through the rest of the lifecycle. Another important activity is to set the overall direction for work that does not take place until later. This is accomplished through a series of direction-setting strategy documents. For instance, once you have your requirements, you can start to set the overall direction for training in a Training Strategy document. The strategies are at a high-level and are later defined at a lower level before they are finally implemented toward the end of the project.
Lastly, the project team creates an optional document that helps transition from the Analysis Phase to the more technical and detailed Design Phase. This document, called a Conceptual System Design, provides client feedback into many of the ways that the final solution will be implemented. This feedback includes much of the look-and-feel of the final solution.
Most of the work in the Analysis Phase is performed by the role of analyst. For background on the type of skills and responsibilities required for an analyst, refer to 408.2 The Role of an Analyst. Additional information is listed below to place this section in context.
412.0 Evaluate Reuse, Buy (Rent), Build Alternatives
413.0 Create Requirements Management Plan
414.0 Build Conceptual Systems Design
415.0 Develop High-Level Project Strategies
416.0 Capture Additional Client Information
418.0 Re-plan for the Remainder of the Project
419.0 Obtain Approval to Proceed
-
Business Requirements Report
-
Testing Strategy
-
Training Strategy
-
Data Conversion Strategy
-
Implementation Strategy
-
Conceptual Systems Design
-
Acceptance Criteria
-
Information Retention Questionnaire
-
Project Data Retention Sheet
[Previous -
409.0 Mapping to
Other Lifecycle Models]
[Next -
410.1 What is a
Requirement?
]
