編輯導語：軟件需求分析，就是把軟件計劃期間建立的軟件可行性分析求精和細化，分析各種可能的解法，並且分配給各個軟件元素。這是是軟件定義階段中的最後一步，是確定系統必須完成哪些工作，也就是對目標系統提出完整、準確、清晰、具體的要求。
軟件需求分析也稱為系統需求分析或需求分析工程等，是開發人員經過深入細緻的調研和分析，準確理解用户和項目的功能、性能、可靠性等具體要求，將用户非形式的需求表述轉化為完整的需求定義，從而確定系統必須做什麼的過程。
軟件開發一般包括：可行性分析、需求分析、軟件設計、軟件開發、軟件測試、軟件實施、軟件服務等步驟，需求分時軟件開發的第一步驟。
用户需求分析是指在系統設計之前和設計、開發過程中對用户需求所作的調查與分析，是系統設計、系統完善和系統維護的依據。
需求是需要與欲求的意思，需求是機體的一種客觀需要，而欲求則是一種主觀需要，包括人在勝利、環境、社會等方面的需要。
需求是一款產品的市場基礎，成功的產品不但能滿足用户的物質需求，也要滿足用户的精神和心理需求。
二、軟件需求分析目標需求分析是軟件計劃階段的重要活動，也是軟件生存週期中的第一步，該階段是分析系統在功能上需要“實現什麼”，而不是考慮如何去“實現”。
對客户的信息化需求進行分析，將客户不規範的、隨意的需求，轉換成規範的、嚴謹的、結構化的需求，將客户不正確的需求轉換成正確的需求、將客户不切實際的需求轉換成可以實現的需求，將客户不必要的需求砍掉，將客户漏掉的需求補上。
此外，軟件的一些非功能性需求(如軟件性能、可靠性、響應時間、可擴展性等)，軟件設計的約束條件，運行時與其他軟件的關係等也是軟件需求分析的目標。
三、軟件需求分析原則需求分析通常來講它們應符合以下一般原則：
1. 能夠表達和理解問題的信息域信息域反映的是用户業務系統中數據的流向和對數據進行加工的處理過程，因此信息域是解決“做什麼？”的關鍵因素。根據信息域描述的信息流、信息內容和信息結構，可以較全面地（完整地）瞭解系統的功能。
2. 建立描述系統信息、功能和行為的模型建立模型的過程是“由粗到精”的綜合分析的過程。通過對模型的不斷深化認識，來達到對實際問題的深刻認識。
3. 能夠對所建模型按一定形式進行分解分解是為了降低問題的複雜性，增加問題的可解性和可描述性。分解可以在同一個層次上進行（橫向分解），也可以在多層次上進行（縱向分解）。
4. 分清系統的邏輯視圖和物理視圖軟件需求的邏輯視圖描述的是系統要達到的功能和要處理的信息之間的關係，這與實現細節無關，而物理視圖描述的是處理功能和信息結構的實際表現形式，這與實現細節是有關的。
需求分析只研究軟件系統“做什麼？”，而不考慮“怎樣做？”。
四、軟件需求分析內容需求分析的內容是針對待開發軟件提供完整、清晰、具體的要求，確定軟件必須實現哪些任務。
具體分為功能性需求、非功能性需求與設計約束三個方面：
功能性需求即軟件必須完成哪些事，必須實現哪些功能，以及為了向其用户提供有用的功能所需執行的動作。
功能性需求是軟件需求的主體，開發人員需要親自與用户進行交流，核實用户需求，從軟件幫助用户完成事務的角度上充分描述外部行為，形成軟件需求規格説明書。
2. 非功能性需求作為對功能性需求的補充，軟件需求分析的內容中還應該包括一些非功能需求。
主要包括軟件使用時對性能方面的要求、運行環境要求，軟件設計必須遵循的相關標準、規範、用户界面設計的具體細節、未來可能的擴充方案等。
3. 設計約束一般也稱做設計限制條件，通常是對一些設計或實現方案的約束説明。
例如：要求待開發軟件必須使用Oracle數據庫系統完成數據管理功能，運行時必須基於Linux環境等。
五、軟件需求分析過程需求分析階段的工作,可以分為四個方面：問題識別、分析與綜合、制訂規格説明、評審。
就是從系統角度來理解軟件，確定對所開發系統的綜合要求，並提出這些需求的實現條件，以及需求應該達到的標準。
這些需求包括：功能需求（做什麼）、性能需求（要達到什麼指標）、環境需求（如機型、操作系統等）、可靠性需求（不發生故障的概率）、安全保密需求、用户界面需求、資源使用需求（軟件運行是所需的內存、CPU等）、軟件成本消耗與開發進度需求、預先估計以後系統可能達到的目標。
2. 分析與綜合逐步細化所有的軟件功能，找出系統各元素間的聯繫，接口特性和設計上的限制，分析他們是否滿足需求，剔除不合理部分，增加需要部分。
最後綜合成系統的解決方案，給出要開發的系統的詳細邏輯模型（做什麼的模型）。
3. 制訂規格説明書即編制文檔，描述需求的文檔稱為軟件需求規格説明書。請注意，需求分析階段的成果是需求規格説明書，向下一階段提交。
4. 評審對功能的正確性，完整性和清晰性，以及其它需求給予評價。評審通過才可進行下一階段的工作，否則重新進行需求分析。
六、軟件需求評估方法需求評估分析方法通常有：模糊聚類分析、質量功能展開、KANO模型分析、A/B測試。其中以卡諾（KANO）模型最常用。
1. 模糊聚類分析法是通過分析客觀事物之間的不同特徵和親疏程度，建立模糊相似關係，從而對齊進行分類的方法。
在用户需求分析的運用中，判斷用户需求之間的相似程度（親疏關係），然後統計並建立相似性矩陣，繼而尋找需求組合之間的相似程度，由此逐漸將用户需求逐一歸類。
最終得到一個關係圖譜，以更直觀和自然的方式心展示用户需求各個特性之間的差異性和相似性，模糊聚類分析法一般要求對需求進行數學建模分析。
是指把用户對產品的需求進行多層次的演繹分析，轉化為產品的設計需求、工程部件特徵、工藝要求、生產要求，用來指導產品設計並保證產品的質量，是一種以用户為導向的質量管理工具。
由於該方法所使用的主要圖形就像房屋，所以它也被稱為“質量屋”，如下圖：
是 Noriaki Kano 博士提出的與產品性能有關的用户滿意度模型，該模型能對用户需求進行很好的識別和分類，是對用户需求分類和優先排序的有用工具，以分析用户需求對用户滿意的影響為基礎，體現了產品性能和用户滿意之間的非線性關係。
Noriaki Kano 將影響滿意度的因素劃分為五個類型，包括：必備需求、期望需求、魅力需求、無差異需求、反向需求。
- 興奮（魅力）需求：用户意想不到的，如果不提供次需求，用户滿意度不會降低，但是提供次需求，用户滿意度會有很大的提升；
- 期望（意願）需求：當提供此需求，用户滿意度會提升，當不提供此需求，用户滿意度會降低；
- 基本（必備）需求：當優化此需求，用户滿意度不會提升，當不提供此需求，用户滿意度會大幅下降；
- 無差異需求：無論提供或者不提供此需求，用户滿意度都不會有變化，而且根本不會在意；
- 反向（逆向）需求：用户根本沒有這個需求，提供之後用户滿意度反而會下降。
利用KANO模型進行需求評估主要集中於對用户需求類型的分類討論。為了便於分析可以設計相應的調研問卷。
問卷中需要對產品的某項功能分別設置正向和負向兩個問題：“如果產品有這個功能，您覺得如何？” 、“如果產品的這個功能不存在，您覺得如何？”
每個問題採用態度量表的形式設計選項，即“我喜歡這樣”、“我期望這樣”、“我沒有意見”、“我可以忍受”、“我討厭這樣”，具體形式如下表：
經過訪談調研後，根據歸類矩陣，將調研問題進行歸類來確定需求的類型，KANO模型需求歸類矩形如下表：
將問題結果術語模型矩陣中，就能夠比較明確地看到，哪些用户需求是必須有的，哪些是用户期望的，哪些是可有可無的，哪些需求又是用户自己不確定的。
將用户需求進行分類，在產品開發時，功能優先級的排序一般是：基本屬性>期望屬性>興奮屬性>無差異屬性，去掉可疑結果的需求和相反的需求。
4. A/B測試是為Web或App界面或流程製作兩個或多個版本，分別讓組成成分相同（相似）的訪客羣組（目標人羣）隨機的訪問這些版本，收集各羣組的用户體驗數據和業務數據，最後分析、評估出最好版本並且實現的綜合成本低，正式採用。
比較常見的案例是對網站註冊頁進行A/B測試，確定哪一個方案的註冊率高，更加滿足用户的需求，實現的商業利益最大化。
需要注意在進行A/B測試時，每次必須只測量一個變量，多個變量測試，則無法判斷是哪個變量導致的結果；測試的環境應當一直，例如測量時間應一致。
因為在不同的時間段，用户的訪問量會有變動；測量的樣本量要具有統計學意義，樣本流量太小時，無法體現在線用户的真實行為。
七、需求分析優先級的方法需求優先級的分析方法大致可以分成兩大類：定性分析方法、定量分析方法；
一類是根據分析人員的經驗主觀地對需求進行優先級分類，稱之為定性的分析方法，比如：四象限分析法、波士頓矩陣分析法；另一類是根據調查數據，對調查數據進行分析，得出需求的優先級分類，稱之為定量的分析方法，比如：KANO模型。
1. 四象限分析法根據需求對於業務的影響，以及需求實現的緊迫程度，我們可以按照如下方式將需求歸為4個象限，這也是需求歸類的經典4分法。四象限分析法是很常見的一種定性分析需求優先級的方法，如下：
- 重要且緊急的事，影響業務正常進行，需要儘快處理；
- 不重要但緊急的事，雖然對業務影響不大，但是需要儘快處理；
- 重要且不緊急的事，對業務影響大，但不需要短期內就完成；
- 不緊急且不重要的，對業務影響不大，也不需要短期內完成。
波斯頓矩陣是由波士頓諮詢公司發明的一種方法，最早用於分析市場增長率和市場份額，現在也被經常用於對需求的分析之中，波士頓矩陣由用户價值維度和公司價值兩個維度將需求分成了四個象限：
- 明星需求：對用户體驗有價值，對公司戰略也有價值的需求。明星需求是雙贏的需求，需要優先得到滿足，如一些促進用户活躍、轉化的需求，具體的有，活躍度排名、優惠提醒等功能；
- 問題需求：對用户體驗有價值，但對公司戰略和目標沒價值的需求。此類需求雖然看似對公司沒直接價值，但是提升用户體驗有助於提升用户的忠誠度，如一些提升用户體驗的需求。具體的有，提供多種快捷登陸方式、提供輔助輸入功能等；
- 金牛需求：對用户體驗沒價值甚至會對用户造成困擾，但是對公司戰略有價值的需求。公司價值的體現，此類需求應該儘量考慮避免對用户造成影響。如一些運營需求等。具體的有，收集用户信息等；
- 瘦狗需求：對用户體驗無價值，對公司戰略也無價值的需求。此類需求應該過濾掉，例如一些偽需求。
Noriaki Kano 將影響滿意度的因素劃分為五個類型，包括：必備需求、期望需求、魅力需求、無差異需求、反向需求（詳情見上文）。
八、如何確定軟件需求經過大量的需求調研工作之後，手上可能有客户提出的大量的、各種各樣的需求。
這些需求有的是技術上可以實現的，有的是技術上不可以實現的；有些是管理上需要的，有的是管理上不需要的；有些是合理的，有些是不合理的，如何處理這些需求呢？
以“實現用户正確的需求”為原則，對於用户提出的需求進行嚴格的分析、甄別。
為了認清用户的需求，先要認清用户。在進行需求調研的時候，會跟各種各樣的人員溝通，他們的技術、只是、性格、職位、工作內容各不相同。
但他們也有相似的地方：他們不是做軟件的，也不是分析需求的，他們永遠不會像你希望的那樣去描述需求，他們的需求是用自然語言描述的，是抽象的、概略的、隨性的。
那個這些抽象、概略、隨性的用户需求轉化成具體、詳細、結構化的軟件需求，是需求分析的重點，通常從以下幾點着手認清和控制需求：
1. 將抽象的需求具體化在需求調研的時候會發現，用户提出自己的需求時總是不會按照你希望方式去提出來，有的人因為不知道你想要什麼，只為了應付領導佈置的任務，有的是處於比較高的職位，習慣了從宏觀的角度去講問題，所以我們在整理需求的時候要將抽象的要求具體化。
2. 將自然語言描述的需求結構化用户描述需求總是非常隨意的，他們使用平常正常溝通的語言描述，這種需求的主要特點就是不嚴謹，容易有其一，這種需求不能直接讓開發者處理的，開發者需要的需求是描述明確的、精準的、沒有歧義的。
需求分析分析者作為用户與開發者的橋樑，有義務將用户用自然語言描述的需求結構化。將用户的描述轉換成更精確的語言，更接近IT人使用的語言。
3. 注意避免理解偏差理解偏差主要是需求分析者對用户所提的需求沒有理解到位，用户明明想表達的是這個意思，卻被理解成了另外一個意思。
這是一個溝通問題，説的人覺得自己説的很清楚了，可偏偏雙方就是沒有真正理解對方，所以下面是我們需要注意的：
- 提高溝通能力：多從對方的立場考慮問題，當雙方描述某件事時，要從對方的角度思考這些描述；
- 提高溝通頻次：一方面要引導對方多説話，另一方面對不理解的或者覺得理解起來有困難的內容，多向對方詢問，換成你的表達方式讓對方確認是不是這個意思；
- 學習對方領域的知識：用户有自己的知識領域，需求分析者也有自己的知識領域，前者滿腦子是業務術語，後者滿腦子是IT術語，有的時候兩者真難溝通。每個人的知識面不同，要想溝通順暢，兩個人的知識面重疊的地方越多越好。
用户的需求不能是漫無邊際的，所有的需求都應該在項目範圍之內，做需求分析的時候首先要確定好項目目標，要讓用户知道需求邊界在什麼地方。
這個項目應該在項目啓動時雙方經過討論達成共識，後面所有的工作都應該圍繞這個目標展開。原則是即使在這個階段的目標實現了以後再設置新目標，也不要不停的修改一個目標。
5. 識別錯誤的需求對於那些毫無邏輯性、前後矛盾或者在技術上根本無法實現，類似這樣的統統歸為錯誤需求。
6. 識別技術上不能實現的需求。當需求者面向用户時，代表的是身後的整個研發團隊，要做好需求分析，需要對自己團隊的技術能力有非常清楚的瞭解，哪些事情能做/不能做，又或者可以做但是需要太大的代價等，每個團隊都有自己的技術邊界。
九、整理需求前期做了那麼多的收集工作並確定需求之後，要做好需求的整理工作。需求整理是不是簡單的將用户所提的需求全部一條條寫下來就好了，而是一個綜合分析的的整理過程。
通過整理，使得需求更有目的性、更系統性、更明確、更容易理解。需求經過整理後一般會生成需求調研報告與業務流程圖，這是後面工作的綱領性文件。
當完成用户需求調查後，首先對《用户需求説明書》進行細化，對比較複雜的用户需求進行建模分析，以幫助軟件開發人員更好地理解需求。
十、需求不明確帶來的影響1. 項目失控甚至爛尾在開發時間和開發費用上的失控，因為需求的不完善，導致啓動開發前無法準確預估需求的工作量和確定技術實現方案，走一步看一步開發過程中，發現需求有坑，不斷髮現新的問題。
有時因為一個簡單的邏輯或設計不明確，在溝通明確後最終發現需要技術方案大調整，很多項目會變得失控甚至爛尾。
2. 技術腦補需求假如需求不是明確的話，靠譜的技術同學，就會自己考慮邏輯和設計，就按他自己的理解和想法實現。
看上去省心，但一千個觀眾就一千個哈姆雷特，一旦實現的邏輯可能並不是產品期望的邏輯，到了測試環節，測試同學也有自己的理解，導致又要花時間溝通統一意見，或浪費時間返工修改。
3. 溝通成本高項目規模越大，參與人數越多，矛盾越凸顯。
在面對的是人數眾多的設計師，前端團隊、後端團隊、外部團隊、測試團隊等時，產品經理需經常與設計、技術和測試溝通需求邏輯，溝通的成本會很高。
4. 產品邏輯難以後續追溯移動互聯網時代，產品上線迭代節奏非常快，產品不斷的迭代更新，或是人員的交接，經常需要回溯之前的線上邏輯，需求文檔的缺失或不完善，會導致線上邏輯不明確，甚至後續的產品需求設計的邏輯與線上矛盾或衝突，為項目的開發帶來麻煩。
參考資料：
- 《軟件工程》賴均 2016 清華大學出版社
- 《軟件需求分析實戰》楊長春 2020 清華大學出版社
- 《產品交互設計基礎》蔣曉 2016 清華大學出版社
- 《開發製作App時需求不明確，帶來哪些嚴重後果？》
本文由 @忻芸 原創發佈於人人都是產品經理，未經許可，禁止轉載
題圖來自 unsplash，基於 CC0 協議