Business Requirement and Product Requirement

Are these two separate requirement documents? Some people believe that there is no differece between these two documents. I feel that we should separate these as two separate deliverables.

The business requirement document is sometimes referred as the marketing requirement document (MRD). It discusses the requirements at a very high level from a business perspective. It describes the problem that need to be resolved, the market opportunity, and sometimes the competitor offerings. It justifies if a development project should be initiated. The business requirement document is not tie to any given development release and should avoid using the product specific terms. Sometimes the requirements are described in a such neutral way that you cannot tell which module or applications will be impacted. Actually, the business requirements is more like a RFP from some prospects. It is a user view of the solution.

The product requirement document is sometime referred as the product requirement specification or functional specification. It describes the expected functionality from a product. It is an outcome from the requirement analysis process. It interprets the business requirements by mapping and describing them using the product terminology. It is the document to communicate the business requirement to the product stakeholders. A product requirement document should be written with a product release in mind although not all features identified need to be scoped in. The key point is that the detail scoping decision can be made based on the product requirement document. It is the product requirement document identifies the scope of a development project. In the PMBOK, the product requirement document can be regarded as the scope statement for initiating a development project. It defines the features and is the product view of the solution.

At some stage, the product requirement should be baselined for functional design. It should be subject to the change control process for scope control. Scope creeping can thus be avoid. However, it worth mentioning that the requirement analysis is a iteration process. You should not be too rigid on changing the product requirement during design phase. You should not feel hesitate to contact customers to clarify the requirement.