Product Requirements Document (PRD): A Complete Guide

Business and engineering teams use a product requirements document (PRD) to agree what a product must do and the qualities it must have, without prescribing the design. In regulated programs, the PRD also has to be maintained after approval, because that is how teams show controlled change, approval before implementation and assessed impact.

Medical, automotive and airborne development standards require teams to control changes to the PRD, even though none of them demands a frozen document. What follows covers what a PRD contains, how it differs from a market requirements document (MRD) and a software requirements specification (SRS), and how one requirement moves through a change.

What Is a Product Requirements Document?

A PRD is the product-level requirement set between the needs captured in business and market documents and the system and software specifications that decompose it. Each requirement in it has enough measurable detail for engineering to design to it and for test teams to verify it. Its approved version is a contract between the business users and the product developers, especially in programs where the two sides are different companies and both sign the baseline.

The PRD layer is called design input requirements in the International Council on Systems Engineering (INCOSE) Guide to Writing Requirements V4 from June 2023. Design input requirements are the agreed-to obligations derived from the integrated set of needs, in the guide’s definition. ISO/IEC/IEEE 29148:2018, the requirements engineering standard, specifies the information items that requirements work produces and what each must contain.

The same content corresponds to design and development inputs in ISO 13485:2016, the medical device quality management standard. ISO 13485 sets them out in Clause 7.3, and the Quality Management System Regulation (QMSR) incorporates the standard. In medical device programs, the PRD maps to the design-input requirement set, with the MRD or business requirements document (BRD) above it as the needs set.

A requirement that says an infusion pump shall reject an out-of-range rate states product behavior. Specifying that the rate limit be stored in a lookup table crosses into the SRS and the design, and the PRD is the wrong place for it.

What a PRD Contains

At the document level, a regulated PRD covers functional, performance, usability and safety requirements for the intended use. The PRD also includes regulatory and standards requirements, outputs of risk management, and information taken from similar previous designs. Under the same ISO 13485 clause, design inputs include that content.

Dozens of attributes can attach to a requirement under the INCOSE guide, while the NASA Systems Engineering Handbook uses a compact metadata table. The following attributes do most of the work in a PRD that has to survive change:

• Unique identifier: A stable identifier outlives document renumbering, so test cases, risk items and SRS children can point directly at the requirement.
• Rationale: The field records why the requirement exists and what it assumes. Purpose phrases stay out of the requirement statement under INCOSE rule R20, so the reason for the requirement goes in its rationale attribute.
• Owner: The owner is the person or group responsible for writing, managing or approving changes, according to the NASA handbook. A requirement with no owner leaves nobody to answer the impact question when it changes.
• Parent and source trace: Each requirement links to its parent need from the moment it is written, and the author maintains that link in both directions, as the NASA handbook recommends.
• Verification method and success criteria: The author chooses test, inspection, analysis or demonstration while writing the requirement and defines the measurable condition that counts as a pass.
• Version and change history: Version number, approval date, last change and stability show how the requirement has evolved after approval.

Without these attributes, the requirement’s next change gets assessed from memory. The full set also gives design, risk and verification records stable points to connect to.

Traceability makes change impact assessment practical and a rationale documents every post-baseline change. Requirements must also be complete, unambiguous, verifiable or validatable, and free of conflict with one another under ISO 13485. Ambiguous, incomplete or unverifiable requirements, including requirements not tied to validation methods, contribute to software project failures. You can improve requirement quality with the rules and characteristics in the INCOSE requirements writing guide and the six patterns of the Easy Approach to Requirements Syntax (EARS).

Watch the Webinar

Who Writes, Reviews and Approves a PRD

The product manager typically owns the PRD, though that ownership is editorial in a regulated program. Systems engineering, regulatory affairs, quality assurance and safety engineering each contribute requirements and sign off on the set, and hardware, software and test teams join the review before approval. In a responsible, accountable, consulted and informed (RACI) model for design control accountability on a medical program, quality is accountable for the design and development process. Research and Development (R&D), systems, test and manufacturing teams implement it.

ISO 13485 Clause 7.3 requires design inputs to be reviewed for adequacy and approved. In the US, the QMSR has incorporated that clause since February 2, 2026. Teams plan and document design reviews at suitable stages, with representatives of the functions concerned with each stage and other specialist personnel. In highly regulated systems, the approving authorities may sit outside the company.

