410.0 Analysis

Bibliotecas

 

Have you ever worked on a project where the final deliverables did not meet client expectations? If so, the problem may have been that the project team was not able to meet the expectations of the client. However, the problem is often more basic than that. 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 Definition, but more importantly in the more detailed business requirements.

The Analysis Phase is where the project lifecycle begins. The only exception is a situation where you have broken a large project down into smaller components. In that case, you may have an entire project that is only focused on the Analysis Phase, while the next project may start at the Design Phase. The Analysis Phase is where you break down the high-level Project Definition 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 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 407.2 The Role of an Analyst. Additional information is listed below to place this section in context:

 

• 410.1 What is a Requirement?

• 410.2 Use Cases

• 410.3 Asking the Right Questions

• 410.4 Active Listening

 

411.0 Gather Requirements

• 411.1 Elicitation

  • 411.1.1 One-on-One Interviews

  • 411.1.2 Group Interviews

  • 411.1.3 Facilitated Sessions

  • 411.1.4 JAD Sessions

  • 411.1.5 Questionnaires

  • 411.1.6 Prototyping

  • 411.1.7 Following People Around

• 411.2 Validation

  • 411.2.1 Consolidate the Requirements

  • 411.2.2 Rationalize the Requirements

  • 411.2.3 Model the Requirements

    • 411.2.3.1 Process Models

    • 411.2.3.2 Data Models

    • 411.2.3.3 Other Models

• 411.3 Specification

  • 411.3.1 Prioritize the Requirements

  • 411.3.2 Ensure Traceability of the Requirements

  • 411.3.3 Ensure Testability of the Requirements

  • 411.3.4 Create Business Requirements Report

• 411.4 Verification

  • 411.4.1 Conduct Requirements Review

  • 411.4.2 Obtain Sponsor Signoff

 

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

• 415.1 Create Testing Strategy

• 415.2 Create Training Strategy

• 415.3 Create Data Conversion Strategy

• 415.4 Create Implementation Strategy

 

416.0 Capture Additional Client Information

• 416.1 Develop Acceptance Criteria

• 416.2 Develop Information Retention Criteria

• 416.3 Create Security Risk Assessment

  • 416.3.1 Other Organizations with Security Responsibilities

418.0 Re-plan for the Remainder of the Project

 

419.0 Obtain Approval to Proceed

 

Supporting Templates

• Business Requirements Report

• Testing Strategy

• Training Strategy

• Data Conversion Strategy

• Implementation Strategy

• Conceptual Systems Design

• Acceptance Criteria

• Information Retention Questionnaire

• Project Data Retention Sheet

Anterior: 407.2 The Role of an Analyst

Próxima: 410.1 What is a Requirement?