如何表述清楚需求？我們需要盡可能做好兩件事情：1.完整建立產(chǎn)品的user case；2.在需求文檔中力爭做到明確、完整、一致和可測試四點。那么對于產(chǎn)品、開發(fā)的工作影響就能降到最小，你的項目也越能在規(guī)定的時間內(nèi)完成。

如何建立產(chǎn)品的User Case Diagram

User Case Diagram也叫用例圖，基于面向?qū)ο蟮乃枷牒陀脩粢暯莵碓O(shè)計。如下圖就是一種非常簡單的用例圖，它有點類似創(chuàng)建產(chǎn)品的用戶角色，你需要能從使用的角度描述出用戶是如何一步步操作這個產(chǎn)品的。

用例這種通過講故事來把需求描述清楚的辦法很有點黑盒的概念，很容易被用戶和開發(fā)者理解；但缺陷在于無法描述清楚該如何實現(xiàn)，也很少涉及內(nèi)部的信息。一旦我們遇到無法理解產(chǎn)品實現(xiàn)機制或者內(nèi)部流程架構(gòu)的情況時，就必須借助其他的方法來理解需求，這個過程可以理解為打開黑盒。這樣通過不斷地觀察黑盒，打開黑盒、分析黑盒，然后再打開黑盒的過程，我們就能做到對整個產(chǎn)品的需求有比較準確的把握。

用例圖就是這樣一種能幫助我們了解需求的方式，當(dāng)然如果指望讓程序員看完了用例圖就能把程序做出來，那是相當(dāng)?shù)爻兜?/p>

因為用例圖本身只是用來闡述用戶的需求，很難準確對產(chǎn)品的功能、架構(gòu)賦予嚴謹?shù)拿枋龊投x。因此，我們還需要另外一份交付物，來清楚表達產(chǎn)品的功能、流程和架構(gòu)，比如說產(chǎn)品需求文檔。

產(chǎn)品需求文檔應(yīng)有的幾個基本要素：

對應(yīng)的產(chǎn)品不同，需求的標準也不盡相同，不過有一些通用的要素，仍然是可以借鑒的：

明確：很多撰寫需求文檔的人并沒有學(xué)習(xí)過形式化語言，因此我們看到的需求文檔很多都是采用自然語言寫出來的。這對需求分析帶來的最大弊病就是它的二義性。因此需要我們對文檔的表述進行一些限制，例如盡可能只用主謂賓的基本表達方式，避免修飾句，避免容易令人產(chǎn)生誤解的表達方式。

比如我們是做一個社保卡系統(tǒng)，你可以這樣描述需求：每張公交IC卡只能屬于一個用戶，社?？ㄓ锌ㄌ柡徒痤~數(shù)。社?？梢栽卺t(yī)院使用，可以用來支付醫(yī)藥費。

完整：既不要在提需求時說還有一些需求沒有確認，也不要開發(fā)接近完成了提出來有一些需求遺漏了。需求的不完整是導(dǎo)致開發(fā)返工的最直接因素，也是令人發(fā)指的行為。

需求的完整需要產(chǎn)品人員有很好的產(chǎn)品管理技能，也需要對已有產(chǎn)品的架構(gòu)有清晰的了解，很多時候產(chǎn)品人員面對的都是拍腦袋或者臨時決定提出來的需求，很難第一時間提煉出完整的需求，怎么辦？問！問自己，問客戶，問開發(fā)。在你無法確認出完整需求或者起碼的核心需求之前，任何交付給開發(fā)的行為注定是不負責(zé)任的。

一致：需求簡單來說可以分成業(yè)務(wù)需求、用戶需求和開發(fā)需求三個方面。用戶需求需要能和業(yè)務(wù)需求一致，開發(fā)需求需要能和用戶需求一致，這并不是在說廢話，而是三種需求之間的繼承關(guān)系。否則，辛苦開發(fā)出來的東西很可能會偏離當(dāng)初的實現(xiàn)目標。在具象的實現(xiàn)過程中，這種一致性也必須細化。往往用戶需求在整個過程中不斷變化，產(chǎn)生所謂的”需求變動”，這種變化不應(yīng)該超出先前既定的范圍，至少不應(yīng)該超出最初的業(yè)務(wù)目標。

可測試：很多人認為項目、產(chǎn)品的測試應(yīng)該從寫完代碼輸出測試產(chǎn)品時開始算起或者說開發(fā)們在寫代碼的時候就該開始履行測試的職責(zé)了，這樣理解有它的道理。但實際上，和完整性的要求一樣，測試的過程應(yīng)該從需求一開始分析的時候就要開始。

作為測試的輸入輸入和參照物，需求分析應(yīng)該是可測試的。比如我們說“設(shè)計一個網(wǎng)站，能讓用戶第一時間了解車票的行情”。這個需求是可測試的么？當(dāng)然不是！車票是指的火車票、汽車票抑或二者都是？了解車票的行情包括哪些方面？這些在需求中都沒有做出說明，也意味著它是無法測試的，不具備可測試性。

因此包括前幾項的需求因素在內(nèi)，我們的目的都是要保證需求的可測試性。當(dāng)且只有當(dāng)所有的需求是可以被測試的，才有可能保證產(chǎn)品從需求分析到設(shè)計開發(fā)再到最后的交付都是真的在圍繞業(yè)務(wù)目標和用戶需要的。產(chǎn)品才能更接近成功。

究竟該如何解決“需求的變動”帶來的問題呢，對于這個“世界難題”我只能說見招拆招了，畢竟這屬于項目開發(fā)中不可抗的外因，很多時候并不是產(chǎn)品經(jīng)理或者項目經(jīng)理能左右的。在面向?qū)ο蟮拈_發(fā)模式下，管理者能做的就是盡可能避免變動可能造成的計劃延遲，而對于產(chǎn)品經(jīng)理來說，不僅要控制好進度，更要能把握好變動可能帶來的對核心功能的影響，因為你是掌舵者，你是“總設(shè)計師”。

但是，有句說句：忽略需求過程或者需求的變動造成項目返工是項目失敗的最大因素，大量項目的失敗往往都是在需求階段就注定了的。正在做產(chǎn)品經(jīng)理的諸位不妨審視一下自己的工作，發(fā)現(xiàn)情況不妙的趕緊處理掉吧。

舉兩個典型的需求變動的例子：

1.需求人員口頭上把自己的想法和開發(fā)人員溝通以后，又扔下一句話：這些地方暫時沒有討論清楚，不用去管，你先做吧，然后過了一段時間又提出來一個新需求，完全不管不同需求之間對開發(fā)工作的影響。

2.告訴開發(fā)人員需要做一個xx產(chǎn)品，但是現(xiàn)在自己很忙，要開發(fā)人員先照著其他類似的產(chǎn)品做一個出來。

上述的兩種情況都會造成項目的不成功，特別當(dāng)某些外行冒充內(nèi)行的時候……