How to write a good product requirements document.
http://www.pinterec.ca/how-to-write-a-good-product-requirements-document/
Written by Chris Pinter
February 1, 2010
The development of new technology starts from a marketing perspective. It is important to know what you are building before you build it. Business Analysts’ are constantly asking the question… What does the market want? Knowing the answer is the key to success. Documenting the facts and key features is the essence of the requirements document. It is best written by business analysts and marketing professionals.
The requirements document is the first document that is used to build a technology. According to Wikipedia.com the Product Requirements document (PRD) is designed to allow people within a company to understand what a product should do and how it should work. [1] This document directs the development team in what the needs are and is used to create the technical specifications.
A good requirements document has the following areas addressed:
1. Purpose and scope
The purpose and scope of the project should be well defined. The best way to do this is to use the S.M.A.R.T. approach to setting goals. The purpose and scope must be Specific, Measureable, Attainable, Realistic and Timely. [2]
2. Identify stakeholders
Identify everyone who has an interest in the project. This list of interested parties will consist of members who want a positive outcome and members who do not. Some examples include the client, customer, executives, lobby groups, strategic partners, government organizations, project managers, and members of the development team.
3. Market assessment
The market assessment section should include as much information on the market as required to outline the project. It should include a brief description of the problem, specifically why this project is necessary and the target audience, who has the problem. It must also include the market size and potential market acceptance so that the development team knows the likely volume to design to. Products that have a potential of 5 million pieces per year require different design criteria than those products that have a potential of one thousand units per year. The competitors and similar products on the market should also be noted so that there is a reference to the technology of the day.
4. Product overview and use cases
The product overview is the vision of how the product solves the market problem. This can be described using a series of use cases. Each example describes how the product will be used in each situation thereby solving the problem in different ways or solving a group of similar problems with a single solution.
5. Product requirements
The product requirements section describes how each aspect, notable condition, feature or function the product must possess. The requirements can include function, usability, environmental, interacting and interfacing requirements. It is important that each requirement be well defined in specific measureable terms. A measure of minimum and maximum should be used wherever possible.
6. Supporting business requirements
Development projects are very seldom developed in isolation. Many other business departments and organizational resources will be used to promote, service and maintain the new technology project. It is important to recognize the need for these departments as there are costs and procedures that will need to be recognized and developed.
7. Known risks and constraints
In order to achieve a competitive advantage in the market place, risks must be overcome that your competitors cannot. It is important to recognize the technical, procedural and business risks and constraints that may affect the project.
8. Workflow constraints
It is not required to outline the schedule, budget, and tasks required to complete the project in the requirements document. However, it is important to recognize any time, environmental, budget or resource constraints that must be considered when planning the project.
9. Evaluation plan and performance metrics
How the project is evaluated for quality and the performance completes the requirements as these measurable aspects of the document will affect the feasibility, budget and schedule of the project.
The requirements document outlines the customer needs and the factors that will affect success. The primary use of this document is to direct the development team in creating a technical brief and project plan. The schedule, budget and deliverables can then be outlined and decisions can be made on the return on investment (ROI) for the project. So… provide as much information as possible.
References
http://en.wikipedia.org/wiki/Product_requirements_document
http://www.topachievement.com/smart.html
http://www.pmi.org/Marketplace/Pages/ProductDetail.aspx?GMProduct=00101095501
- See more at: http://www.pinterec.ca/how-to-write-a-good-product-requirements-document/#sthash.HiIC4xgD.dpuf
--------
How To write a Good PRD
Martin Cagan
Silicon Valley Product Group
http://dc.mit.edu/sites/dc.mit.edu/files/Econ%20Special%20Rpt%20Manufactur.pdf
http://citybuild.seoul.go.kr/files/2012/08/502887c4836660.89190585.pdf
http://www.fona.de/mediathek/gek/vortraege/eroeffnung_rifkin_jeremy_01_presentation_ge2012.pdf
'Gurus,Google,Apple,... > 꿈,학습,성장' 카테고리의 다른 글
| 시간 관리 잘하기 (0) | 2013.07.23 |
|---|---|
| 좋은 관리자가 되기 위한 스킬 (Skill Sets for Smart managers) (0) | 2013.07.23 |
| 내면 검색 , 명상 (0) | 2013.07.21 |
| French Paradox - 프랑스의 생산성 (0) | 2013.07.21 |
| 학습, 성과, 그리고 팀 리딩의 향상을 위해 (0) | 2013.07.18 |
WRITTEN BY
- manager@
Data Analysis, Text/Knowledge Mining, Python, Cloud Computing, Platform