The document’s approver and the requirement’s owner have distinct responsibilities. An approver signs the design-input baseline, while the owner answers for a single requirement through each later change under the team’s change management process. Relevant cross-functional reviewers confirm a change’s implementation before the change request closes under the Automotive Software Process Improvement and Capability Determination (ASPICE) 4.0. The process works only when every requirement names someone to ask.

PRD vs. MRD vs. SRS

The MRD states the market need, the PRD states what the product must do about it, and the SRS decomposes that into software behavior. Product development practice sets the working boundaries below, and while the names vary, each layer needs a distinct audience and trace position.

Attribute	MRD	PRD	SRS
Audience	Product managers, executives, marketing	Cross-functional product team	Developers, testers, compliance leads
Question it answers	Is there a market need, and for which personas?	What must the product do and how well?	What must the software do, with its interfaces and constraints?
Position	Before the PRD	Between the MRD and the SRS	Decomposes the PRD and inherits its trace links

Marketing typically writes the MRD with the product manager, who quantifies the market problems the PRD has to answer. The SRS then decomposes the PRD’s behavior into testable software requirements. Developers build to its interfaces and constraints as well as its functional and non-functional requirements.

Some teams use MRD and PRD interchangeably or maintain only an MRD and a product specification. Whichever names a team uses, the layers need traceability. A PRD requirement with no child in a system or software specification is unimplemented, and an SRS requirement with no PRD parent is unjustified.

Learn About SRS Documents

A Worked Example: One Requirement in a PRD

A single PRD requirement that has its full set of attributes shows exactly which items a later change will affect. The infusion pump entry below follows the EARS unwanted-behavior pattern, and its identifiers and values are illustrative.

Attribute	Entry
Identifier	PRD-114
Statement	If the entered infusion rate is outside 0.1 to 500 mL/hour, then the Pump_Controller shall reject the entry and display the Rate_Limit_Message within 1 second.
Rationale	An entry outside the clinically supported range is the dose-error hazard recorded as HAZ-021. The 1-second limit keeps the clinician’s attention on the entry field. How the limit is stored is a design decision and is not stated here.
Owner	Systems engineer, infusion subsystem
Trace to parent	User need UN-07 (clinicians program infusion rates without introducing a dose error) and risk control RC-021
Verification method	Test. Boundary entries of 0.09, 0.1, 500 and 500.1 mL/hour produce the expected accept or reject response, with the message displayed within 1 second.
Downstream links	SRS-233 (software input validation), test cases TC-114-01 and TC-114-02, labeling requirement LBL-09 stating the supported range
Applicable requirement	Design input under ISO 13485:2016 Clause 7.3, software requirement traceability under IEC 62304, the medical device software lifecycle standard
Version and status	Version 1, approved at design input baseline 1.0, stability medium

If clinical advisory input raises the supported ceiling to 999 mL/hour for high-volume therapies, the statement changes, along with the boundary values in the verification entry and TC-114-02. SRS-233’s validation bound and LBL-09’s stated range must change to match. Because the hazard severity at higher rates might differ from the original rationale, HAZ-021 and RC-021 also need review. The owner records a change rationale, the requirement becomes version 2, and the next baseline includes it.

Finding those five dependent items in a document requires somebody to read it. An item-based PRD already names them in its trace and downstream links. The owner of SRS-233 receives the new ceiling as a flag on the item. In a revised file, the same change is one line among many. The regulation is identical in both cases, and the links determine whether the required impact assessment takes an afternoon or a reading of the whole file.

How a PRD Stays Current Through Change

Teams keep a PRD current only by assessing and controlling each change. Each regulated regime puts its controls on the change itself:

• Medical device controls: Teams review design changes for their effect on delivered product and risk management outputs, then approve them before implementation under ISO 13485 through the QMSR.
• Automotive change control: Each change request must trace to the work products it affects and remain tracked to closure under ASPICE 4.0. The linked items must also stay consistent with each other under ASPICE 4.0, a check that goes beyond confirming the links exist.
• Airborne software and hardware control: Changes to previously approved airborne software go through a change impact analysis before the change is accepted, as Federal Aviation Administration guidance for DO-178C, the airborne software standard, expects. DO-254 covers configuration management, problem reporting and change assessment for airborne electronic hardware.

