Product requirements document
From Wikipedia, the free encyclopedia
A product requirements document (PRD) is a document in product planning that provides a high level description of the solution, intended use, and the set of features it provides. The PRD offers a solution that addresses the market problem and satisfies needs. The PRD defines product functionality and features, from the solution’s perspective. This is the “product view” of the solution. [1]
A PRD is often created after a market requirements document (MRD) has been written and been given approval by management, and is usually written before (or at least concurrently with) a technical requirements document. It is designed to allow people within a company to understand what a product should do and how it should work. PRDs are most frequently written for software products, but can be used for any type of product.
Typical components of a software product requirements document are:
- Title & author Information
- Purpose and scope, from both a technical and business perspective
- Stakeholder identification
- Market assessment and target demographics
- Product overview and use cases
- Requirements, including
- functional requirements (e.g. what a product should do)
- usability requirements
- technical requirements (e.g. security, network, platform, integration, client)
- environmental requirements
- support requirements
- interaction requirements (e.g. how the software should work with other systems)
- Constraints
- Workflow plans, timelines and milestones
- Evaluation plan and performance metrics
Not all PRDs have all of these components. In particular, PRDs for other types of products (manufactured goods, etc.) will eliminate the software-specific elements from the list above, and may add in additional elements that pertain to their domain, e.g. manufacturing requirements.
A PRD sometimes serves as a marketing requirements document as well, particularly if the product is small or uncomplicated.
'Levels of Requirements Definitions'
- MUST - This word "MUST", or the adjective “REQUIRED”, or "MANDATORY" means that the definition is an absolute requirement of the specification.
- MUST NOT - This phrase means that the definition is an absolute prohibition of the specification.
- SHOULD - This word "SHOULD", or the adjective “DESIRABLE”, means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications must be understood and carefully weighted before choosing a different course.
- MAY - This word "MAY" or the adjective “OPTIONAL”, means that this item is one of an allowed set of alternatives. An implementation that does not include this option MUST be prepared to inter-operate with another implementation that does include the option.
[edit] See also
- Market requirements document
- Requirements management
- User requirements document
- Product planning
- Product Architect
- Product management
[edit] Templates & How-Tos
- Joel on Software: Painless Functional Specifications - Written in 2000, one of the seminal articles on writing software requirements docs
- Process Impact: SRS Template - (MS Word)
- Basic PRD format
- "PRM Product Requirements" - PRD Template
[edit] References
- ^ Gabriel Steinhardt (2008). "Product Definition Team" (PDF). 2.0. . Blackblot Retrieved on 2008.