Sample Marketing Requirements Document for PRODUCT X

Author:
Note: this is a sample MRD from a now-obsolete model on a product that no longer
exists. We are suggesting to update all elements to current technical and marketing
standards.

1.0 Scope

This is the Marketing Requirements Document for PRODUCT X Version 1.1. It

comprises requirements for the entire rst release, including maintenance upgrades,
multiple license packages and upgrade versions.

The purpose of PRODUCT X will be to (input here atheism of your product/positioning

and why the update needed)

2.0 Product Release Strategy

The product will be released in ___________.

It will be released through App Store & Google Play Markets to distribute world-wide.
French, UK and German versions will be released simultaneous to the US version. At the
time of the release, the following versions will need to be completed:

PRODUCT X Version 1.1 - iOS version

PRODUCT X Version 1.1 - Andorid version

Upgrades
(Input here a policy on upgrades from previous versions if exist)

2.1 Release 1.1 Overview

(Input here a descriptive features you want to have in the update)

Current Market Conditions

(The more detailed research you made, the better. Input here general market changes,
updates that competitors have, etc)

Timeframe Constraints
(Input here a timeframe you are planning to have the release. p.s. don’t forget to discuss
the timelines with your development team)

Currently unresolved issues.

(In case there are such, specify them)

3.1 Functional Requirements


fi
 Priorities of requirement.

• Priority 0 -- absolutely must be in release.

• Priority 1 -- Highly desirable, should consider removing from release only if

amount of effort
required is not consistent with timeframe requirements.

• Priority 2 -- Desirable for this release, should include if time and resources permit.

Required Changes

Priority: 0
- describe features here

Priority: 1
- describe features here

Priority: 2
- describe features here

Other Changes required:

- describe features here

3.2 Software Development Requirements

1. The source code shall be complete and clearly commented.

2. The source code shall be run through Testing Tools such as ______, ______,
__________, and must pass each product’s tests.

3. The program shall be built with commercially available tools and/or libraries.

4. Any libraries that are not commercially available must include source code.

3.3 Environmental / Compatibility Requirements

1. The product must support the next hardware environments: iPhone SE and above.

 2. The product must support the next hardware environments all Android devices that
supports Android 8 and above.

(If you have more requirements to specify, put them here or change above)

3.4 Special Quality Assurance Compatibility Requirements

(Ask your development team for their standards and put them here)

3.5 Performance / Resource Requirements

1. The program must not crash itself or the machine, and must not cause Windows
General Protection Faults.

2. The program shall respond appropriately to inadequate memory conditions and to

inadequate disk space. The product shall warn the user of the error condition, allow
the user to rectify it, or will the user fail to rectify the problem, the program shall
refrain from proceeding.

3. The program will act on user requests as quickly as could be expected given the
request. This will not be an unusually slow program.

(Specify other requirements based on devices you are going to support)

3.6 Internationalisation Requirements

The product must be released simultaneously in the United States, Canada, France,
Germany and the United Kingdom, and thus must be built for fast translation.

3.7 Problem Fix Requirements

1. Before the nal release of the program, all bugs marked as priority “Urgent”,
“High”, and “Medium" in the Quality Assurance bug-tracking database will be
xed. Bugs not xed, (marked as deferred) must be agreed upon by all parties.

2. Any problems detected during the beta test cycle that con ict with this document
or with the Functional Speci cation must be resolved by release time. This
resolution may include a change to the MRD.


fi
fi
fi
fi

fl

 3. The Company shall provide problem reports immediately upon request to all
developers who may be related to the product. Developers within The Company
will have access to the Quality Assurance Bug Tracking System.

4. All bugs with priority of “Urgent”, “High”, and “Medium” shall be considered
“show stoppers” and shall receive immediate attention.

5. Problems that are xed in a speci c beta release will be marked as “ xed” by the
developers on the bug report. That bug report will then be sent back to QA for
veri cation at the same time the code with the x is sent to QA.

6. Beta maintenance releases will be sent to QA in no longer than two week intervals
and no more often than one week intervals unless agreed upon by all parties
involved.

7. Bugs shall be xed as soon as they are found.

3.8 User Documentation Requirements

(Detail doc changes)

A functional spec will be required at least 2 months before the documentation goes to the
printer. QA must proof the documentation before going to press.

3.90 Special Beta Release Requirements

1. Each beta test cycle shall last not less than ve weeks.

2. There will be at least two outside beta cycles. Both of these releases will have a a
detailed list with the known bugs, xes from the last release, and a quick guide on
how to get up and running.

3. All User Interface issues will be resolved before releasing the rst of cial beta.

3.91 Maintenance Release Requirements

1. No subreleases are planned at this time. As with any new product, there is likely to be a
set of bug releases and maintenance xes that address issues that we will neither
recognize nor understand until the product has been in release for some time. As a matter
of general policy, we would desire minor bug xes within 60 days of the rst release, and
a signi cant upgrade release within eighteen months.

4.0 Other General Release Requirements



fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
 1. iOS build should be delivered by TestFlight app and Android app should be
transferred within Firebase Testing Environment.

2. The package is not to be released as version 1.1 until agreed upon by all parties
involved.

3. Developers shall be accessible via, at a minimum, phone, messangers, and e-mail

during regular working hours, or at times to be mutually agreed upon by The
Company.