• 客戶自己對需求理解失真

• 設(shè)計人員對需求理解失真

• 需求文檔對需求描述失真

• 開發(fā)人員對需求設(shè)計失真

• .......
  那么對于需求的定義在項目的成功執(zhí)行，就顯得尤為重要了。再看一個關(guān)于小龍女形象的經(jīng)典段子：

需求的SMART原則，SMART依次英文含義為聰明的，SMART對于需求而言，有哪些度量維度呢？

• S：Specific 明確的
• M：Measurable 可度量的
• A：Achievable 可實現(xiàn)的
• R：Relevant ?相關(guān)的（范疇內(nèi)）
• T：Traceable and Testable 可追溯及可測的

Specific明確原則

• 需求描述的正確性？描述的需求本身必須是正確的界定某個功能，如果本身就是一個錯誤的描述，則設(shè)計實現(xiàn)就一定是錯誤的！需求描述的內(nèi)容是否是需求方（可能是最終客戶或者來源于市場產(chǎn)品管理人員）。這項需求真的是需求方所需嗎？或者部分所需？或者完全錯誤？
• 需求描述的唯一性？好的做法是將需求拆分成一個個條目，每一個條目描述一項明確精準(zhǔn)的需求，相互之間不存在包含關(guān)系。
• 需求條目是否在項目的范圍內(nèi)？有的需求可能天馬行空，超出了項目預(yù)期的范圍的事情時有發(fā)生。
• 需求描述時否明確了該項需求的前提條件或者約束？

Measurable可度量原則

• 需求描述的精確性？需求不要用模棱兩可的描述，比如不可使用左右，上下，可能等，而盡量用精準(zhǔn)的數(shù)字去描述。比如需要描述響應(yīng)時間，推薦描述為響應(yīng)時間須滿足：
• 需求描述的客觀性？需求描述應(yīng)采用客觀描述語言，忌諱采用具有主管色彩的詞匯，比如需求一個產(chǎn)品經(jīng)理要求設(shè)計的UI界面，美觀大方，容易操作，這樣的需求是非常不易度量的，相信很多盆友或許又遭遇過這樣的需求，也一定是非常惱火的。這樣的需求你讓設(shè)計咋整？一千個讀者眼中就有一千個哈姆萊特，這樣的描述太過主觀，最后一定是撕逼扯皮的結(jié)局。

Achievable 可實現(xiàn)原則

• 項目團(tuán)隊是否具有這樣的技術(shù)？
• 關(guān)鍵技術(shù)指標(biāo)能否滿足要求？
• 項目資源配置能滿足要求？
• 可實現(xiàn)是原則不是描述如何實現(xiàn)！需求描述的就是功能性或非功能性的要求，而不要描述設(shè)計方案！
• .......

雙T可追溯可測原則

• 后向追溯：所有的需求條目，理論上應(yīng)有甲方（需求方）的源頭
• 后向追溯：所有的需求條目，都應(yīng)有設(shè)計能對應(yīng)保證，都應(yīng)測試用例可驗證。

• 需求條目，需要應(yīng)盡量具有可測性
• 需求階段，理論上測試人員就應(yīng)該參與討論，從測試的角度來進(jìn)行核定。

不良需求描述栗子

無法追溯（無標(biāo)號）

• 按下急停開關(guān)，系統(tǒng)須停機。（這里其實還不精確，應(yīng)描述在多少時間內(nèi)停機）

不可測

• SR-1：系統(tǒng)須永不崩潰。

不精確

• SR-2：系統(tǒng)應(yīng)向用戶提供快速反饋。（多快？）

無測量公差

• SR-3：LED燈應(yīng)閃爍間隔100毫秒（應(yīng)定義正負(fù)偏差）

過于復(fù)雜

• SR-4：按紅色按鈕將激活功能A，按藍(lán)色按鈕應(yīng)使LED 1 閃爍而不是LED 2點亮，點亮LED 2通過黃色按鈕實現(xiàn)。（應(yīng)拆分）

描述實現(xiàn)

• SR-5：按下按鈕W將導(dǎo)致兩個16位整數(shù)值相加，然后…

需求描述方法

• 文檔描述法：屬于常規(guī)方法，很多公司采用這樣方案描述項目需求。
• UML 用例法：利用UML用例圖描述需求，這種方法比較直觀，比如下圖
• 敏捷項目管理，采用用戶故事描述（user story）

總結(jié)一下