The Essence of a Marketing Requirements Document (MRD)

A few thoughts about writing MRDs.

NOTE: The MRD should describe WHAT needs to happen overall and between parts. The MRD should not (usually) describe HOW all the parts get implemented - that is for the engineering design document.

1. Describe the end-to-end scope of the problem to be solved
2. Break the problem into logical sub-problems
3. Describe the inputs required to resolve each sub-problem. This includes:
• human interfaces for data input 
• one time 
• interactive / iterative 
• machine / data inputs from external data
• machine / data inputs from internal (transient) data
4. Describe what output should be generated by resolving each sub-problem. This includes:
• which data is needed as "the" output. i.e. the "permanent" data. 
• What is the expected input format of the consumer(s)?
• which data is needed to address another sub-problem. i.e. transient data.

All of this should be written with an eye to the system in which the functionality described by the MRD lives.

• Every input is the output of another system, ideally described by an MRD (reference it if you can).
• Other systems may need the output of the system described by your MRD. Include these systems as examples in your MRD to give color to the bigger picture problem being solved.
• Human input interfaces (User Interfaces), Machine Input interfaces (APIs) and Permanent Data stores (HDDs or Databases) may be shared between multiple systems. If they are, or should be, note that explicitly.

One obvious challenge, given the recursive approach to MRD writing given here, is figuring out where to stop.

How big should the scope of THE problem be?

My experience: when in doubt, make the scope too big. Then scale back the scope during reviews based on feedback from the stakeholders.