前言
在軟體開發的過程中，我們經常遇到以下兩種情況：
1、客戶說的不一定是客戶想要的；
2、需求傳遞失真是客觀存在的。
一、什麼是需求
IEEE 《軟體工程标準詞彙表（1997）》從使用者角度和開發者角度定義需求：
（1）使用者解決問題和達到目标所需的條件或能力；
（2）系統或系統部件要滿足合同、标準、規範或其他正式規定文檔所需具有的條件或能力；
（3）一種反應上面（1）或（2）所描述的條件或權能的文檔說明。
在IEEE830【1998年版】中，将軟體需求總結為以下需求：
1）功能性需求
功能性需求是軟體需求的主題，即軟體必須完成哪些事，必須實作哪些功能，以及為了向其使用者提供有用的功能所需執行的動作。是系統應提供的服務、系統針對特定輸入如何響應，以及系統在特定情形下行為的陳述。如，51CTO部落格的功能性需求是：對使用者開放部落格的編寫、檢視、編輯、删除，個人資訊的換頭像、更改密碼等。
2）非功能性需求
作為對功能性需求的補充，軟體需求分析的内容中還應該保護一些非功能需求（DFX需求）。主要包括軟體使用時對性能方面的要求、運作環境要求。軟體設計必須遵循的相關标準、規範、使用者界面設計的具體細節、未來可能的擴充方案等。如：
性能：頁面的響應時長不超過3秒。
備份：使用者不正常退出時，需将使用者編輯的内容存為草稿。
相容性：使用者使用IE浏覽器、谷歌浏覽器、火狐浏覽器登入51CTO的部落格子產品，都可以正常使用。
3）設計限制
一般也稱為設計限制條件，通常是對一些設計或實作方案的限制說明。如，資料庫、部署環境等。
1.1 需求的分類（KANO模型）
衆所周知，馬洛斯認為，人的訴求主要由生理需求、安全需要、社交需求、尊重需求、自我價值實作的需求5類構成，這就是著名的馬洛斯模型。
那麼，對于産品來說，東京理工大學教授：授野紀昭（Noriaki Kano）通過對使用者需求分類和優先排序的有用工具，以此分析使用者需求對使用者滿意度的影響為基礎，總結出了一種可以展現産品性能和使用者滿意之間的非線性關系，這便是KANO模型。
KANO模型定義了5類需求：必備型需求、期望型需求、魅力型需求、無差異需求、反向需求。
1）必備型需求（基本型需求）：
顧客對産品或服務的基本要求，即使用者認為産品或服務“必須有”的屬性或功能。
2）期望型需求：
使用者的滿意狀況與需求的滿足程度成比例關系的需求，這是處于成長期的需求，客戶、競争對手和企業自身都關注的需求，也是展現競争能力的需求。對于這類需求，企業的做法應該是注重提高這方面的品質，要力争超過競争對手。
3）魅力型需求（興奮型需求）：
指不會被顧客過分期望的需求。這類需求往往是代表使用者的潛在需求，企業的做法就是去尋找發掘這樣的需求，領先對手。
4）無差異需求
無論提供或不提供，使用者的滿意度都不會改變，使用者不在意的需求。
5）反向需求
提供後使用者滿意度反而會下降的需求。
1.2 需求的九種屬性
需求作為一種特殊的資訊，具有一些重要的屬性。而大部分管理需求的活動，就是圍繞需求的屬性展開的，是以深入了解需求的内在屬性，對于如何開展需求管理是至關重要的。需求有多種屬性，最重要的屬性可以總結為如下9點：
1）基礎屬性：二重性
需求=“問題”+“解決方案”
“問題”是“廣義”的問題，不一定是缺陷，也可能是一種願望，是“使用者期望”和“現狀”之間的差距。澄清問題比澄清解決方案更加重要和優先。“問題”是根源，是出發點。對于一個問題，其解決方案通常不隻一種。如果我們無法得到明确的“問題”，就無法找出正确的“解決方案”。
這有一個誤區：大多數人由于過于關注解決方案，在描述需求時往往會直接描述自己拟制好的解決方案，以解決方案來代替整個需求，這是導緻需求被誤解和失真的主要原因之一。
2）需求屬性：易變性
需求的易變性是指需求從提出以後到實作以前，可能部分或全部發生變化。根據需求的二重性，其易變性可以總結為如下三種情況：
> “問題”發生變化或者消失。
> “解決方案”被替換。
> “解決方案”的細節發生變化。
在IT需求分析中，如果已經看到需求易變性的風險，可以通過以下方式規避：
需求取消
需求簡化
IT功能上增強配置性
3）需求屬性：限制性
需求的“問題”和限制條件，可以比喻為浮在海面的冰山。露出水面的“問題”占整個冰山的20％，而隐含在水下的限制條件卻占冰山的80％。例如第三方依賴條件、網絡準入規範、請求并發數、裝置相容性等，這些就是需求的限制性。
如果在分析問題時未能充分把握限制條件，則解決方案将面臨多次返工的風險，甚至推倒重來。
做好需求的限制條件分析，應采取至少如下三種基本方法：
> 有計劃、系統性收集可能對解決方案有影響的業務相關資訊，建設業務資訊知識庫，以便在分析需求時進行查詢。如業務文檔，接口規範等。
> 在具體的需求分析中加強場景分析，模拟使用者的行為過程來尋找更多的隐含條件，并考慮在現場進行專題調研。如場景分析，功能時序圖。
> 利用DEMO等方式，将解決方案原型與客戶進行确認，以便發現更多的隐含因素，并驗證解決方案的正确性。可以參照相近的系統，或者用低保真方式展現方案的關鍵部分。如原型機、UCD原型設計稿。
4）需求屬性：關聯性
需求分析前，需要将收集的需求劃分“需求集”：
“需求集”：通過不同管道産生的需求是一個個顆粒度不同的獨立資訊，而這些獨立的需求資訊，也可能是相關或雷同的。在初步整合、歸納雷同的需求後，所得到的一組需求，就構成了“需求集” 。
“需求集”的可以按照不同次元劃分。如，同一個業務功能的需求，同一個客戶的需求，同一個産品的需求等等。按照“需求集”分析需求，可以更好的考慮分析需求之間的關聯關系，如雷同需求、沖突需求、前後依賴等。
5）需求屬性：演進性
什麼是需求的演進性？
> 正如上面所提到的，需求包括“問題”和“解決方案”，“問題”中還包含限制條件。随着需求的澄清、分析、實施過程，這三要素會不斷發生演進，沿時間軸的先後順序進行轉化。這就是需求的演進性。
> 這個逐漸明晰化的過程，不是一次完成的，而是經過了若幹中間步驟。隻有清晰地定義出所需的中間步驟，才能有效指導需求的分析過程管理。
> 需求的演進性，就是将需求從不明确到明确的中間過程進行了定義。定義的目的，就是為了指導這個“逐漸明确化”的過程循着科學的方法論、規範的過程來進行。
根據需求演進特性，可定義如下四個演進關鍵步驟：
Step1：業務構想idea（識别領域）
問題域：開始意識到問題的存在
解決方案域：尋找初步的解決辦法
Step2：業務政策tactics（問題細分與選擇/指出目标）
問題域：對問題進行了概括，初步識别了問題的範圍
解決方案域：找出了多個可能方案，嘗試進行選擇
Step3：行動計劃action plan（方案與步驟）
問題域：識别出問題的表象及根源，區分主要沖突與次要沖突
解決方案域：對標明的方案進行優化完善并拟制了計劃裡程碑
Step4：任務task（聚焦點/具體工作）
問題域：對所有要解決的問題點識别出了細節性的限制條件
解決方案域：将裡程碑計劃分解為可實施的具體工作單元
6）需求屬性：多元性
> 需求的多元性，簡單說就是可以從多個不同的角度來看待同一組需求。隻有意識到需求可以從多個次元看待，才能避免在分析、分類時陷入誤區。
> 由于需求具備上述提到的多種屬性，而每條需求本身也有具體的客戶、相關的産品與技術、所屬地區等具體特征，是以可以從很多種次元來分析需求，或者說可以将需求分成很多種類别。
> 需要注意的是，每次隻能使用一緻的次元去分析一組需求，而不能混用多種次元。在一種次元使用後，可以換用第二種次元來分析，直到使用過足夠多的次元，将需求各方面都考慮完全為止。
> 需求的多元性，在對需求集分析時，我們可以想像需求的金字塔模型，每次隻看到金字塔的一個側面，然後再換到另一個側面
二、常見的需求收集方法
2.1 啟發式評估
2.2 使用者訪談（需求調研）
2.3 資料分析
2.4 研讨會
2.5 競品分析
2.6 實際觀察
三、需求分析
需求分析，是經過深入細緻的調研和分析，準确了解使用者和項目的功能、性能、可靠性等具體要求，将使用者非形式的需求表述轉化為完整的需求定義，進而确定系統必須做什麼的過程。需求沒分析透徹可能會導緻南轅北轍，修複成本被層層放大。下圖是各階段的需求修複成本示例：
3.1 需求分析方法：5W1H方法
1、使用者識别（Who）：該需求的使用角色是誰？需求滿足的是不是我們的目标使用者？
2、使用場景（Where/When）：需求的使用場景是什麼？什麼時間使用？使用的頻次？
3、問題分析（What/Why）：在業務場景下遇到什麼問題？為什麼要解決這些問題？
4、解決方案（How）：需求的解決方案是什麼？包括頁面UI、業務規則、第三方接口、異常處理、非功能需求（DFX）。
3.2 需求分析：非功能需求（DFX）
3.3 需求文檔
需求分析後需要輸出需求文檔，即“功能需求說明書” （FRS，Functional Requirement Specification ），并與使用者确認。
3.4 需求分析：需求分析輸出的品質準則
3.5 需求排序
1、KANO模型法：基本型需求 > 期望型需求 > 興奮型需求
2、矩陣分析法：重要且緊急 > 重要不緊急 > 緊急不重要 > 不重要也不緊急
3、經濟收益法：經濟收益高且緊迫的功能需求 ＞ 經濟收益高但不緊迫的功能需求 ＞ 緊迫但經濟收益不高的功能需求 ＞ 不緊迫且經濟收益不高的功能需求
4、前/後置需求分析法：前置需求的優先級 > 後置需求的優先級
5、二八原則：滿足核心使用者的需求優先，先做能夠滿足80%使用者的需求，邊緣使用者的需求往後排