如何做需求分析業務需求單 _經驗分享

業務需求，用戶需求，功能需求是什么意思？有什么區別我們的軟件產品或者項目，其需求都有三個層級和三個方面。一、我們首先看需求的三個層次軟件需求包括3個不同的層次――業務需求、用戶需求和功能需求。業務需求（Business requirement）表示組織或客戶高層次的目標。業務需求通常來自項目投資人、購買產品的客戶、實際用戶的管理者、市場營銷部門或產品策劃部門。業務需求描述了組織為什么要開發一個系統，即組織希望達到的目標。使用前景和范圍（vision and scope）文檔來記錄業務需求，這份文檔有時也被稱作項目輪廓圖或市場需求（project charter 或 market requirement）文檔。用戶需求（user requirement）描述的是用戶的目標，或用戶要求系統必須能完成的任務。用例、場景描述和事件――響應表都是表達用戶需求的有效途徑。也就是說用戶需求描述了用戶能使用系統來做些什么。功能需求（functional requirement）規定開發人員必須在產品中實現的軟件功能，用戶利用這些功能來完成任務，滿足業務需求。功能需求有時也被稱作行為需求（behavīoral requirement），因為習慣上總是用“應該”對其進行描述：“系統應該發送電子郵件來通知用戶已接受其預定” 。功能需求描述是開發人員需要實現什么。注意：用戶需求不總是被轉變成功能需求。產品特性，所謂特性（feature），是指一組邏輯上相關的功能需求，它們為用戶提供某項功能，使業務目標得以滿足。對商業軟件而言，特性則是一組能被客戶識別，并幫助他決定是否購買的需求，也就是產品說明書中用著重號標明的部分。客戶希望得到的產品特性和用戶的任務相關的需求不完全是一回事。一項特性可以包括多個用例，每個用例又要求實現多項功能需求，以便用戶能夠執行某項任務。系統需求（system requirement）用于描述包含有多個子系統的產品（即系統）的頂級需求。系統可以只包含軟件系統，也可以既包含軟件又包含硬件子系統。人也可以是系統的一部分，因此某些系統功能可能要由人來承擔。業務規則包括企業方針、政府條例、工業標準、會計準則和計算方法等。業務規劃本身并非軟件需求，因為它們不屬于任何特定軟件系統的范圍。然而，業務規則常常會限制誰能夠執行某些特定用例，或者規定系統為符合相關規則必須實現某些特定功能。有時，功能中特定的質量屬性（通過功能實現）也源于業務規則。所以，對某些功能需求進行追溯時，會發現其來源正是一條特定的業務規則。功能需求記錄在軟件需求規格說明（SRS）中。SRS完整地描述了軟件系統的預期特性。SRS我們一般把它當作文檔，其實，SRS還可以是包含需求信息的數據庫或電子表格；或者是存儲在商業需求管理工具中的信息；而對于小型項目，甚至可能是一疊索引卡片。開發、測試、質量保證、項目管理和其他相關的項目功能都要用到 SRS 。除此之外，對于需求層次，我們還有其它的分法：組織級需求->業務需求->用戶需求->功能需求（有時也叫行為需求）。組織級需求：一般代表著組織的愿景和目標。對于大的公司，一般是通過資深的咨詢顧問和咨詢公司得出的，呈現的方式是咨詢報告。比如在ITSM或者企業信息化這方面。典型的組織級的需求是：降低成本、減少庫存成本、提升IT服務部門在企業中的價值、通過ISO20000、提高IT服務的效率、提高員工的滿意度等。業務需求：是要完組織的使命，達成組織的愿景的各個業務流程和業務單元具有的需求。業務需求服從于組織需求。用戶需求：用戶級的需求，是在業務級的需求下，各個崗位協作完成業務而具有的需求。我們在軟件需求規格說明書中表述的需求其實主要是這一部分需求。功能需求：同樣，它代表著產品或者軟件需求具備的能力。一般是管理人員或者產品的市場部門人員負責定義軟件的業務需求，以提高公司的運營效率（對信息系統而言）或產品的市場競爭力（對商業軟件而言）。所有的用戶需求都必須符合業務需求。需求分析員從用戶需求中推導出產品應具備哪些對用戶有幫助的功能。開發人員則根據功能需求和非功能需求設計解決方案，在約束條件的限制范圍內實現必需的功能，并達到規定的質量和性能指標。當一項新的特性、用例或功能需求被提出時，需求分析員必須思考一個問題：“它在范圍內嗎？” 。如果答案是肯定的，則該需求屬于需求規格說明，反之則不屬于。但答案也許是“不在，但應該在”，這時必須由業務需求的負責人或投資管理人來決定：是否擴大項目范圍以容納新的需求。這是一個可能影響項目進度和預算的商業決策。二、需求的三個方面除了功能需求外，SRS中還包含非功能需求，包括性能指標和對質量屬性的描述。質量屬性（quality attribute）對產品的功能描述作了補充，它從不同方面描述了產品的各種特性。這些特性包括可用性、可移植性、完整性、效率和健壯性，它們對用戶或開發人員都很重要。其他的非功能需求包括系統與外部世界的外部界面，以及對設計與實現的約束。還有一項稱為可用性（usability）的質量屬性，它規定了業務需求中“有效”（efficiently）一詞的含義。約束（constraint）限制了開發人員設計和構建系統時的選擇范圍。約束，在產品的架構設計中，是需要被首先考慮的問題。如果說產品的功能代表了產品的能力，那么產品的質量屬性代表了產品的品質，產品的約束代表了產品必須去滿足的或者適應的條件！用人說“用戶體驗”是產品的靈魂，對于個人級的軟件這么說或許很恰當，當對于企業級甚至是行業級的產品，其靈魂有兩個：一個是產品帶個用戶的價值，另一個是產品的品質，簡單的說，就是價值和品質。但其成為一個產品的前提應該是滿足約束，否則就不應該設計、開發、進入市場而成為一個垃圾。用戶需求功能需求區別簡單的就是：用戶需求。用戶需要在應用系統中實現什么東西，為實現這個目標，需要用戶提供的全部的詳細的業務說明，業務流程，表格樣式等。功能需求。將用戶需求歸類分解為計算機可以實現的子系統和功能模塊，用設計語言描述和解釋用戶的需求，以達到可以指導程序設計的目的。
如何做需求分析？你這個問題問的有點太大了，不知道怎么回答，需求的工作存在很多靈活性，很難整理出一個流程性的東西，我也是正在學習，最近在學習徐峰老師的《軟件需求實踐》，把我知道的拿出來分享，錯了的話請大家糾正，但是不要噴我啊！妹子心里素質不行，嘿嘿
1、需求是有層次的，分為業務需求、用戶需求以及系統需求，所以在進行需求分析時肯定是要根據不同層次階段進行不同方式、內容以及側重點的需求調研。
1）業務需求，一般是公司的高層提出的，就是我們這個系統的指導需求，這個需求比較空，但是卻是整個系統需求的指導思想，在做需求時經常想想這個知道思想，可以防止需求跑偏。
2）用戶需求，一般是公司的中層和操作層提出的需求。中層突出流程，就是整個框架，而操作層提出具體的細節性需求。就是往中層的框架里面添加需求細節。
3）系統需求，就是針對前兩種需求調研之后得結果進行需求分析和業務建模之后，得到了系統開發的需求。
2、需求的步驟分為：需求定義（對應上面的業務需求）、需求捕獲（對應上面的用戶需求）、需求分析與需求建模（對應上面的系統需求）、需求驗證、需求跟蹤、需求管理。
3、做需求工程中可以使用的工具：AXURE（用來制作原型，讓用戶更直觀的了解即將做成什么狀態的系統，便于需求確認）、EA（是建模工具，用來繪制UML圖，“一圖抵千言”為了更好的表達需求和溝通需求）、word、Excel、Visio等工具。
erp系統的業務需求怎么寫你是公司內部職員還是給客戶做ERP實施的實施顧問呢？要是公司內部職員的話，這個需求很簡單啊，你就把你平時的工作梳理一下，把你覺得那些東西希望讓通過ERP軟件來完成，你把這些列舉出來就行了，另外還有你對軟件的一些要求都是i可以跟他們提出來的。要是你是ERP實施人員的話，這個也好寫啊，根據客戶提出來的需求做一個分析，那些是現有軟件能實現的，那些是不能實現的，需要通過開發來實現，把這些分析一下，寫成一個文檔，就形成了業務需求報告了。
怎么編寫用戶業務需求分析需求分析
格式
1 引言
1.1 編寫目的
【說明】目標：對用戶的需求進行收集、整理與分析，弄清楚系統究竟要 “干什么”及“由誰干”，并用合乎規范的文字及圖表予以描述。不需要說明“怎么干”，因為那是設計階段的事情。有關文字與圖表應盡量讓用戶便于理解。
預期讀者：用戶方的相關業務人員、雙方的開發人員和系統維護人員。
作用：實現開發方與用戶方的雙向溝通，是把業務需求計算機化的關鍵步驟。
為下一階段的概要設計工作提供依據。當用戶的需求發生變更時，應添寫補充說明；如變動過大可形成新版本。
軟件需求說明（Software Requirements Specification）的主要作用為：
? 為用戶方與開發方建立共同協議奠定基礎。
? 提高開發效率、強化進度控制。
? 為項目的的評測與驗收提供依據。
? 便于移植。
? 作為系統不斷提高的基礎。
1.2 編寫背景
1.2.1 系統名稱及版本號
【說明】形如“網銀三期***系統V3.0.0” 。其中，版本號的格式為“XX.XX.XX”，X為阿拉伯數字，左“0”可省略。
1.2.2 使用者
【說明】適應對象和范圍。主要指預期讀者，也供有關領導審閱。
1.2.3 與其它系統的關系
【說明】在用戶現有的及預期的整個應用系統中，給本系統準確定位。用示意圖及相應的文字予以說明。
2 用戶的基本情況
2.1 系統建設背景
【說明】項目背景與依據、現有基礎、項目規模、預期目標等。可繁可簡，格式自定。
2.2 組織機構與職能
【說明】用層次示意圖及相應文字表示(如果需要開發的系統與部門沒有直接依賴關系此節可省略,本章隨后的小節數將順次減1)，
加注：組織機構的層次數、數目、各個機構的職能簡述。
2.3 用戶特點
【說明】所在行業特征、操作人員與系統維護人員的數量、學歷與水平、數據量大小、使用頻度等。
2.4 用戶業務分析
【說明】在本部分，希望系統分析人員能夠對用戶業務現狀進行分析、對用戶對本系統的未來發展方向作出一定的預測等。以便設計人員對業務及其發展有所了解，增強系統設計的前瞻性。
2.5 計算機應用現狀
【說明】可繁可簡，格式自定。
3 業務需求
3.1 項目概述
【說明】
第一、指明項目的開發意圖、應用目標（總目標、分期目標）、作用范圍、預期效益等。
第二、指明在輸入信息轉變為輸出信息的過程中，為了滿足用戶的業務需求，應用軟件必須完成的基本功能(采用自然語言敘述) 。但此時不要求對基本功能進行分解。
第三、如果本系統與其他系統相關聯，則應確定本系統的基本功能邊界（可采用圖示+文字說明的形式，用藍色標示出本系統的功能，用綠色標示出相關系統的功能）。
3.2 約束條件
3.2.1 費用約束
【說明】預計投資金額概算、其中軟硬件費用的比例、資金分期到位計劃。
3.2.2 進度約束
【說明】預計完成日期、分步實施期限。
3.2.3 其它約束
【說明】場地面積限制、通信設施基礎、其它干擾因素。
注意：任何計算機系統都不是包羅萬象的；用戶自身的能力也是有限的。輕諾必寡信。故應特別指出：由于哪些條件的約束，本系統不能滿足哪些業務需求與系統需求。
本章主要介紹項目的總體業務功能,要求站在客戶的角度把握系統需求.
3.3 性能需求
【說明】依據ISO9000標準及我們的理解，下面列出了軟件的6組性能，共涵蓋21個子特性。這些性能/子特性的相對重要性并不是等同的。編寫時，可以基于具體項目的實際需求，對下述標題或內容進行取舍/側重。事實上不可能做到面面俱到，往往要作出某些折中。
本節說明系統在性能方面的預期目標，不要求提供實現上述目標的具體實施方案。
3.3.1 功能性
【說明】指與軟件實現的各項功能及其指定性質有關的一組屬性。這些功能都是滿足規定需求和潛在需求所必需的。它包括5個子特性：
適用性：與指定業務所需各項功能的實現及其適合程度有關的一些軟件屬性。
準確性：與保證正確（或符合要求的）結果（或效果）有關的一些軟件屬性。
互操作性：與軟件同一些指定系統交互作用能力有關的一些軟件屬性。
復合性：使軟件遵守相關的標準、約定/法律或類似規定有關的一些軟件屬性。
保密安全性：與針對蓄意（或無意）而非法存取程序和數據的預防能力有關的一些軟件屬性。這里主要指的是保護軟件的要素，旨在防止各種非法訪問、修改、破壞、泄密及感染計算機病毒等。
3.3.2 可靠性
【說明】指在規定的條件和期限內，與軟件保持其性能水平有關的一組軟件屬性。
成熟性：與軟件故障引起的失誤頻率有關的一些軟件屬性。
容錯性：在軟件故障發生或其規定界面被破壞的情況下，與軟件仍能保持規定性能水平的能力有關的一些軟件屬性。
可恢復性：在失效的情況下、在限定的期限和強度范圍內，與軟件重建性能水平并恢復直接受影響的數據的能力有關的一些軟件屬性。
3.3.3 易使用性
【說明】指與規定用戶（或潛在用戶）使用軟件所需的努力程度、對這種使用所做的評估有關的一組軟件屬性。它包括3個子特性：
易理解性：與用戶為理解其邏輯概念及適用范圍需做的努力有關的一些軟件屬性。
易學習性：與用戶學習其應用（例如操作控制、輸入、輸出）需做的努力有關的一些軟件屬性。
易操作性：與用戶操作及運行控制需做的努力有關的一些軟件屬性。
3.3.4 高效性
【說明】指在特定的運行環境中，描寫軟件性能水平與所用的資源量之間關系的一組軟件屬性。它包括兩個子特性：
時間特性：在完成軟件功能時，與響應時間、處理時間、吞吐率有關的一些軟件屬性。
資源特性：在完成軟件功能時，與所用資源量及占用時間有關的一些軟件屬性。
3.3.5 可維護性
【說明】與對軟件進行指定的修改所需的工作量有關的一組軟件屬性。它包括4個子特性：
易分析性：與診斷故障、確定失敗原因、在需要修改的部位進行標識等所做努力有關的一些軟件屬性。
易修改性：與實施修改、排除故障、環境改變所做努力有關的一些軟件屬性。
穩定性：與修改的意外影響帶來的風險有關的一些軟件屬性。
易測試性：與對經過修改的軟件進行檢驗/確認做努力有關的一些軟件屬性。
3.3.6 可移植性
【說明】指軟件從一個環境轉移的另一個環境時，與其適應能力有關的一組軟件屬性。它包括4個子特性：
適應性：除已有手段外，無須采用其它措施或手段，軟件便應能適應指定的環境。與這種能力有關的一些軟件屬性稱為適應性。
易安裝性：在指定環境內，與安裝軟件所需努力有關的一些軟件屬性。
一致性：軟件從一個環境轉移的另一個環境時，應符合一定的標準和約定。與這種符合程度有關的一些軟件屬性，稱為一致性。
易替換性：有時會出現這種需求：在某個其它軟件的運行環境下，要用本軟件來置換那個軟件。與這種可能性及所需努力有關的一些軟件屬性。
4 用戶需求
【說明】本章下面介紹的是一般規模軟件系統的書寫格式。在書寫過程中可能要以業務名稱劃分小節(例如:5.1 代收電話費) 。每個業務小節包含兩個部分：第一部分是對此業務中角色和功能的定義；第二部分是此業務的圖形分析方法。
在本章開始未分節的部分，應當繪制一個總體結構圖，依據這個總體結構圖進行一個總體描述，使得閱讀者對下面分節描述的各個功能形成一個整體印象。這個總體結構圖不一定是指在ROSE工具中繪制的用例總圖，而是根據需要可以選擇包括“用例總圖”、“適當級別的數據流圖”、“IDFF圖”、“數據流程圖”或其他專業圖形分析圖示等。
每個小節中的第二部分采用rational公司的rose2000作為工具繪制用例（use case）圖和順序（sequence）圖。在這里采用rose工具是作為繪圖分析工具使用，對需求的描述和分析并不代表我們的設計采用UML標準和面向對象的設計，具體分析人員應當根據實際的用戶需求描述繪制順序圖，而并不著重考慮對象的分析限制。
需求變更的處理原則：獲得批準的需求變更，需要在《需求分析》中有所體現。增加的需求，需直接從本章尾部順序添加，相應的小節編號也需要依次增加。例如：本章小節為5.1—5.5，增加的需求小節編號則為5.6 。刪除的需求，不需要將相應需求直接從《需求分析》中刪除，而只需在相應需求小節上注明刪除，并標出《需求變更單》編號。修改的需求，可在相應的需求小節直接修改。所有對《需求分析》內容的修改必須在修改歷史中留有記錄。
4.1 業務名稱1
4.1.1 角色/功能定義
【說明】根據會議紀要、小組討論，確定系統中的角色（角色可以為外部系統或系統用戶），和功能，并給出相應的定義或解釋。
4.1.2 圖形分析
【說明】本節主要描述相應業務的用例圖和順序圖的內容
統一建模語言（UML）是一個通用的可視化建模語言，用于對軟件進行描述、可視化處理、構造和建立軟件系統制品的文檔。它記錄了對必須構造的系統的決定和理解，可用于對系統的理解、設計、瀏覽、配置、維護和信息控制。UML適用于各種軟件開發方法、軟件生命周期的各個階段、各種應用領域以及各種開發工具，是一種總結了以往建模技術的經驗并吸收當今優秀成果的標準建模方法。
在本需求模板中我們選取的是UML視圖來輔助進行圖形需求分析，選用Rational公司的ROSE工具完成。在需求分析過程需要完成結構分類中的用例分析，繪制用例圖；對用例的動態行為進行交互分析，描述執行系統功能的各個角色之間相互傳遞消息的順序關系，繪制順序圖。
在這里請作者將制作的用例圖和順序圖拷貝到本文檔中。
基本成分：用例（use case）、用例視圖（use case view）、角色（role、actor）、順序圖（sequence diagram）、協作圖（collaboration diagram）。
模板和命名：為更好地使用ROSE圖形分析工具，我們設定一個基本的分析模板，文件名為lansoftmdl.mdl 。該文檔涉及項目開發的需求、概設和詳設3個階段，在需求階段主要完成模板中用例視圖（use case view）規定完成的部分。在項目中使用該模板后生成的mdl文件納入文檔的配置管理，具體命名參照SEMP體系的命名規定。修改歷史記入文檔開始部分的“mdl文檔修改歷史表”中。
【ROSE使用要求】
1、要求使用ROSE工具時必須完成模板和使用要求中規定完成的內容，在完成基本內容的基礎上，可以根據需要增加部分內容。
2、在公司沒有購買確定版本的ROSE以前，使用的ROSE版本應在項目開始前在項目組規定好，并由配置管理員負責配置。
3、在用例視圖（use case view）中建立一個名稱為main的主用例圖（use case diagram），具體內容應當包括所有用例圖的全部內容，具體應用時還可以根據情況建立多個用例圖（use case diagram）。
4、在用例視圖中請采用中文對所有的角色（actor\role）進行命名。其中角色必須在雙擊該對象圖后，詳細填寫該角色的描述（documentation）和該角色代表的角色數量（detail-multiplic）。
5、在用例視圖中請采用中文對所有的用例（use case）進行命名。命名中在一般的中文概括前應增加代表本節編號的部分，如“1.用戶認證”，順序編號。其中用例必須在雙擊該對象圖后，詳細填寫該用例的描述（documentation）。
6、在每個用例下必須組織建立相應的順序圖（sequence diagram），對于一個用例可以包含多個順序圖（sequence diagram），各個順序圖（sequence diagram）的命名需在一般的中文概括前增加代表本節編號的部分，如“1.1用戶認證”，順序編號，其中第一個1代表所屬的用例，第二個1代表順序圖（sequence diagram）的編號。產生順序圖的數量根據說明需求的具體要求設定。其中順序圖中的各個對象消息（object message）必須在雙擊該對象圖后，詳細填寫該對象消息（object message）的描述（documentation）。
4.1.3 數據存儲需求
【說明】根據會議紀要、小組討論，對于在需求調研中有關的數據實體對象或數據實體信息，應當根據需要提出可能數據類型和數據長度以及單位量綱的記錄或建議。
5 運行環境
【說明】本章只提出運行環境的邏輯結構，物理結構將在《概要設計說明書》中給出。
容許提出幾種可選方案。
5.1 硬件平臺
【說明】指出本應用軟件適用的主機/服務器與終端/工作站的技術指標、基本配置、接口特點、特殊約定等。
應盡可能地說明上述設備在各級用戶機構預計的分布狀態。
5.2 網絡平臺
【說明】選型標準、網絡類型、基本部件、接口情況、對綜合布線的要求、限制條件等。應畫出網絡（廣域網、局域網）的拓撲結構圖，說明后者對前者的接入方式。
5.3 軟件平臺
【說明】操作系統的名稱、生產廠家、版本號等。
數據庫的名稱、生產廠家、版本號等。
數據庫設計工具的名稱、生產廠家、版本號等。
網絡通信協議的名稱、生產廠家、版本號等。
前端開發工具的名稱、生產廠家、版本號等。
測試開發工具的名稱、生產廠家、版本號等。
現場運行時需要的工具軟件的名稱、生產廠家、版本號等。
配置管理工具軟件的名稱、生產廠家、版本號等。
6 附錄
【說明】列出基礎素材中的文件、報表、單據等的樣張，再附上必要的注釋。
如果條件成熟，可以把數據字典（data dictionary）作為附件列于后。
6.1 電子文檔編寫方式與使用工具
【說明】編寫要求、工具名、版本號、操作系統平臺。使用多種工具時，應分別說明。形如：
Microsoft Word 97 for Windows 95/98
Power Designer 6.0 for Windows 95/98
Rational Rose 98 for Wintel
Visio或Power Point 97 for Windows 95/98
6.2 定義說明與符號
【說明】包括對專用術語及縮略語的解釋、所用到的圖（如use case、sequence圖）之圖符的表示與解釋等。
6.3 參考資料
【說明】格式：作者，[版本號，]資料來源，日期 [，起止頁號]。其中，《質量保證計劃》是必選的參考資料。
6.4 有關表格清單
【說明】列出用戶提供的素材，加上我們積累的有關文件，作為系統分析的基礎。在這里除系統內部沒有用戶參與的需求分析工作外，必須包括一個以上的用戶訪談紀要、用戶確認簽名文件以及用戶訪談計劃等文件的列表。在列表中的文件應當作為附件與需求文檔共同納入配置管理
如何把業務需求轉換成程序員需求作為程序員，作為需求分析設計人員，更應該明白客戶就是上帝。在與用戶交流的時候，不要把客戶想象成架構師，要把他們當做“白目”來對待，因為客戶的沒有開發過軟件的經驗，他們表達的想法不是按照程序來執行。如果程序員只是一味的揣測客戶的意愿，而不能自己的所想轉換成原型，那么很可能會弄巧成拙。比如客戶甲說想要在應用軟件中加個公雞報時的功能。程序員A以為客戶想要一個公雞寵物，點擊時可以報時，而實際上客戶是想讓軟件可以設置鬧鐘，在某個時間點發出公雞鳴叫的聲音。可想而知，設計出來的寵物再好，也不是用戶所需要的。也許有一些客戶是屬于“鉆石王老五”類型的，他們對軟件一竅不通，偏偏還在和你談需求，他們會對軟件提出很多意見，他們會很固執的讓我們按照他的思想去設計、實現，盡管那樣可以，但是軟件的性能及維護性將大大降低，這時候我們需要去主動的引動客戶，不是客戶左右了你，就是你左右了客戶。如果客戶左右了你，盡管可能你按照客戶的需求把軟件設計出來了，但這卻是一個失敗的軟件，因為它的運行效率很低，而且需求又經常發生變動，而這個軟件沒有絲毫的可擴充性，那么最后客戶會說這個軟件設計師給他們設計的軟件不夠好，而不是客戶影響了正常的開發，那么作為軟件的需求分析設計師就應該對這件事會責任。業務需求是通過對業務流程、業務目標、業務實體類型和決策過程的業務模型的分析捕獲的。業務需求應或可以通過一組關鍵性能指標進行度量，以便提供有關實現要求和滿足業務需求方面的成功程度的反饋。它們是通過一個對變化進行劃分、分解、細化、映射和分析的過程（面向變化的分析和設計）解釋的。劃分是將業務域分解為域組成類型或功能區域。這表示結構劃分。業務的分解是對如何將流程分解為子流程和用例的解釋。分解過程將創建一個分層結構，而細化過程則將這個分層結構細化為一組可操作的面向目標的交互序列。
什么是業務需求和用戶需求業務需求表示組織或客戶高層次的目標。業務需求通常來自項目投資人、購買產品的客戶、實際用戶的管理者、市場營銷部門或產品策劃部門。業務需求描述了組織為什么要開發一個系統，即組織希望達到的目標。
用戶需求描述的是用戶的目標，或用戶要求系統必須能完成的任務。用例、場景描述和事件，響應表都是表達用戶需求的有效途徑。也就是用戶需求描述了用戶能使用系統來做些什么。
擴展資料：
注意事項：
業務需求是偏向宏觀的，偏向生產者的。騰訊微信團隊開發微信這款產品的目標：做一個流量大，覆蓋范圍廣的即時通訊軟件→做多平臺入口，購物金融等等→未來
如何引導用戶使用，如何盈利，如何推廣運營，這些都屬于微信的業務需求。
用戶需求以用戶為中心，設定場景，事件或用例，分析用戶需要的功能。微信中中用戶希望可以個性化設定頭像，于是上傳用戶頭像是一定要滿足的用戶需求之一。
參考資料來源：百度百科-需求分析
參考資料來源：百度百科-用戶需求分析
參考資料來源：百度百科-業務

【如何做需求分析業務需求單】關于業務需求和業務需求單的內容就分享到這兒！更多實用知識經驗，盡在 m.apearl.cn

如何做需求分析 業務需求單

如何做需求分析業務需求單