Marketing Requirements Document

Marketing Requirements Document

General Information
Product:
Version: / Product Name
Document Version: / 1.0
Document Date:
Author: / Product Manager
Distribution
Director, Marketing
VP, Marketing
Chief Technical Officer
VP, Development
Program Manager
Project Manager
VP, Sales
VP, Client Services
Intl Marketing Mgr
VP, Intl Business
Documentation Mgr
Customer Support
QA Manager
VP, Business Development

Note: The Marketing Requirements Document is a high level document owned by Product Management.. It is based on the product strategy and is specific to a particular release. The MRD identifies the initial project definition on which Development activity will be based.

XYZ Software Incorporated

Company Confidential

______

Product Name, Release, MRDCompany Confidential

Date of last revisionMrd_template_1.doc

Page 1

XYZ Software Inc

Marketing Requirements Document (MRD)

1.Revision History

2.Overview

3.User Profiles and Use Cases Referenced in this Document

4.Required Feature/Functionality Specification

5.Future Functionality and Features

6.Exclusions

7.Assumptions and Dependencies

8.Documentation and Training Requirements

9.Supported Configurations

9.1.1.Minimum Configuration - Client

9.1.2.Recommended Configuration - Client

10.Platform Testing

10.1.1.Client Operating and Browser Systems

10.1.2.Operating, Server and Database Systems

11.Product Configuration

12.Definitions

______

Product Name, Release, MRDCompany Confidential

Date of last revisionMrd_template_1.doc

Page 1

XYZ Software Inc

Marketing Requirements Document (MRD)

All sections of this MRD are not required. It is up to the Product Management and Program Management to determine the appropriate sections for a particular release. However, at a minimum, the Overview and Feature Specifications should always be included.

1.Revision History

This section identifies by date key revisions to the document over time. For example:

01/05/96 - First Draft

2.Overview

This section provides an overview of the release. This section taken alone could be used as an executive summary of the release and distributed as such.

What are the issues/problems in the marketplace this release will resolve? (Business opportunity)
How will this release increase our success and/or competitive advantage? (Business objectives)
Positioning and value proposition

What is the scope of this release? (high level)

Key features and their benefits (top 3-5)
Key exclusions
Is this release feature dependent or is it time dependent?

How does this release interact/interface with other XYZ products/modules?

3.User Profiles and Use Cases Referenced in this Document

This section describes the typical users of the product, and the common tasks each type of user will perform when using the product.

Example:

Staff user: a business traveler or administrative assistant of low-to-average PC literacy, using a desktop or laptop PC, who needs to perform the following tasks:

Entering the data

Changing the data

Submitting the form

Checking status of the form

Supervisor user: a manager, sometimes also a business traveler, of low-to-average PC literacy, using a desktop of laptop PC, who needs to perform the following tasks:

Approving and rejecting forms

Overriding data

4.Required Feature/Functionality Specification

This section identifies and prioritizes the features and functionality required for this release. At a minimum, each item should have a description of the business problem, specifying the typical user profile and use case associated with the problem, and any special conditions or exclusions that apply to potential solutions. The information should be sufficient for the audience of this document (the Development team which includes Program Management, design, coding, test, and documentation) to proceed with their preliminary efforts. In particular, the content analyst should be able to take this information and begin a functional specification.

The format of the feature/function discussion should make it easy to identify discreet elements of work from an analyst’s point of view, if possible.

Use a numbering scheme that allows each requirement to be easily identified.

5.Future Functionality and Features

This section prioritizes the features and functionality that are “in-plan” and “out-plan” for this release.

In-Plan:Highly desirable, but not required in this release.

In-plan items should be described and documented the same as “Required” items in section 6.

Out-Plan: Not required in this release.

6.Exclusions

This section includes items that are excluded from this release. There could be several reasons: the feature does not work, we no longer support a certain platform, we replace a feature with another feature, the feature is outside the scope of this product. Placing it in the exclusion list makes it clear to the document audience that this item will not be included in the release.

For example:

Support for Windows 3.1 will be dropped beginning with this release of the product.

7.Assumptions and Dependencies

This section includes items that may not be part of the release but should be considered, by product management and development, in the planning of the release.

For Example:

Integration of a product
Retirement of a version
Third party product planning and integration

8.Documentation and Training Requirements

This section includes all documentation and training materials required for the release, for both customer and internal use. It also includes requirements for new documentation and training technology.

9.Supported Configurations

A list of supported configurations. This list must be detailed as this will be the basis for recommendations to customers, documented requirements, and tested configurations. Each Server and Client machine should have a minimum and recommended configuration.

9.1.1.Minimum Configuration - Client

For example:

Intel Compatible P2, 64 MB RAM, 2G hard disk

Windows NT 4.0, Service Pak 3,

SVGA Monitor

IE 3.02

9.1.2.Recommended Configuration - Client

For example:

Intel Compatible P2, 128 MB RAM, 4G hard disk

Windows NT 4.0, SP 3

IE 4.0

10.Platform Testing

This section provides information on supported platforms and platforms to be tested and documented for this release.

10.1.1.Client Operating and Browser Systems

A list of supported operating and database systems.

For example:

OS:Windows 95 and Windows NT

Browser:IE 4.0, Netscape 4.0

10.1.2.Operating, Server and Database Systems

A list of supported network operating systems and version. You should be specific in these versions.

For example:

OS:Windows NT 4.0

Server:IIS Server

Database:SQL Server 6.5

11.Product Configuration

This section identifies the total product configuration, including who will be getting this release, and what type of release it is.

For example:

This is a maintenance release and will go to all maintenance subscribers and partners in the form of an in-place upgrade to their existing version 2.x installation.

This release will be storefronted for partners to be identified.

Out-plan items require only a bullet listing for future awareness.

12.Definitions

This section includes critical definitions of items covered in the MRD. For Example:

MRD - Marketing Requirements Document. This is the document that details the requirements for a given release identified in the Product Strategy. Also include specific business terminology that customers use.

______

Product Name, Release, MRDCompany Confidential

December 2, 1998

Page 1

XYZ Software Inc