Purpose:

Define customer (business) and product (system) requirements, create an architectural design of the solution, prepare a development environment, and develop a Request for Proposals (RFPs).

Objective:

Supplier bids are submitted and evaluated, a detail project plan for the rest of the project is created, with strategies for testing and deployment.

Description:

At the beginning of the Define phase, supplier-sourcing activities are performed to select a supplier to conduct the Define Phase activities.  This phase is divided into three sub-phases: Requirements, Architectural Design and Supplier Selection.

In the Requirements sub-phase, requirements are distinguished between Customer (business) Requirements and Product (system) Requirements.  Customer requirements describe the major features of the system with high-level assumptions and constraints on the functionality of the system.  The product requirements comprehend performance, interface and operational requirements, as well as, functional requirements.  Success of the project relies on the accuracy and integrity of these requirements.  The quality of these requirements is pursued through activities to verify requirements through peer reviews, use cases and prototypes.

The Architectural Design sub-phase takes the product requirements and an understanding of the computing environment to create the architectural design.  The Architectural Design sub-phase leads into the Supplier Selection sub-phase, emphasizing the Outsource Model and resolving organizational  challenges in entering into agreements with suppliers before enough detail is known about the IT solution for those agreements to be accurate and effective.  Finally, the proposals from suppliers (for Construct, Test, and Deploy) are evaluated and the number of suppliers is reduced for price negotiation during the Supplier Selection sub-phase. 

Test and Deployment Strategies are also developed during the Define phase.  The Test Strategy identifies the specific types of tests to be performed and who will be executing each test.  Deployment teams are engaged early in the project during the Define phase to ensure that a viable Deployment Strategy is created.  The Deployment Strategy identifies the sites to which the system will be deployed and describes how the deployment will be rolled out. 

An activity that is often overlooked during projects is the planning to create development, test, pre-production and production environments.  Online-PMO includes these activities to prepare all the necessary computing environments through Define, Construct, and Test phases.  In the Define phase, preparation of the development environment is started, as appropriate, and is completed early during the Construct phase.

 The Define phase concludes with the second formal tollgate, the Define Tollgate, resulting in a Go/No-Go decision.

Entrance Criteria:

<?>

Exit Criteria:

  • <?>

Process and Procedures:

Tailoring Guidelines:

None

Process Verification Record(s):

  • Correspondence over e-mail clarifying Requirements
    • Stored By: Requirements Analyst
  • Minutes of Meeting – Business Requirements Review
    • Stored By: Requirements Analyst
  • Records containing review feedback on the Business Requirements Document
    • Stored By: Requirements Analyst
  • Completed Business Requirements Checklist
    • Stored By: Requirements Analyst
  • Completed Peer Review Summary Report Template
    • Stored By: Requirements Analyst
  • Records containing review feedback on BRD, SRS and RTM
    • Stored By: Requirements Analyst
  • Completed System Requirements Checklist
    • Stored By: Requirements Analyst
  • Approval Records from Business Project Champion and Process Engineer approving BRD, SRS and RTM
    • Stored By: Requirements Analyst

Measure(s):

  • Bugs Density – Customer Requirements

Number of Bugs identified in Customer Requirements Document divided by Total Number of Customer Requirements.

    • Maintained By: Project Manager
    • Submitted By: Requirements Analyst
    • Frequency of Submission: Reported in Senior Management Review for the project and analyzed during Weekly Progress Review Meeting.
  • Bugs Density – Product Requirements

Number of Bugs identified in the Product Requirements divided by Total number of Product Requirements. 

    • Maintained By: Project Manager
    • Submitted By: Requirements Analyst
    • Frequency of Submission: Reported in Senior Management Review for the project and analyzed during Weekly Progress Review Meeting.
  • Bugs Density – System Requirements

Number of Bugs identified in the System Requirements divided by Total number of Product Requirements. 

    • Maintained By: Project Manager
    • Submitted By: Requirements Analyst
    • Frequency of Submission: Reported in Senior Management Review for the project and analyzed during Weekly Progress Review Meeting

References:

  • <?>