[導讀] 項目開發，通常都是按照需求驅動開發整個開發過程的。需求是開發的源頭，即使是本身DIY一個小東西，心中所想也是一種需求，因此一個項目是否成功，需求分析作的是否到位也是相當重要的。七夕情人節剛過完了，想來有的盆友或許深思倦怠，今天來分享一篇輕鬆的文章吧。
node
從搞笑開始
客戶想要一款集美麗、智慧於一身的機器人，理想很豐滿，但是現實很骨感。項目中不一樣的角色對這個需求理解各不相同，而表現傳遞的信息又有可能會大打折扣，因此最後交付造出來的產品與客戶想要的相去甚遠。
web
那麼問題出在哪裏呢？我覺得需求失真是罪魁禍首！微信
-
客戶本身對需求理解失真網絡
-
設計人員對需求理解失真架構
-
需求文檔對需求描述失真app
-
開發人員對需求設計失真less
-
.......編輯器
那麼對於需求的定義在項目的成功執行，就顯得尤其重要了。再看一個關於小龍女形象的經典段子：svg
這不是終極版本，來看下顛覆三觀的終極失控版本：測試
注：圖片來源於網絡，純屬調侃搞笑，不帶任何歧視，侵刪
因此對一個成功的項目而已，需求的做用就顯得尤其重要了。
需求的SMART原則，SMART依次英文含義爲聰明的，SMART對於需求而言，有哪些度量維度呢？
S：Specific 明確的 M：Measurable 可度量的 A：Achievable 可實現的 R：Realizable 可實現的 T：Traceable and Testable 可追溯及可測的
Specific明確原則
明確原則主要涵蓋這樣一些要點：
-
需求描述的正確性？描述的需求自己必須是正確的界定某個功能，若是自己就是一個錯誤的描述，則設計實現就必定是錯誤的！需求描述的內容是不是需求方（多是最終客戶或者來源於市場產品管理人員）。這項需求真的是需求方所需嗎？或者部分所需？或者徹底錯誤？ -
需求描述的惟一性？好的作法是將需求拆分紅一個個條目，每個條目描述一項明確精準的需求，相互之間不存在包含關係。 -
需求條目是否在項目的範圍內？有的需求可能天馬行空，超出了項目預期的範圍的事情時有發生。 -
需求描述時否明確了該項需求的前提條件或者約束？
Measurable可度量原則
可度量，個人理解是體現精確性：
-
需求描述的精確性？需求不要用模棱兩可的描述，好比不可以使用左右，上下，可能等，而儘可能用精準的數字去描述。好比須要描述響應時間，推薦描述爲響應時間須知足： -
需求描述的客觀性？需求描述應採用客觀描述語言，忌諱採用具備主管色彩的詞彙，好比需求一個產品經理要求設計的UI界面，美觀大方，容易操做，這樣的需求是很是不易度量的，相信不少盆友或許又遭遇過這樣的需求，也必定是很是惱火的。這樣的需求你讓設計咋整？一千個讀者眼中就有一千個哈姆萊特，這樣的描述太過主觀，最後必定是撕逼扯皮的結局。
Achievable 可實現原則
凡是寫入項目需求規格書中的條款理論上就是一份技術合同，需求方就是甲方，項目團隊至關於乙方。因此界定需求是須要與甲方反覆溝通，反覆確認的，不然一旦寫入規格書，臨了發現臣妾作不到！最後又難免撕逼扯皮！
要實現需求規格書的可實現原則，並非簡單成員坐在一塊兒，拍拍腦殼想一想就定下來，這裏對於一些具備挑戰的技術難點、技術指標是須要作技術預研的，不然可實現就變成了以爲可實現，而非客觀上真的可實現！對因而否可實現，能夠提出這樣些問題：
-
項目團隊是否具備這樣的技術？ -
關鍵技術指標可否知足要求？ -
項目資源配置能知足要求？ -
可實現是原則不是描述如何實現！需求描述的就是功能性或非功能性的要求，而不要描述設計方案！ -
.......
雙T可追溯可測原則
可追溯原則：
-
後向追溯：全部的需求條目，理論上應有甲方（需求方）的源頭 -
後向追溯：全部的需求條目，都應有設計能對應保證，都應測試用例可驗證。
可測試原則：
-
需求條目，須要應儘可能具備可測性 -
需求階段，理論上測試人員就應該參與討論，從測試的角度來進行覈定。
不良需求描述栗子
沒法追溯（無標號）
按下急停開關，系統須停機。（這裏其實還不精確，應描述在多少時間內停機） 不可測
SR-1：系統須永不崩潰。 不精確
SR-2：系統應向用戶提供快速反饋。（多快？） 無測量公差
SR-3：LED燈應閃爍間隔100毫秒（應定義正負誤差） 過於複雜
SR-4：按紅色按鈕將激活功能A，按藍色按鈕應使LED 1 閃爍而不是LED 2點亮，點亮LED 2經過黃色按鈕實現。（應拆分） 描述實現
SR-5：按下按鈕W將致使兩個16位整數值相加，而後…
需求描述方法
實際項目中，不一樣的公司實際落地都各有各的特色，這裏大體列舉一些常見作法：
-
文檔描述法：屬於常規方法，不少公司採用這樣方案描述項目需求。 -
UML 用例法：利用UML用例圖描述需求，這種方法比較直觀，好比下圖
-
敏捷項目管理，採用用戶故事描述（user story）
總結一下
項目開發，需求階段是一個相當重要的階段。若是在需求階段不作足確認工做，需求分析描述作的很隨意，開發過程及交付時難免掉進各類坑裏。
本文辛苦原創，如喜歡請點贊/在看/分享支持，不勝感激！
—END—
本文分享自微信公衆號 - 嵌入式客棧（embInn）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。