如何書寫好的產品需求文檔PRD
1、正確
需求規格說明書應當正確地反映用戶的真實意圖,正確是《產品需求規格說明書》最重要的屬性。如果“不正確”僅僅是由于錯別字造成的,那么多檢查幾遍文檔就能解決問題。真正的困難是開發者和用戶自己都不明白用戶究竟“想要什么”和“不要什么”。為確保需求是正確的,開發方和用戶必須對《需求規格說明書》進行確認。
2、清楚
清楚的需求讓人易讀易懂。清楚的反義詞是難讀、難理解??梢圆捎梅磫柕姆绞絹砼袛嘈枨笪臋n是否清楚:文檔的結構、段落是否亂七八糟?上下文是否不連貫?文檔的語句是否含糊其詞、羅里羅嗦?看了半天是否還不明白需求究竟是什么?
3、無二義性?
無二義性是指每個需求只有唯一的含義。如果一個人說的話,不同的人可能有不同的理解,那么這句話就有二義性。如果需求存在二義性,將會導致人們誤解需求而開發出偏離需求的產品。為了使需求無二義性,人們在寫《產品需求規格說明書》時措詞應當準確,切勿模棱兩可。
4、一致性
一致是指《產品需求規格說明書》中各個需求之間不會發生矛盾。矛盾常常潛伏在需求文檔的上下文中。
5、必要性
《產品需求規格說明書》中的各項需求對用戶而言應當都是必要的??梢园选氨匾北扔鳛檠┲兴吞??!氨匾蓖耙徊?,要么是畫蛇添足要么是錦上添花。畫蛇添足顯然是壞事,會導致開發人員多干一些吃力不討好的工作。所以要盡量剔除需求規格說明書中畫蛇添足的那些需求。錦上添花是好事,可能會讓用戶獲得比期望更多的喜悅,但是眼前用戶不會為此多付錢。開發者應當集中精力先完成必要的需求,如果條件允許則再做錦上添花的需求。為了避免主次顛倒,應當在《產品需求規格說明書》中將那些錦上添花的需求設置為較低的優先級。
6、完備性
完備是指《產品需求規格說明書》中沒有遺漏一些必要的需求。人們往往傾向于關注系統的特色功能,而忽視了其它一些不起眼的但卻是必需的功能。不完備的《產品需求規格說明書》將導致產生功能不完整的軟件,用戶在使用該軟件時可能無法完成預期的任務。
7、可實現性
《產品需求規格說明書》中的各項需求對開發方而言應當都是可實現的??蓪崿F意味著在技術上是可行的,并且滿足時間、費用、質量等約束。營銷人員和用戶談生意時,為了能拿到單子,他們往往對用戶提出的需求來者不拒。吹牛皮雖然不犯法,但是《產品需求規格說明書》可是白紙黑字啊。經過雙方確認的《產品需求規格說明書》相當于商業合同,如果開發方不能夠實現《產品需求規格說明書》中的內容,那就是違約。對于合同項目,如果開發方不能確信某些需求是否可實現,則應事先與用戶協商,達成一致的處理意見,避免將來發生商業糾紛。
8、可驗證性
《產品需求規格說明書》中的各項需求對用戶方而言應當都是可驗證的。如果需求是不可驗證的,那么用戶就無法驗收產品。 例如,摩天大樓的一項需求是“抗十二級臺風”,這個需求看起來堂而皇之,但是如何驗證呢?當摩天大樓完工后驗收時,用戶又不是巫師,他怎能造個十二級臺風來試驗?如果雙方都認可“采用計算機模擬十二級臺風”等效于實際測試,那么這項需求就是“可驗證”的。
9、確定優先級
為什么要確定需求的優先級? 理論上講,所有需求都應當被實現。但是在現實之中,項目存在進度、費用、人力資源等限制。在項目剛開始的時候,開發方和客戶比較樂觀,什么都要做,可是做著做著,常常會面臨進度延誤、費用超支、人員不足等問題,這時就亂套了。不過可以采用取舍的辦法:先做優先級高的需求,后做(甚至放棄)優先級低的需求,這樣可以將風險降到最低。需求的優先級其實就是需求輕重緩急的分級表述,例如劃分為“高、中、低”三級。一般地,由用戶和開發方共同確定需求的優先級。
10、闡述“做什么”而不是“怎么做”
《產品需求規格說明書》的重點是闡述“做什么”,而不是闡述“怎么做”?!霸趺醋觥笔窍到y設計和實現階段的事情。 很多開發人員常常身兼數職,可能把需求開發、系統設計、編程等工作從頭做到尾。所以他們在調查、分析、定義需求時,自然會想到“怎么做”,這并沒有什么過錯。如果在調查、定義需求時想好了“怎么做”,當然應該寫下來,否則豈不浪費!關鍵是不要將“怎么做”寫到需求規格說明書里面,記錄在其它文檔里就行了。
PS:產品需求文檔模板下載地址:?http://pan.baidu.com/s/1kTMN6WR
附上海某知名互聯網公司產品需求文檔案例一份,woshipm.com版權所有,轉載請注明來源,請勿用于商用,否則追究法律責任,謝謝。
下載地址:?http://pan.baidu.com/s/1bn2fg6r
很基礎的模板,可以提供思路。不過現在一般公司都有自己的模板,雖然大同小異,但還是要應對實際情況來做。
模板呢?取消分享了嗎?