How to Write a Product Requirements Document

Image by Gerd Altmann from Pixabay

The product manager is responsible for writing the product requirements document (“PRD”). The PRD writing phase is made after completing a few pre-steps: description of the market opportunities, define the user’s problem, gathering the user’s needs, and analyze it. The product manager and the project manager also need to create separate documents regarding the project management and the quality assurance test plan, addressing schedule, cost, development methods, development phases, deliverables, and testing procedures.

This article describes what a product requirements document should include.

Introduction

  1. System name
  2. Author
  3. Date
  4. Revision sheet (Version, date, revision description)

Purpose & Background

This section describes an overview of the purpose and the background of the requirements document of the system. It should include:

  1. Purpose, background, and audience
  2. A general business context
  3. A brief introduction to the organization and purpose of the different sections
  4. An overview of the system under development
  5. Project constraints, such as cost and schedule
  6. Applicable Documents

Scope

  1. This section defines the boundaries of the product
  2. What it will and will not the product do
  3. What is and is not going to be implemented
  4. The main functionality and capabilities of the system

Definitions, Acronyms, and Abbreviations

Some words may be unfamiliar or open to multiple interpretations. This section should define:

  1. Potentially unknown or ambiguous words
  2. Acronyms
  3. Abbreviations

Product Environment

This section describes the boundaries between the system and its environment and should include the following:

  1. Assumptions and dependencies
  2. Installation environment
  3. A block diagram that shows the significant interfaces between the system and its environment
  4. The system interfaces: API, input & output files
  5. The workflow of the system
  6. Hardware systems & Software systems
  7. Database management system interface
  8. The user interface, which characterizes an interface between the system and its environment

User Characteristics

The user’s characteristics section presents a complete and accurate image of the end-users. The general characteristics of the end-users includes:

  1. User roles, categories of users, and types of users
  2. Users responsibilities
  3. Users knowledge of the domain
  4. Users technical sophistication
  5. User’s background and education
  6. Prioritization

Constraints

  1. A list of constraints that are categorized as absolute, desirable, or optional
  2. Design constraints
  3. Implementation constraints
  4. Technologies constraints, for example, database management system, programming language, operating system, etc.

Nonfunctional requirements

  1. Operational Requirements: the characteristics of the physical environment for the product.
  2. Performance Requirements: speed, safety, precision, reliability, availability, capacity, scalability, maintainability, and portability.
  3. Security Requirements
  4. Other Quality Attributes

Functional Requirements

  1. A list of prioritized use cases
  2. A unique number to assist in tracking
  3. For each use-case or portion of the workflow: list of the relevant system requirements.
  4. The actions the product must take in response to inputs that come from users or other software systems.
  5. The answers for both valid and invalid input values.
  6. Wireframes
  7. Mockups
  8. Screenshots
  9. Illustrations
  10. Optional use cases for future use, growth, and maintenance.
  11. A cost estimate that is provided by the developer.

In summary, the product requirements document (“PRD”) includes the requirements which will be presented to the development team as part of the sprint planning meeting. The PRD is one way to share the product information from the product team to the development and QA team. A valuable product requirements document can provide the infrastructure for maintaining knowledge and documenting the system throughout the product life cycle.

Written by Maayan Galperin

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store