Talk:Product requirements document/Archives/2012

This page is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Broken Links

I removed

Sample Requirements Document put together for wireless email enhancements because it doesn't work anymore.

I'm putting it here in case someone can find the referent again.

Please remove the hyperlinks from "market requirements document" in the article and the list of links at the end of the article in http://en.wikipedia.org/wiki/Product_Requirements_Document. The referenced article has been deleted. 76.126.126.86 (talk) 02:07, 5 February 2009 (UTC)

Industrial Strength PRD Templates

1. Software Products --- http://software.franteractive.com/Software%20PRD/pg_0002.htm

2. Hardware Products --- http://software.franteractive.com/Hardware%20PRD/pg_0001.htm Sam (talk) 01:16, 13 September 2009 (UTC)

Levels of requirements definitions

The section on "Levels of requirements definitions" doesn't describe the contents. I am removing the section as it is not necessary to the definition and potentially duplicates content that should be found on the requirements page.

The text is below in case anyone wants to check my edit's validity. I've also added a link to the requirements page under "See Also".

Levels of requirements definitions

The following words are used to indicate different levels of requirements:^{[citation needed]}

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 - The 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 weighed before choosing a different course.
MAY - The 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.

Another way to define levels of the requirements is by using the MoSCoW Method.