Under each regime, teams also record who reviewed the impact, what changed and why the resulting set remains acceptable. A design-input procedure with no mechanism for incomplete, ambiguous or conflicting requirements, along with a missing design-change procedure, drew a February 2026 FDA warning letter. Without those procedures, nothing obliges reviewers to find the dependent items a change touches.

Where product teams revise requirements on a sprint cadence, a requirements document written, signed and filed once can be out of date within weeks of approval. Practitioners in 58 German companies rated moving targets, requirements that keep changing, a median 4 out of 5 for how strongly the problem applied to their projects. The ratings come from the 2012 and 2013 run of the Naming the Pain in Requirements Engineering (NaPiRE) survey. Updating the product backlog was the most common response to requirements changes after the first release when the survey ran in 10 countries in 2014 and 2015. Only 19% of respondents in that run regularly changed the requirements specification.

In the infusion pump example, the five dependent items are already named on the requirement, so nobody has to search the document for them. When a requirement changes, each affected owner reviews the linked records, updates them or documents why no change is needed. The next approved baseline then captures the revised set and its decision history. On a multi-team program, a skipped review may be found only at integration, when one team has built to the revised requirement and another to the baseline it replaced.

How Jama Connect Supports Product Requirements Documents

When the ceiling rises to 999 mL/hour, the five items that depend on it have to be found without anyone rereading the PRD. Jama Connect®, a web-based requirements management and traceability platform, can configure each requirement’s identifier, rationale, owner, source trace and verification method as fields on a custom PRD item type. Each item then holds its parent needs, SRS requirements, test cases and risk items as relationships and keeps a complete version history. The Traceability Information Model (TIM) specifies which links each PRD requirement should have. Review Center records each approver’s electronic signature on the reviewed PRD requirements, and the activity stream keeps a chronological record of every edit and comment.

Impact analysis identifies the downstream items a change like that can reach across one or more degrees of separation. Suspect links then mark the linked requirements and test cases for their owners to reassess, and Baseline Compare shows what changed between two baselines of the PRD. Keeping every linked owner current on a change is a weekly cost. GridUnity cut requirements-change management time by 90%, from ten hours to one hour per person each week. The owner reviews that each PRD requirement change triggers downstream are where that time goes.

Decide When to Baseline Your Product Requirements Document

Each PRD requirement is ready to baseline when it is stable enough for other work to safely depend on it. Scheduling a baseline by calendar date alone doesn’t show whether a requirement has reached that point for SRS development, verification planning or regulatory review. Per-requirement stability and version history let you approve settled requirements while volatile items remain under review, so downstream work can proceed without hiding uncertainty.

Teams moving from calendar-date baselines to per-requirement ones can record each requirement’s status and stability on the item itself in Jama Connect. You can start a free 30-day trial and baseline only the settled requirements of a live project.

Frequently Asked Questions About Product Requirements Document

Does a PRD still apply when the team works in sprints?

Yes, a PRD still applies because agile development can produce design inputs and outputs continuously in pairs under the Association for the Advancement of Medical Instrumentation technical information report TIR45:2023. The report appears on the FDA’s list of recognized consensus standards, with Recognition No. 13-143 added May 26, 2025. When sprint refinement risks separating requirements from downstream work, Jama Connect supports Traceable Agile™ workflows that keep those records connected.

What is the difference between a PRD and a BRD?

A BRD records the business case, program rationale and regulatory obligations the company is taking on. The PRD translates that case into product-level behavior, and each requirement should trace to the BRD item or user need that justifies it. In the build order from BRD to SRS, each layer’s project requirements inherit content and trace links from the layer above.

How detailed should a PRD be?

A PRD should be detailed enough that every requirement has a pass-or-fail answer, without prescribing the design. One thought per statement, with the rationale stored separately, gives reviewers a practical boundary for detail. For automated quality feedback, Jama Intelligence, an add-on for Jama Connect Cloud, can assess requirement quality during authoring.

When should a PRD be updated?

New scope, a user story that reveals a missing or conflicting requirement, or a risk analysis that identifies safety-critical failure modes should each reopen the PRD. The PRD also reopens on regulatory feedback, a design change that invalidates a requirement, or post-market data that reveals a use-related issue. Each trigger should produce a change request, an impact assessment and approval before downstream work moves.

If I want to learn more about product requirements document, what else should I read?

For organizing and governing requirements across a whole program, read the requirements management best practices guide. Enterprise requirements management describes a broader operating model.

This article was authored by Mario Maldari and published on October 27, 2026.