{"id":7754,"date":"2018-08-15T11:45:52","date_gmt":"2018-08-15T16:45:52","guid":{"rendered":"https:\/\/actuationconsulting.com\/?p=7754"},"modified":"2018-08-15T11:45:52","modified_gmt":"2018-08-15T16:45:52","slug":"market-requirements-document-mrd","status":"publish","type":"post","link":"https:\/\/actuationconsulting.com\/market-requirements-document-mrd\/","title":{"rendered":"What is a Market Requirements Document (MRD)?"},"content":{"rendered":"

Of all the documents you create while developing a new product or product extension the Market Requirements Document (MRD) is most important of all. First, the MRD defines the overall target market. It also captures the market expectations for product attributes. Meeting these expectations is critical to increasing the odds of success in the marketplace.<\/p>\n

What Does an MRD Look Like?<\/strong><\/h2>\n

Your MRD can take many forms. It can be a simple document, a wiki, a spreadsheet, a unique software tool, or something else you devise to fulfill this important step in your process. The potential of the project will dictate the form your MRD should take.<\/p>\n

T<\/strong>he Core of the Market Requirements Document<\/strong><\/h3>\n

There are essentially two things at the core of your MRD:<\/p>\n

1 \u2013 A clear definition of your target market. This is basically a vivid picture of your potential buyer and user profiles. What are the key reasons someone would use the product?<\/p>\n

2 \u2013 Defined problem scenarios \u2013 What are the main challenges your users face that will cause them to turn to your product. These likely will vary between buyers and end users. You\u2019ll want to develop problem scenarios for each.<\/p>\n

Functional and Non-Functional Requirements<\/strong><\/h3>\n

Requirements that must be dealt with in the Market Requirements Document fall into two categories: function and non-functional. Here\u2019s the difference.<\/p>\n

Functional requirements<\/strong> cover capabilities that have interactivity with the user. They deal with specific high-level functions a user may want to perform.<\/p>\n

Non-functional requirements<\/strong> are concerned with design restrictions and performance factors involved with the product. Performance factors cover how well a product must perform. Design restrictions revolve around how much a product must support.<\/p>\n

Common Non-Functional Requirement Categories<\/strong><\/h3>\n

There are many different categories of non-functional requirements including many that are industry specific. Here are some of the most common categories:<\/p>\n