1樓：2杭瓷
當我們進行業務流程分析時，只空對空而不落到紙面上是不可以的。過去，在面向過程的時代，我們繪製dfd圖、流程圖，以及編寫流程說明來描繪這一部分分析；而現在，在物件導向的時代，我們則是繪製行**、狀態圖，以及編寫用例說明來完成這部分工作。
毫不疑問，做用例分析首先是要繪製出用例圖（前面已經說過了）。圖形的最大優勢是能夠形象生動地描述我們的分析，但它最大的缺點是會遺失許多的細節資訊，因此我們必須要對它進行進一步的文字描述。
由於不同的人對用例的理解不同，格式也不盡相同，但一些基本的元素是一樣的。以上**是我採用的用例說明格式，其中用例名稱、用例描述、參與者、前置條件、事件流、後置條件是公認的、用例說明的基本元素。
用例標識：就是用例的編號，一般採用「專案編號-子系統編號-模組編號-序號」來編號。
用例名稱：沒啥可說的，就是用例圖中該用例的名稱。注意用例的命名規則：
用例名稱通常是乙個動詞短語或短句，而不是乙個名詞短語。它可以是乙個動詞（如：自動考核），乙個動賓短語（如：
提取存款），乙個被動句（如：發票填報），或者乙個主謂句（如：使用者提款，這個不推薦，因為主語就是參與者，顯得有些多餘）。
參與者：用例圖中該用例的參與者，通常是業務操作的觸發者和施與物件（如外部系統）。
前置條件：在觸發該用例相關操作前必須達到的條件。
事件流：這是用例說明中最重要的部分，它詳細描述了該用例可能出現的所有流程。
1. 基本流程：另乙個名稱更能表達它的意義：
最佳流程（the best flow）。它描述的是該用例以最佳的、最正常的方式流轉，沒有出現任何異常，並且最終成功完成操作的流程。基本流程在編寫時，應當通過數字對流程中的每一步進行編號。
2. 擴充套件流程：或者叫「分支流程」，它描述的是基本流程在流轉過程中可能出現的所有分支。
擴充套件流程最大的特點就是，它應當是在基本流程的某一步驟發生的分支，因此它的編號規則是「基本流程號+序號」。基本流程號就是發生分支的那乙個基本流程的編號。在同乙個基本流程上發生多個分支時，它們的序號從1依次開始編號。
另一種情況是，某個擴充套件流程本身擁有多個步驟，這時應當在「基本流程號+自身序號」的基礎上再新增序號，如「2.1.1」。
擴充套件流程在描述時，應當首先描述進入這個分支的條件，即「如果××則××」、「當××時××」。
3. 異常流程：就是發生異常情況時的處理流程。
注意，用例說明是站在用例角度進行的說明，因此這裡並不是我們通常一樣的發生程式異常的處理流程，而是使用者在處理業務操作時發生的異常情況，如：如果顧客不能提供身份證，則616161616161
後置條件：又稱為「成功保證」，就是執行基本流程獲得成功以後所達到的狀態（條件）。後置條件往往體現的是執行該用例的最終目的。如：完成使用者檔案的填寫並提交。
非功能需求：簡稱為「urps+」，即可用性（usability）、可靠性（reliability）、效能（performance）、可支援性（supportability）以及其它（+）。這一部分的需求分析相當重要而又最容易被忽略，後面我們再詳細討論。
假設與約束：就是隱藏於業務功能中的各項規則與條件，如各種邏輯條件、計算公式、環境限制等等。
除此之外，我還往往在每乙個用例說明的後面與該用例相關的需求列表，便於需求跟蹤。用例分析實質是需求人員的乙份設計。既然是設計就可能出現偏差，最終偏離原始的需求（這種情況特別容易出現在日後的公升級維護中）。
因此，將需求列表附在用例後面，便於日後的需求評審與確認。當每次需要公升級時，則新增上新的需求，或對以往的需求進行更新。
我們應當怎樣做需求分析我們應當怎樣做需求調研：初識我們應當怎樣做需求調研：拜訪我們應當怎樣做需求調研：
研討會我們應當怎樣做需求調研：需求研討我們應當怎樣做需求調研：迭代我們應當怎樣做需求調研：
需求捕獲（上）我們應當怎樣做需求調研：需求捕獲（下）我們應當怎樣做需求分析：功能角色分析與用例圖我們應當怎樣做需求分析：
業務流程分析（上）我們應當怎樣做需求分析：業務流程分析（下）我們應當怎樣做需求分析：查詢報表分析我們應當怎樣做需求分析：
子用例與擴充套件用例我們應當怎樣做需求分析：行**和狀態圖我們應當怎樣做需求分析：業務領域分析我們應當怎樣做需求分析：
原文分析法我們應當怎樣做需求分析：領域驅動設計我們應當怎樣做需求分析：非功能需求我們應當怎樣做需求確認：
需求列表我們應當怎樣做需求確認：乙個需求列表的例項我們應當怎樣做需求確認：快速原型法我們應當怎樣做需求確認：
需求規格說明書我們應當怎樣做需求確認：評審與簽字確認會（續）
我們應當怎樣做需求分析：功能角色分析與用例圖
2樓：匿名使用者
在我們進行一系列需求調研工作的同時，我們的需求分析工作也開始啟動了。需求調研與需求分析工作應當是相輔相伴共同進行的。每次參加完需求調研回到公司，我們就應當對需求調研的成果進行一次需求分析。
當下一次開始進行需求調研時，我們應當首先將上次需求分析的結果與客戶進行確認，同時對需求分析中提出的疑問交給客戶予以解答。這就是乙個需求捕獲->需求整理->需求驗證->再需求捕獲的過程。
但是，當我們經過一番忙碌，將需求中的第一手資料從調研現場捕獲回來以後，我們應當怎樣進行分析呢？不少團隊對此都比較迷茫，沒有乙個統一和有效的方法，往往採用想到**做到**的方式。一些問題想到了就做了，沒有想到則忽略掉了。
實際上，需求分析不應當是太公釣魚，而應當是拉網排查。任何乙個疏忽都可能對專案研發帶來風險。因此，我們應當採用一套成熟而完整的分析方法，穩步而有序地完成這部分工作。
不同型別的軟體專案其分析方法可能存在差異，但一般來說，資訊化管理類軟體專案通常從這幾個方面著手分析：功能角色分析、業務流程分析與業務領域分析。
需求分析不是一項一蹴而就就可以完成的工作，它需要乙個長期的過程，而這個過程是乙個由粗到細的過程，它體現了人類認識事物的客觀規律。在需求分析的初期，我們對需求的認識往往是整體的、巨集觀的，隨著分析工作的逐漸深入，一步步細化。按照這個思路，我們對需求的分析，首先應當從功能角色分析開始。
所謂功能角色分析，就是從乙個外部使用者的視角分析整個軟體系統能夠提供的功能，以及這些功能到底是提供給哪些角色使用。
對乙個系統進行功能和角色方面的梳理和分析，可以採用的比較主流的方法之一就是繪製用例圖。用例圖是uml的4+1檢視中的一種，準確地說就是那個「+1」。用例圖是貫穿整個物件導向分析/設計（ooa/d）的核心檢視，它描述的是系統到底為使用者提供了哪些功能，以及到底是哪些使用者在使用這些功能，是溝通使用者與技術人員的橋梁。
運用用例檢視對業務需求進行分析、抽象、整理、提煉，進而形成抽象模型的過程稱之為用例建模，而這個模型就是用例模型。
一般地，在乙個用例圖中通常有三種元素：參與者（actor）、用例（use case）與系統邊界（boundary）。用例描述的是系統為使用者提供的功能，也就是系統能為使用者做什麼，通常被繪製成乙個橢圓；參與者，我認為稱為角色更加合適，也就是系統為哪些型別的使用者提供服務，他們都各自承擔哪些不同的職責，通常被繪製成乙個小人兒；最後是系統邊界，也就是系統是對現實世界哪個範圍的內容進行的模擬，它涉及到軟體設計的工作範圍與工作量，通常被繪製成乙個方框。
但是，通常情況下系統邊界只是乙個概念而不用真正繪製出來，因為被繪製成用例的必然是系統內部的功能，被繪製成參與者的必然是系統外部事物。從這個意義上講，用例圖中的參與者不僅包括人，還包括那些外部系統和自動觸發器。根據這樣乙個思路，我以往常常將外部系統和自動觸發器繪製成乙個小人，這常常令客戶感到困惑。
隨後我改變了思路，將外部系統和自動觸發器繪製成另一種表達形式——類元符號表示法，並在構造型上標註為actor。
上圖是乙個考核系統中乙個子模組的用例圖。圖中的用例就是這個系統提供給使用者的各項功能。注意，這裡僅僅是在羅列功能而不表示它們之間諸如流程呼叫等相互關係，這是一些初學者常常犯的毛病。
參與者與用例通過實線關聯起來，代表的是一種使用關係。箭頭代表的是一種導航，即動作施與的方向。在這個用例圖中，普通使用者執行查詢操作，查詢系統提供的「預警監控單項查詢」、「預警監控彙總查詢」等查詢報表；每日自動觸發器觸發自動考核功能，自動考核功能從「稅收徵管系統」這樣乙個外部系統中採集資料。
在繪製用例圖時乙個值得思考的細節是，用例是怎樣通過分析獲得的。這個問題，在一些客戶對資訊化管理比較有經驗的專案中不存在問題，因為在客戶提供給我們的需求文件中就清晰地劃分出了一項一項的功能。這些功能可能會在日後的需求分析工作中有所調整，但它從整體上形成了乙個雛形，成為我們進行用例分析進而形成用例的依據。
有人說，我們繪製的用例圖拿給客戶看不懂。這樣乙個清晰明了的用例圖，輔之以我們對圖形的描述，客戶怎麼會看不懂呢？關鍵問題在於，我們沒有將用例圖的精髓弄明白，再加上出現一些常見問題，使得用例圖畫得不倫不類，客戶當然就看不明白了。
現在我們看看用例繪製都有些什麼常見問題。
1. 沒有正確理解用例圖的視角。前面我反覆強調了，用例圖的視角是使用者，也就是說，站在使用者的角度來觀察的我們需要設計的系統。
從這個視角，使用者看到的系統是什麼呢？當然是一項一項的功能，這些功能是客戶能夠理解的、具體的、對客戶存在價值的功能。從這個意義上說，那些技術性的功能不應當出現在這裡，或者應當描述為使用者可以理解的文字，比如「自動考核」。
而那些應當繪製的用例，在取名時也應當站在使用者角度去取名。舉個簡單的例子，乙個員工檔案資訊系統，以往我們總愛將用例取名為「新增員工資訊」、「更新員工資訊」、「刪除員工資訊」，這就是典型的技術人員編寫的用例。「新增員工資訊」對於使用者來講應當是做什麼呢——填寫新員工資料；「更新員工資訊」對於使用者來講又是做什麼呢——更改員工資料；「刪除員工資訊」又是什麼呢——員工登出。
不論是「填寫新員工資料」、「更改員工資料」，還是「員工登出」，對於客戶都是日常工作中需要完成的操作，將用例命名為這些名字必然為使用者所理解。同時，每乙個用例對於使用者來說應當是有價值的，也就是說，使用者使用這個功能是要完成一項操作，或獲得什麼資訊。比如上圖的「自動考核」會產生一批考核結果，執行「預警監控單項查詢」可以獲得預警監控結果資料。
2. 圖形繪製雜亂無章。乙個系統，特別是乙個大型系統，提供給使用者的功能是繁雜的。
如果你想將所有的功能，不管粗的細的，都試圖繪製在乙個用例圖中，幾乎沒人看得懂。我們之所以將分析設計圖形化，是因為圖形能給人形象立體的感官，使人立即就明白了其中的意思，但前提是，這個圖形是主題清晰的、形象生動的。因此，我們繪製用例圖要學會拆分，由粗到細地乙個乙個繪製。
先整體的繪製，再劃分成各個模組乙個乙個詳細繪製，再進一步細化。所以，描述乙個系統應當有許許多多的用例圖。
3. 用例是乙個場景。在現實世界中，我們常常面對的是乙個個長而複雜的操作流程，但在軟體世界裡，我們要將它們拆分成乙個個的用例，怎樣拆分？
乙個用例必須有乙個場景，也就是時間相近、地點單一的一系列操作，並且這些操作最終應當有乙個明確的結果。
如上所示這個用例圖，「申辯申請」就是過錯責任人填寫了一張申辯申請單，最終的結果是將申辯申請單提交給考核管理員；「申辯受理」就是考核管理員接收了過錯責任人的申辯申請單並予以受理，當然另乙個結果是對其不予受理，該申請單被退回給過錯責任人。每個用例都有確定的場景，明確的目的和結果。
功能角色分析是對系統巨集觀的、整體的需求分析，它用簡短的圖形繪製出了乙個系統的整體輪廓。但僅僅進行功能角色分析是遠遠不夠的，我們還需要在它的基礎上做更加詳盡的分析。
如何做需求分析 需求分析是什麼
1 無針對性的使用者訪談一般來說，tob的產品，特定的使用者是主要需求的提出者，而產品設計是為特定使用者服務，在這種情況下，我們有機會與特定使用者進行深度的溝通。但是，即使是明確了需求的提出者，在收集需求的過程中，還是有可能遇到很多 坑 2 頭腦風暴頭腦風暴是比較常見的需求收集方式，對於頭腦風暴的流...
做需求分析，包括資料流圖，功能分析等跪求大神，急求
資料流程圖的基本成分 系統部件包括系統的外部實體 處理過程資料儲存和系統中的資料流四個組成部分如下圖所示 1,外部實體 外部實體指系統以外又和系統有聯絡的人或事物，它說明了資料的外部 和去處，屬於系統的外部和系統的介面。外部實體支援系統資料輸入的實體稱為源點，支援系統資料輸出的實體稱為終點。通常外部...
說說面對不同的文化我們應當如何做
首先大的態度就是求同存異，當我們去面對好不同的文化肯定是需要學會去溝通交流才是最好的，還有一點就是需要去保持自己的文化特色，不能忘記自己的文化非常重要 查詢一些文化習俗 風俗習慣 說說我們應該怎樣對待這些文化 傳統文化被我們看作國寶。我們對待它的態度是很好的，但我們不應把它看作必須的 一定要保留的 ...