Product requirements document
From Wikipedia, the free encyclopedia
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
