BRD
Business Requirements document, Business Requirement document. This is the first document to be asked during the product declaration cycle. It should have been conceived for a long time. It involves market analysis, sales strategies, profit forecasts, etc, it is usually a PPT with the old guys, so it is relatively short and refined, there is no product details.
The Business Requirements document focuses on defining the business needs of a project. BRD must be able to identify one or more business problems the customer has encountered and solve these problems through the company's products. Next, we suggest a solution, which is usually the improvement of new products or existing products, to solve these problems. BRD may also include an advanced business case, such as earnings prediction, market competition analysis, and sales/marketing strategies. BRD is generally written by a person with the title of product manager, product marketing manager, or industry analyst. In a small company, it may be written by a senior supervisor or even the Founder. BRD is usually a continuous 1-3 page Word document, or a PowerPoint document with no more than 10 pages.
MRD
Market Requirements document, market requirement document. After receiving the approval from the boss, the product should be implemented first, and MRD should be provided. Specifically, more detailed market and competitor analysis should be conducted, and which functions should be used to achieve business purposes, what are the functional/non-functional requirements and their priority. In actual work, the PD may generate things such as mind manager's mind chart and Excel's feature list.
The market demand document (MRD) focuses on defining market requirements for improvements to a proposed new product or existing product. Unlike BRD's solution to identifying business problems and solving these problems, MRD goes deeper into the details of the proposed solution. It includes some or all of these details:
A. features required to solve business problems
B. Market Competition Analysis
C. functional and non-functional requirements
D. Priority of features/requirements
E. Use Cases
MRD is generally written by a person with the title of product manager, product marketing manager, or industry analyst. MRD is usually a continuous 5-25 page Word document, or as described later, it is even longer in some organizations.
PRD
Product requirementsdocument, product requirement document. Progress 1 is refined. This part is the most frequently written content by PD, that is, Requirement Analysis in the traditional sense. Here we mainly refer to the UC (usecase) document. The main content is specific descriptions of function usage (each UC generally provides a brief description of useful examples, actors, preconditions, backend conditions, UI descriptions, processes, subprocesses, and branch processes, and so on. In terms of demo, you may use Dreamweaver, PS, or even graphic panels for simple painting. Sometimes there will be UI/UE support, and a high-fidelity demo, which can be directly used for development in the future.
The product requirement document (PRD) focuses on defining market requirements for improvements to a proposed new product or existing product. Unlike MRD, which focuses on market needs, PRD focuses on product needs. Generally, the features and functional requirements are more detailed, and may also include screen and user interface processes. In those organizations where MRD does not include specific requirements and use cases, PRD includes these specific content. PRD is generally written by people with product managers, industry analysts, or product analyst titles. PRD is usually a continuous 20-50 page Word document, or for complex products or even longer.
Note: Some organizations combine the MRD and PRD described here into a document, and the final document is MRD. In this case, MRD includes the content described in this section, as well as the content described in the previous section PRD, and may exceed 50 pages.
FSD
Functional specificationsdocument, detailed description of the function. One thing is like "Outline Design". This step starts to link to development. The details of the product UI and business logic should be determined, and documents should be refined and updated. Correspondingly, there is a lot of content, such as table structure design, which should be compiled by the Project Manager.
The Function Specification document (FSD) focuses on implementation and defines all the details of product functional requirements. FSD may define product specifications through one screenshot and one functional point. This is a document that allows engineers to directly create products. Unlike MrD and PRD, which focus on market needs and product needs, FSD focuses on defining product details in tabular form and then allowing engineers to implement these details. FSD may also include complete screen and UI design details. FSD is generally written by a person with the title of a product analyst, engineering leader, or project manager-the author generally belongs to the engineering department. It is usually a word or similar document with dozens of consecutive pages.