Product requirements document

Product requirements document

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.

See also

* Market requirements document
* Requirements management
* User requirements document
* Product planning
* Product Architect
* Product management

References

External links

* [http://software.forbes.com/requirements-management-software Forbes Requirements Management Software Directory]
* [http://software.franteractive.com/Hardware%20PRD/pg_0001.htm Fifty Pages Long Industrial Strength PRD Template]


Wikimedia Foundation. 2010.

Игры ⚽ Нужен реферат?

Look at other dictionaries:

  • User requirements document — The user requirements document (URD) is a document used in software engineering that specifies the requirements the user expects from software to be constructed in a software project.An important and difficult step of designing a software product …   Wikipedia

  • Market requirements document — Marketing Key concepts Product marketing · Pricing …   Wikipedia

  • Product marketing — deals with the first of the 4P s of marketing, which are Product, Pricing, Place, and Promotion. Product marketing, as opposed to product management, deals with more outbound marketing tasks. For example, product management deals with the nuts… …   Wikipedia

  • Requirements management — The purpose of Requirements management is to assure the organization leverages to the expectations of its customers, internal or external stakeholders. It focuses on requirements as the element capturing these expectations, and thus, as a focal… …   Wikipedia

  • Product manager — A product manager researches, selects, develops, and places a company s products. A product manager considers numerous factors such as target demographic, the products offered by the competition, and how well the product fits in with the company… …   Wikipedia

  • Product Family Engineering — Product families/lines are quite common in our daily lives, but before a product family can be successfully established, an extensive process has to be followed. This process is known as product family engineering, product line engineering, and… …   Wikipedia

  • Product lifecycle management — (PLM) is the process of managing the entire lifecycle of a product from its conception, through design and manufacture, to service and disposal. [cite web title = About PLM publisher = CIMdata url = http://www.cimdata.com/PLM/aboutPLM.html ] PLM… …   Wikipedia

  • Product certification — or product qualification is the process of certifying that a certain product has passed performance and quality assurance tests or qualification requirements stipulated in regulations such as a building code and nationally accredited test… …   Wikipedia

  • Software product management — is the process of managing software that is built and served as a product as opposed to a serviceoftware productsA software product is typically a single application or suite of applications built by a software company to be used by *many*… …   Wikipedia

  • Requirements traceability — is a sub discipline of requirements management within software development and systems engineering. Requirements traceability is concerned with documenting the life of a requirement. It should be possible to trace back to the origin of each… …   Wikipedia

Share the article and excerpts

Direct link
… Do a right-click on the link above
and select “Copy Link”