『壹』 如何進行軟體需求分析
軟體需求建模的方法目前比較流行一般有三種：面向對象、結構化、面向問題域。傳統上一般採用結構化的方法，也就是面向過程、面向數據的方法，可以採用數據流圖、與ER圖的建模方法對流程和數據分別建模。而現在大家也在使用面向對象的需求分析方法，也就是採用USE CASE的方式描述需求，採用對象關系圖描述數據。比較新的方法是面向問題域的方法。
『貳』 怎樣做軟體的需求分析
軟體需求的定義：
（1）用戶解決問題或達到目標所需的條件或能力。
（2）系統或系統部件要滿足合同、標准、規范或其它正式規定文檔所需具有的條件或能力。
（3）一種反映上面(1)或(2)所描述的條件或權能的文檔說明。 實通俗的講，「需求」就是用戶的需要，它包括用戶要解決的問題、達到的目標、以及實現這些目標所需要的條件，它是一個程序或系統開發工作的說明，表現形式一般為文檔形式。
需求工程的定義：
需求分析的過程，也叫做需求工程和需求階段，它包括了需求開發和需求管理兩個部分。需求開發是指從情況收集、分析和評價到編寫文檔、評審等一系列產生需求的活動，分為四個階段：情況獲取、分析、制訂規格說明和評審。這四個階段不一定是遵循線性順序的，他們的活動是相互獨立和反復的。需求管理是軟體項目開發過程中控制和維持需求約定的活動，它包括：變更控制、版本控制、需求跟蹤、需求狀態跟蹤等工作。
需求開發與管理的一些方法：
（1）繪制關聯圖：繪制系統關聯圖是用於定義系統與系統外部實體間的界限和介面的簡單模型。
（2）可行性分析：在允許的成本、性能要求下，分析每項需求實施的可行性，提出需求實現相關風險，包括與其它需求的沖突，對外界因素的依賴和技術障礙。
（4）系統原型：當用戶自身對有的需求不十分清楚時，我們可以建立一個系統原型，用戶通過評價原型更好地理解所要解決的問題。。
（5）圖形分析模型：繪制圖形分析模型是編制軟體需求規格說明重要手段。它們能幫助分析人員理清數據、業務模式、工作流程以及他們之間的關系，找出遺漏、冗餘和不一致的需求。這樣的模型包括數據流圖、實體關系圖、狀態變換圖、對話框圖、對象類及交互作用圖。
（6）數據字典：數據字典是對系統用到的所有數據項和結構的定義，以確保開發人員使用統一的數據定義。在需求階段，數據字典至少應定義客戶數據項，確保客戶與開發小組是使用一致的定義和術語。
需求管理的方法主要包括以下一些方面：
1）確定需求變更控制過程。制定一個選擇、分析和決策需求變更的過程，所有的需求變更都需遵循此過程。
2）進行需求變更影響分析。評估每項需求變更，以確定它對項目計劃安排和其它需求的影響，明確與變更相關的任務並評估完成這些任務需要的工作量。通過這些分析將有助於需求變更控制部門做出更好的決策。
3）建立需求基準版本和需求控製版本文檔。確定需求基準，這是項目各方對需求達成一致認識時刻的一個快照，之後的需求變更遵循變更控制過程即可。每個版本的需求規格說明都必須是獨立說明，以避免將底稿和基準或新舊版本相混淆。
4）維護需求變更的歷史記錄。將需求變更情況寫成文檔，記錄變更日期、原因、負責人、版本號等內容，及時通知到項目開發所涉及的人員。為了盡量減少困惑、沖突、誤傳，應指定專人來負責更新需求。
5）跟蹤每項需求的狀態。可以把每一項需求的狀態屬性（如已推薦的，已通過的，已實施的，或已驗證的）保存在資料庫中，這樣可以在任何時候得到每個狀態類的需求數量。
6）衡量需求穩定性。可以定期把需求數量和需求變更（添加、修改、刪除）數量進行比較。過多的需求變更"是一個報警信號"，意味著問題並未真正弄清楚。
4.需求分析評價標准
（1）清晰：目前大多數的需求分析採用的仍然是自然語言，自然語言對需求分析最大的弊病就是它的二義性，所以開發人員需要對需求分析中採用的語言做某些限制。例如盡量採用主語＋動作的簡單表達方式。需求分析中的描述一定要簡單，千萬不要採用疑問句、修飾這些復雜的表達方式。 除了語言的二義性之外，注意不要使用行話，就是計算機術語。需求分析最重要的是和用戶溝通，可是用戶多半不是計算機的專業人士，如果在需求分析中使用了行話，就會造成用戶理解上的困難。
（2）完整：需求的完整性是非常重要的，如果有遺漏需求，則不得不返工，在軟體開發過程中，最糟糕的事情莫過於在軟體開發接近完成時發現遺漏了一項需求。但實際情況是，需求的遺漏是常發生的事情，這不僅僅是開發人員的問題，更多發生在用戶那裡。要做到需求的完整性是很艱難的一件事情，它涉及到需求分析過程的各個方面，貫穿整個過程，從最初的需求計劃制定到最後的需求評審。
（3）一致：一致性是指用戶需求必須和業務需求一致，功能需求必須和用戶需求一致。在需求過程中，開發人員需要把一致性關系進行細化，比如用戶需求不能超出預前指定的范圍。嚴格的遵守不同層次間的一致性關系，就可以保證最後開發出來的軟體系統不會偏離最初的實現目標。
（4）可測試：一個項目的測試從什麼時候開始呢？有人說是從編碼完成後開始，有人說是編碼的時候同時進行單元測試，編碼完成後進行系統測試，這些結論都不完全正確。實際上，測試是從需求分析過程就開始了，因為需求是測試計劃的輸入和參照。這就要求需求分析是可測試的，只有系統的所有需求都是可以被測試的，才能夠保證軟體始終圍繞著用戶的需要，保證軟體系統是成功的。
『叄』 軟體工程中常用的需求分析的方法有哪些
一、過濾需求的方法
做後端系統，要學會的第一個技能就是砍需求。也就是過濾需求。
這不是一個貶義詞，反而是體現後端產品價值判斷的基礎。
過濾需求的方法，就是通過一定的手段判斷需求是否是偽需求，應該被過濾掉。
1. 用戶場景模擬法
後端產品的出發點就是幫助業務用戶，因此在調研需求的時候要模擬業務的場景，分析業務用戶提到的需求是否能解決他的問題。
如果不能幫助用戶，那麼這個需求就可能是偽需求。
以下面的案例說明：
背景：「貨到付款」類型的訂單會因為缺貨而無法發出，如果超過一定的時間，客服就會跟顧客溝通，幫顧客取消訂單。
需求：由於這種訂單的數量還是蠻多的，逐個取消太費時間，因此業務用戶要求在「缺貨訂單」列表頁增加「批量取消訂單」按鈕。
分析：調研到業務操作場景,是先找到該類缺貨訂單，然後和顧客溝通，顧客同意刪除，才進行刪除。也就是逐個溝通確認，再逐個取消訂單的，所以「批量取消訂單」無法被有效使用。
因此，該需求是個偽需求，應該被過濾掉。
2. 功能歸屬分析
專門的系統做專職功能，有助於合理的產品體系建設。
因此需求調研的時候，可以通過系統的定位，判斷需求是否應該在該系統完成。
如果不屬於該系統范疇，那麼直接說服需求方更換方案。以
下面的案例說明：
背景：CRM系統（顧客關系管理系統）有一個顧客標簽生成功能，就是根據顧客的消費行為數據，自動對應關聯上標簽，如優質顧客、高潛力顧客、欺詐顧客等。
需求：業務用戶提出需求，除了做上述的基礎標簽之外，還要做出英語版本的標簽（就是把標簽文案翻譯成英文），這樣歐美員工可以在英語版本的系統下使用。
分析：調研到翻譯之後的標簽不是在CRM系統使用的，而是給到SMS（客服系統）使用的。
所以應該由SMS根據CMS提供的基礎標簽數據，自己做二次的衍生。
之所以這樣，首先是為了避免未來更多語言版本的擴展需求或更多系統提出類似的需求；
其次，CRM系統已經完成了「接力賽」的第一棒，創造了基礎數據，那麼其他系統要特殊化使用，完全可以自行進行特殊化處理，無需耦合回CRM系統。
結論：案例的需求本身是真需求，並且實現上也沒難度，但是該功能的定位超出了本系統范疇，專門系統做專職功能，化衍生需求應該在下游執行。
否則，耦合性過高只會增加系統的復雜程度，難以維護和擴展。
二、拆分和聚合的方法
1. 拆分需求法
業務用戶提出一個需求，很可能只是短短的一段話。
但是不要高興太早，可能這一句話暗含了很多線索，因此要善於拆分：
先找他要解決的核心問題，再圍繞核心點，理清前、後、左、右、上、下的旁系需求點。
每個需求點再當做一個子需求進行調研，最後再聚合在一起。
以下面的案例說明：
背景：訂單業務的類型很多，訂單退貨之後需要創建售後單據，但是因為數量大，所以花費很多人力，且手動創建有出錯的風險。
需求：業務提出的需求是「增加退貨訂單自動創建售後單的功能」，這是個一句話需求。
該一句話需求，其實包含了多種具體的訂單類型和場景，那麼我們就要拆分調研，拆分的維度比如：
自營訂單、第三方訂單、貨到付款訂單、先款後貨訂單、部分退貨訂單、完全退貨訂單、服裝事業部訂單、電子事業部訂單等，其中每一個維度就相當於一個小需求。
這里不一一展開。
2. 聚合需求法
拆分法是對單個需求分解成若干小需求進行調研，聚合法相反，是找到許多個相互關聯的小需求的共性，然後統籌成一個大需求去完成。例如：
由於業務用戶分散在不同的部門，各自為政，於是張三、李四可能都對一個業務流程有相同的需求，或者對同一個功能有相同的優化期望，結果倆人分別提了需求過來。那麼產品經理就要找到二者背後的相關性和交叉區。
然後統籌規劃，聚合在一起當作一個需求來調研，最終輸出一個整體的需求調研結果。
三、利用輔助功能調研需求
調研產品現有功能，可以用來確認原有功能的邏輯，或者確定新需求方案是否可行。
比如業務用戶需要更新一個功能，為了避免更新出錯或遺漏，產品經理需要知道修改前和修改後是否會能正常運行。
最基礎的辦法就是自己設計一個測試用例，記錄操作方式、狀態變化、數據流向等。看看下面的例子：
背景：從銷售網站獲取到OMS系統（訂單管理系統）的訂單信息中帶著顧客的郵箱。顧客下完單，可能會在銷售網站修改郵箱，而此時已經獲取到OMS的歷史訂單中的郵箱是不變的。
需求：顧客若在銷售網站修改郵箱，要求已獲取到OMS的該顧客的訂單中的郵箱也要同步修改。
分析：需求是很明白的，也有它的意義，但有風險。
因為我們知道訂單信息貫穿於整個訂單流轉過程中，牽扯到訂單編輯、審核、取消、配貨、發貨等，而這些環節跳轉的觸發條件可能就是某個信息更新（這裡面就可能包括有郵箱更新）。
因此，更新郵箱是否會影響流程中的某些環節，一時間很難准確知道。
於是，我們可以採用預測試的方式，設計測試用例，在測試機運行一些訂單，觀察各個環節郵箱變更的影響，然後收集起來分析對策。
測試法就像是探雷一樣，主要用來解決未知風險點。這個方式的重點是記錄和分析操作前狀態、操作位點、操作後狀態、操作後觸發的連鎖反應、數據流向等。
四、「拔蘿卜帶出泥」的方式調研需求
調研需求時，產品經理要拔蘿卜帶出泥,挖掘用戶沒看到的需求點和價值。
舉例說明：
背景：公司入駐到銷售平台後，銷售平台會對入駐的店鋪的違規行為進行罰款。
需求：業務用戶提出需求，將銷售平台的罰款數據抓取到訂單系統，關聯訂單數據，以便進行人工分析。
分析：
第一步，先拆分需求，確定什麼是罰款數據，總共有哪些罰款種類，需要對接哪些罰款種類，罰款數據與訂單系統關聯方式是什麼，是否都能關聯到，關聯不到怎麼辦，銷售平台是否已經提供了公用的罰款介面，Token（請求許可權）如何獲取，抓取頻率怎麼樣，數據增長幅度多大，獲取之後做哪些展示和搜索，用戶許可權怎麼設置，需要和訂單系統做哪些交互，該需求的價值是什麼……
第二步，挖掘需求：是否需要作分析功能，分析功能的規則是什麼；是否需要做監控和預警，是否需要指派負責人；其他業務人員是否也有類似需求，其他平台是否也有類似需求……
通過「拔蘿卜帶出泥」的方式，連帶出更多需求點。將上述調研結果重新組裝起來，得到一個系統化的完整需求。
羅列出需求要點和對應的驗收目標，這樣使得需求具象化，同時又不會遺漏細節，內部充實，外部閉環，並且進行了價值挖掘，做成控制閾值、預警、責任人分派、趨勢分析、損失分析等高價值的功能，超出業務的預期。
『肆』 需求分析方法主要包括哪些
結構化的分析方法是傳統的分析法，它的好處是在需求階段可以不需要精確地定義系統，只需要根據業務框架確定系統的功能范圍，以及每個功能的處理邏輯和業務規則，功能需求規格書等。因為不需要精確描述，因此描述系統的方式比較靈活多樣，可以採用圖表、示例圖、文字等等方式來描述系統。在系統開發以前，一般還可以採用更為直觀的原型系統方式和最終用戶進行交流和確認，因此對業務需求的要求會低一些，業務需求階段的周期相對容易控制；通過業務全景圖，最終用戶也能了解系統的功能；通過功能活動圖和業務規則的描述，也可以相對精確地描述業務系統；因為沒有嚴格的標記語言，可以採用適當的篇幅描述適當的系統。當然，這種方法的缺點也是明顯的，分析人員和業務人員之間可能缺乏共同語言，機器不能識別業務需求書，在設計階段還需要繼續和用戶確認一部分功能。
面向對象的分析方法的最大好處是在需求階段，就能夠非常精確地描述一個系統，採用程序語言的方式和最終用戶交流（最終用戶必須要熟悉這種語言），能夠在項目一開始就發現很多問題，避免在開發的過程中出現需求的反復，而且在系統設計和開發階段不需要最終用戶參與。在實施上，一般可以採用場景、業務功能等方式來描述，比較適合於業務流程環節多的系統，或者軟體產品的開發。但是，我們也要看到，在現實中，絕大多數的應用系統都很難在需求階段就可以被精確地抽象化定義，所以這種方法的缺點和困難也是顯而易見的：首先，用戶要非常清楚地知道最終的業務系統應該是什麼樣，或者採用一種抽象的方式能夠確定最終的應用系統；其次，因為最終用戶不需要參與設計和開發階段的工作，所以雙方確定業務需求的過程也會比較長；同時，因為是精確描述，因此描述系統的語言是非常邏輯化的，一般通過某種方式可以使機器識別業務需求，採用這種方式寫的業務需求是非常格式化的，一方面描述一個系統需要的信息非常多，可能使需求說明的篇幅非常長，不便於理解和閱讀；另外由於通過抽象的方式來推演最終系統的運行方式，對業務人員的要求非常高。
『伍』 需求分析的主要方法是
目前，軟體需求的分析與設計方法較多，一些大同小異，而有的則基本思路相差很大。從開發過程及特點出發，軟體開發一般採用軟體生存周期的開發方法，有時採用開發原型以幫助了解用戶需求。在軟體分析與設計時，自上而下由全局出發全面規劃分析，然後逐步設計實現。
從系統分析出發，可將需求分析方法大致分為功能分解方法、結構化分析方法、信息建模法和面向對象的分析方法。
(1)功能分解方法。
將新系統作為多功能模塊的組合。各功能義可分解為若乾子功能及介面，子功能再繼續分解。便可得到系統的雛形，即功能分解——功能、子功能、功能介面。
(2)結構化分析方法。
結構化分析方法是一種從問題空間到某種表示的映射方法，是結構化方法中重要且被普遍接受的表示系統，由數據流圖和數據詞典構成並表示。此分析法又稱為數據流法。其基本策略是跟蹤數據流，即研究問題域中數據流動方式及在各個環節上所進行的處理，從而發現數據流和加工。結構化分析可定義為數據流、數據處理或加工、數據存儲、端點、處理說明和數據字典。
(3)信息建模方法。
它從數據角度對現實世界建立模型。大型軟體較復雜；很難直接對其分析和設計，常藉助模型。模型是開發中常用工具，系統包括數據處理、事務管理和決策支持。實質上，也可看成由一系列有序模型構成，其有序模型通常為功能模型、信息模型、數據模型、控制模型和決策模型。有序是指這些模型是分別在系統的不同開發階段及開發層次一同建立的。建立系統常用的基本工具是E—R圖。經過改進後稱為信息建模法，後來又發展為語義數據建模方法，並引入了許多面向對象的特點。
信息建模可定義為實體或對象、屬性、關系、父類型/子類型和關聯對象。此方法的核心概念是實體和關系，基本工具是E-R圖，其基本要素由實體、屬性和聯系構成。該方法的基本策略是從現實中找出實體，然後再用屬性進行描述。
(4)面向對象的分析方法。
面向對象的分析方法的關鍵是識別問題域內的對象，分析它們之間的關系，並建立三類模型，即對象模型、動態模型和功能模型。面向對象主要考慮類或對象、結構與連接、繼承和封裝、消息通信，只表示面向對象的分析中幾項最重要特徵。類的對象是對問題域中事物的完整映射，包括事物的數據特徵(即屬性)和行為特徵(即服務)
『陸』 軟體需求分析4個步驟
一、需求分析理論
軟體需求涉及功能性問題非常廣，我們用抽象化理論分析，可以劃分各個功能域，用不同的數字代替，軟體——S，功能域——A1、A2……An
S＝{A1、A2、……An}
但是功能域B又存在若干問題P1、P2……Pm組成，並且每個功能對應於子系統中的一個軟構件，可以表示為-B＝{P1、P2、……Pm}
功能G有若干個行為F1、F2、……Fj，每個行為對應於軟體構件中的實現方法
G＝{F1、F2……Fj}
一個軟體包含了所有功能的集合，同時包含了實現所以功能的所有方法和演算法描述。需求分析是依據用戶動機，經過需求問題識別，進行分析、消除分馳和綜合，編寫用戶故事，評審；形成用戶需求與設計同步，設計滿足用戶需求目標。
需求開發方法貫穿這個產品生命周期，利用不同的開發方法論進行挖掘需求，幫助用戶找到問題，梳理問題，判斷產品實現功能的正確性、一致性和完整性，促使用戶在軟體設計啟動之前進行周密的、全面的思考軟體產品功能，用商業化行為解決需求與現實中存在的矛盾，解決用戶需求與商業化產品功能融合，解決規范和個性化需求。
二、軟體需求開發的目標
1、對實現的軟體做一個全面的描述，幫助用戶找到問題矛盾解決用戶場景痛點，幫助用戶在進行產品規劃時做到周密，全面產品定位需求
2、了解和描述軟體實現所需的全部信息，為產品設計、確認和驗證提供一個基準
3、為軟體產品管理人員進行軟體產品成本評估和編輯軟體開發計劃書提供保障
需求開發-軟體功能需求、軟硬介面、非功能性需求、設計約束、反向需求、閱讀支持信息。
軟體需求分析盡量提供軟體實現功能需求的全部信息，使軟體設計人員和測試人員不在需要和需求方進行接觸，保證需求分析的一致性和完整性。
三、軟體功能需求
描述軟體功能實現注意——
1、功能需求的完整性和一致性
2、功能描述的無異議和可追蹤
3、功能描述清洗和功能可測試
四、軟硬介面
1、人機介面
2、硬體介面
3、軟體介面
4、通訊介面
五、非功能性需求
1、運行環境
2、時間需求
3、處理容限、精度、異常處理機制等
4、可靠性要求、可維護性、安全性