1.7 The Project Requirements Document (PRD)

The following is an outline for a PRD. The PRD is started in Phase 1 and completed in Phase 2. Many of the questions the PRD asks cannot yet be filled in since the team has yet to be established. The Phase 1 lead uses the Business Requirements Document and the Feature/Functionality Report to create the PRD.

Purpose

The purpose of the PRD is to define the requirements for a project. From these requirements a set of specifications will be produced that indicate how each requirement will be met or what can be achieved with the technology available.

It is the responsibility of each functional area to provide plans that will support the successful completion of this new application, including integration of milestones that represent dependencies for completion of their tasks .

This document will be refined by input from each functional area until it is finalized at the end of Phase 2, Design.

Scope and Description

Project Overview: (If this is a follow-up release, please present only the differentiators between this release and the previous release. If this is a new release an initial listing of the project will need to be presented.)

The Market: What is currently going on in the industry that relates to this project?

Target Users: Who will use this project? Specify their generic demographics .

Project Vision: What is the role of this project? What need will this project fill?

Project Objectives: How will this project fill the role and need?

Fit Within Existing and/or Future Project Line: Where does this project fit into the overall corporate scheme? What are the company s goals and how does this project meet those goals?

Market Positioning: How does this project support the company s market vision and direction?

Performance Goals: What are the specific performance goals of this project?

Preliminary Schedule:

Phase: Date:

Phase 1 ”Project Concept

Phase 2 ”Design

Phase 3 ”Development

Phase 4 ”Quality Assurance

Phase 5 ”Beta

Phase 6 ”Release

Phase 7 ”General Availability

Phase 8 ”EOL

Features: List the recommended features here.

Industry Standards: If applicable , provide standards organizations and how this project conforms.

Compatible Platforms: What hardware and software platforms does this work with? List name and release number.

Prerequisites: What prerequisites are necessary for this project to work?

Scalability: What are the limits to the project s growth? Hardware and software that can support 1 to 1,000 users is considered very scalable. Scalability identifies the ability of a solution to grow from small to large with minimum changes.

Help Desk: What will be needed from the Help Desk department to release and support this project?

Serviceability: What features will be needed to service this project?

Connectivity: What will this project need to connect to? What connectivity will be needed to support this project?

Required Functionality: Itemize the requested functionality by user /internal/strategic/industry requirements.

Hardware/Software: What hardware and software will be needed to support and service this project?

QA Requirements: List requirements for Quality Assurance to test for.

Documentation Requirements: List requirements for documentation.

Help Desk Requirements: List requirements for supporting the project.

Beta: List the beta requirements.

Key Risks/ Open Issues: List risks and open issues that could jeopardize release, costs, and for those projects found in a profit center, list potential revenue.

1.7 in a Nutshell

The Project Requirements Document is created in Phase 1.

• The Business Requirements Development and Feature/ Functionality Document are the foundation of a PRD.

• In Phase 2 the PRD becomes the project bible.

• The PRD will be used as the baseline of what the departments will commit to creating.