Product requirements document

A PRD should, however, generally avoid anticipating or defining how the product will do it in order to later allow interface designers and engineers to use their expertise to provide the optimal solution to the requirements.

Typically, a PRD is created from a user's point-of-view by a user/client or a company's marketing department (in the latter case it may also be called a Marketing Requirements Document (MRD)).

The requirements are then analyzed by a (potential) maker/supplier from a more technical point of view, broken down and detailed in a Functional Specification (sometimes also called Technical Requirements Document).

In the case of an agile development model, requirements are formulated initially at a higher level to allow for prioritization and then elaborated in detail at the beginning of each new cycle.

[4] PRDs also help prevent critical technical issues in software development, including architecture mismatch with product requirements, overlooked technical dependencies, and underestimated implementation complexity.