好的產品需求規格說明書有如下屬性:正確、清楚、無二義性、一致、必要完備、可實現、可驗證。
正確
需求規格說明書應當正確地反映用戶的真實意圖，“正確”是《產品需求規格說明書》最重要的屬性。如果“不正確”僅僅是由於錯別字造成的，那麼多檢查幾遍文檔就能解決問題。真正的困難是開發者和用戶自己都不明白用戶究竟“您要什麼”和“不要什麼”。為確保需求是正確的，開發方和用戶必須對《需求規格說明書》進行確認。
清楚
清楚的需求讓人易讀易懂。清楚的反義詞是“難讀”、“難理解”。你可以採用反問的方式來判斷需求文檔是否清楚:
(1)文檔的結構、段落是否亂七八糟?上下文是否不連貫?
(2)文檔的語句是否糊其詞、羅裡羅嗦?
(3)是否看了半天還不明白需求究竟是什麼?
無二義性
“無二義性”是指每個需求只有惟一的 義。如果一個人說的話，不同的人可能有不同的理解，那麼這句話就有二義性。如果需求存在二義性，將會導致人們誤解需求而開發出偏離需求的產品。為了使需求無二義性，人們在寫《產品需求規格說明書》時措詞應當準確，切勿模稜兩可。
一致
“一致”是指《產品需求規格說明書》中各個需求之間不會發生矛盾。矛盾常常潛伏在需求文檔的上下文中。
必要
《產品需求規格說明書》中的各項需求對用戶而言應當都是必要的。我們可以把“必要”比喻為“雪中送炭”。“必要”往前一步，要麼是“畫蛇添足”要麼是“錦上添花”。“畫蛇添足”顯然是壞事，會導致開發人員多幹一些費力不討好的工作。所以要儘量剔除需求規格說明書中“畫蛇添足”的 那些需求。“錦上添花”是好事，可能會讓用戶獲得比期望更多的喜悅，但是眼前用戶不會為此多付錢。開發者應當集中精力先完成 必要的需求，如果條件允許則再做“錦上添花”的需求。為了避免主次顛倒，應當在《產品需求規格說明書》中將那些“錦上添花”的需求設置為較低的優先級。
完備
“完備”(Complete)是指《產品需求規格說明書》中沒有遺漏一些必要的需求。不完備的《產品需求規格說明書》將導致產生功能不完整的軟件，用戶在使用該軟件時可能無法完成預期的任務。人們往往傾向於關注系統的特色功能，而忽視了其他一些不起眼的但卻是必需的功能。
可實現
《產品需求規格說明書》中的各項需求對開發方而言應當都是可實現的。“可實現”意味著在技術上是可行的，並且滿足時間、費用、質量等約束。營銷人員和用戶談生意時，為了能拿到“單子”，他們往往 對用戶提出的需求“來者不拒”。吹牛皮雖然不犯法，但是《產品需求規格說明書》可是白紙黑字啊。經過雙方確認的《產品需求規格說明書》相當於商業合同，如果開發方不能夠實現《產品需求規格說明書》中的內容，那就是違約，可能會被罰款的。對於合同項目，如果開發方不能確信某些需求是否可實現， 則應事先與用戶協商，達成一致的處理意見，避免將來發生商業 糾紛。
可驗證
《產品需求規格說明書》中的各項需求對用戶方而言應當都是可驗證的。如果需求是不可驗證的，那麼用戶就無法驗收軟件，可能會發生商業糾紛。
確定優先級
為什麼要確定需求的“優先級”?理論上講，軟件的所有需求都應當被實現。但是在現實之中項目存在進度、費用、人力資源等諸多因索的限制。在項目剛開始的時候，開發方和客戶比較樂觀，什麼都要做，可是做著做著，人們常常會面臨進度延誤、費用超支、人員不足等問題，這時就亂套了。久病成醫，人們想出了“取捨”的辦法:先做優先級高的需 求，後做(甚至放棄)優先級低的需求，這樣可以將風險降到最低。 需求的優先級其實就是需求“輕重緩急”的分級表述，例如劃分為“高、中、低”三級。一般地，由用戶和開發方共同確定需求的優先級。 闡述“做什麼”而不是“怎麼做”《產品需求規格說明書》的重點是闡述“做什麼”，而不是闡述“怎麼做”。“怎麼做”是系統設計和實現階段的事情。 國內的很多軟件公司裡，開發人員常常身兼致職，可能把需求開發、系統設計、編程等工作從頭做到尾。所以他們在調查、分析、定義需求時，自然會想到“怎麼做”，這並沒有什麼過錯。如果在調查、定義需求時想好了“怎麼做”，當然應該寫下來，否則豈不浪費!關鍵是不要將“怎麼做”寫到需求規格說明 書裡面，記錄在其他文檔裡就行了。
閱讀更多 筆下餘香 的文章
