1樓：匡瑩莉
另外，業務流程分析
的另一個重要的分析內容就是流程差異化分析。不同的領導有不同的思路，不同的單位有不同的情況。因此，我們在進行流程分析的時候，常常面臨流程差異化的問題。
我們說企業資訊化就是一次改革，這首先體現在業務流程的規範化操作，也就是消除這種流程差異。但不同的單位有不同的情況，這特別體現在不同地域和文化的不同，又常常造成這種流程差異不可避免。分與合，分治與一統，常常是一個都要兼顧的問題，非常微妙，我們要小心處理。
在這個問題上你也許會問，使用工作流引擎就可以了嘛。工作流引擎不是萬能的，它只能解決一部分問題，更多的問題還需要我們的分析人員去分析與處理。
最後，企業資訊化就是一次改革，這特別集中地體現在了業務流程分析這一部分。當我們詳細分析了客戶現有的業務流程以後，應當進一步思考這樣的流程是否合理，是否值得改進。資訊化對於企業流程管理的衝擊是巨大的，最典型的例項就是erp。
erp的前身是mrp（material requirement planning 物料需求計劃）。起初，企業也就是希望有一套軟體系統來管理它們的倉庫。後來，企業領導希望他們在進貨的時候能有一定的採購計劃，避免出現倉庫中的物資擠壓，mrp就出現了。
然後呢，企業開始思考整個生產製造的鏈條管理，mrpii的概念出現了。再然後呢，物料需求的動因是生產的需求，生產需求的動因是銷售的需求。企業要真正做到零庫存，就必須切切實實地把從銷售到採購的每一個環節都管理好，erp的概念就出現了。
一個典型的資訊化流程改進的例子。
erp對企業流程改進的思路是巨集大的，但我們在分析每一個系統的時候不可能有如此巨集大的雄心與抱負。一般來說，我們可以用以下思路來進行我們對流程改進的分析：清除低效環節、簡化業務瓶頸、整合可用資源，以及將繁瑣任務自動化。
清除低效環節，就是清除那些耗費成本高而收效又低的環節，最典型的就是過量的庫存。過量的庫存原因很多，有可能是供銷環節沒有處理好而造成的過量採購，或者生產過剩，也可能是生產計劃沒有制訂好而產生活動間的等待。除此之外，還有重複的活動，等等。
簡化業務瓶頸，就是分析業務流程中影響整體程序的瓶頸業務，並有效地簡化它。如很多業務審批流程中都有一個受理環節。大量業務都集中在一兩個人來集中受理，根本忙不過來，造成整個流程的效率下降。
解決的辦法有兩個：一個是採用資訊化的手段進行批量受理，加快處理效率；另一個是將受理環節的任務分散到更多崗位中，降低受理人員的工作量。
整合可用資源，就是更大範圍地整合各個部門、不同職能的人員與社會資源，更加協同地來完成任務，這也是計算機資訊化管理最拿手的方面。製造業的**鏈管理是最典型的例子，因為實在太經典了我就不累贅了。醫院系統也是一個不錯的例子：
完成了身體檢查，醫生就立即知道了檢查結果；醫生開完藥，收費處就知道收多少費，藥房就知道拿什麼藥。
最後是自動化繁重操作。在財務系統中開了銷售單，就直接開發票了，並且直接形成報稅資料；在網上報完稅就知道該繳多少錢，甚至不用去稅務局，直接上銀行繳，等等等等，不勝列舉。繁重操作自動化，正是資訊化系統價值的體現。
我們應當怎樣做需求分析我們應當怎樣做需求調研：初識我們應當怎樣做需求調研：拜訪我們應當怎樣做需求調研：
研討會我們應當怎樣做需求調研：需求研討我們應當怎樣做需求調研：迭代我們應當怎樣做需求調研：
需求捕獲（上）我們應當怎樣做需求調研：需求捕獲（下）我們應當怎樣做需求分析：功能角色分析與用例圖我們應當怎樣做需求分析：
業務流程分析（上）我們應當怎樣做需求分析：用例說明我們應當怎樣做需求分析：查詢報表分析我們應當怎樣做需求分析：
子用例與擴充套件用例我們應當怎樣做需求分析：行**和狀態圖我們應當怎樣做需求分析：業務領域分析我們應當怎樣做需求分析：
原文分析法我們應當怎樣做需求分析：領域驅動設計我們應當怎樣做需求分析：非功能需求我們應當怎樣做需求確認：
需求列表我們應當怎樣做需求確認：一個需求列表的例項我們應當怎樣做需求確認：快速原型法我們應當怎樣做需求確認：
需求規格說明書我們應當怎樣做需求確認：評審與簽字確認會（續）
我們應當怎樣做需求分析：用例說明求解答
2樓：2杭瓷
當我們進行業務流程分析時，只空對空而不落到紙面上是不可以的。過去，在程序導向的時代，我們繪製dfd圖、流程圖，以及編寫流程說明來描繪這一部分分析；而現在，在物件導向的時代，我們則是繪製行**、狀態圖，以及編寫用例說明來完成這部分工作。
毫不疑問，做用例分析首先是要繪製出用例圖（前面已經說過了）。圖形的最大優勢是能夠形象生動地描述我們的分析，但它最大的缺點是會遺失許多的細節資訊，因此我們必須要對它進行進一步的文字描述。
由於不同的人對用例的理解不同，格式也不盡相同，但一些基本的元素是一樣的。以上**是我採用的用例說明格式，其中用例名稱、用例描述、參與者、前置條件、事件流、後置條件是公認的、用例說明的基本元素。
用例標識：就是用例的編號，一般採用「專案編號-子系統編號-模組編號-序號」來編號。
用例名稱：沒啥可說的，就是用例圖中該用例的名稱。注意用例的命名規則：
用例名稱通常是一個動詞短語或短句，而不是一個名詞短語。它可以是一個動詞（如：自動考核），一個動賓短語（如：
提取存款），一個被動句（如：發票填報），或者一個主謂句（如：使用者提款，這個不推薦，因為主語就是參與者，顯得有些多餘）。
參與者：用例圖中該用例的參與者，通常是業務操作的觸發者和施與物件（如外部系統）。
前置條件：在觸發該用例相關操作前必須達到的條件。
事件流：這是用例說明中最重要的部分，它詳細描述了該用例可能出現的所有流程。
1. 基本流程：另一個名稱更能表達它的意義：
最佳流程（the best flow）。它描述的是該用例以最佳的、最正常的方式流轉，沒有出現任何異常，並且最終成功完成操作的流程。基本流程在編寫時，應當通過數字對流程中的每一步進行編號。
2. 擴充套件流程：或者叫「分支流程」，它描述的是基本流程在流轉過程中可能出現的所有分支。
擴充套件流程最大的特點就是，它應當是在基本流程的某一步驟發生的分支，因此它的編號規則是「基本流程號+序號」。基本流程號就是發生分支的那一個基本流程的編號。在同一個基本流程上發生多個分支時，它們的序號從1依次開始編號。
另一種情況是，某個擴充套件流程本身擁有多個步驟，這時應當在「基本流程號+自身序號」的基礎上再新增序號，如「2.1.1」。
擴充套件流程在描述時，應當首先描述進入這個分支的條件，即「如果××則××」、「當××時××」。
3. 異常流程：就是發生異常情況時的處理流程。
注意，用例說明是站在用例角度進行的說明，因此這裡並不是我們通常一樣的發生程式異常的處理流程，而是使用者在處理業務操作時發生的異常情況，如：如果顧客不能提供身份證，則616161616161
後置條件：又稱為「成功保證」，就是執行基本流程獲得成功以後所達到的狀態（條件）。後置條件往往體現的是執行該用例的最終目的。如：完成使用者檔案的填寫並提交。
非功能需求：簡稱為「urps+」，即可用性（usability）、可靠性（reliability）、效能（performance）、可支援性（supportability）以及其它（+）。這一部分的需求分析相當重要而又最容易被忽略，後面我們再詳細討論。
假設與約束：就是隱藏於業務功能中的各項規則與條件，如各種邏輯條件、計算公式、環境限制等等。
除此之外，我還往往在每一個用例說明的後面與該用例相關的需求列表，便於需求跟蹤。用例分析實質是需求人員的一份設計。既然是設計就可能出現偏差，最終偏離原始的需求（這種情況特別容易出現在日後的升級維護中）。
因此，將需求列表附在用例後面，便於日後的需求評審與確認。當每次需要升級時，則新增上新的需求，或對以往的需求進行更新。
我們應當怎樣做需求分析我們應當怎樣做需求調研：初識我們應當怎樣做需求調研：拜訪我們應當怎樣做需求調研：
研討會我們應當怎樣做需求調研：需求研討我們應當怎樣做需求調研：迭代我們應當怎樣做需求調研：
需求捕獲（上）我們應當怎樣做需求調研：需求捕獲（下）我們應當怎樣做需求分析：功能角色分析與用例圖我們應當怎樣做需求分析：
業務流程分析（上）我們應當怎樣做需求分析：業務流程分析（下）我們應當怎樣做需求分析：查詢報表分析我們應當怎樣做需求分析：
子用例與擴充套件用例我們應當怎樣做需求分析：行**和狀態圖我們應當怎樣做需求分析：業務領域分析我們應當怎樣做需求分析：
原文分析法我們應當怎樣做需求分析：領域驅動設計我們應當怎樣做需求分析：非功能需求我們應當怎樣做需求確認：
需求列表我們應當怎樣做需求確認：一個需求列表的例項我們應當怎樣做需求確認：快速原型法我們應當怎樣做需求確認：
需求規格說明書我們應當怎樣做需求確認：評審與簽字確認會（續）
我們應當怎樣做需求分析：查詢報表分析求答案
3樓：手機使用者
在我以往的用例分析中，使用這樣格式的用例模式，對於大多數業務操作流程來說是得心應手的，但對於有些功能來說總感覺不對勁。感覺不對勁的，就是那些查詢、彙總與報表功能。對於這部分功能，需要我們描述的不是什麼操作流程，而更重要的是那些資料項、資料**、報**式、資料連結，以及使用者、使用頻率的說明。
而這些，在以往的用例說明格式中統統都沒有，怎麼辦呢？俗話說「東西是死的人是活的」，把我們的用例格式改改吧。
報表內容：用簡短的話描述一下。
輸出列：羅列報表的輸出列，如果需要的話，還應對輸出列進行說明，或描述它的資料**。
使用頻率：參與者使用它的頻率，便於設計者考慮報表的查詢效率。
最後依然是那個需求列表，便於業務需求的跟蹤。
查詢報表的需求分析與一般的業務操作的需求分析存在著巨大的差異。而許多需求分析人員沒有認識到這一點，這往往導致對查詢報表的分析不到位，為專案的研發帶來風險，因此在這裡我們認真**一下。
一個有效的報表，往往不是對數字的簡單堆砌，它通過一組一組的資料，揭示的都是一些客觀規律、複雜活動與發展趨勢。客戶方的領導，特別是那些中層和高層領導，通過對這些報表的閱讀，就可以掌握他們的工作程序、加強他們的人員管理、發現他們的管理漏洞、指導他們的戰略決策。總之一句話，每個報表都有他們的設計意圖。
比如說，一份工作月報，領導希望看到的，是按時間、按專案、按部門統計的各項工作的進展情況，以及有哪些異常情況，以便領導監控各項工作能夠順利完成；一份銷售報表，領導希望看到的，是按產品、按區域、按顧客型別統計的各項產品的銷售情況，以便領導制訂銷售計劃與各種營銷戰略。沒有弄清楚一個報表的真實意圖，就不算真正理解了這個報表的業務需求。
同時，報表的資料項應當都是**與系統中各項操作的結果資料。許多業務系統的操作流程都是紛繁複雜的，其中還包括各種情況。更復雜的，一些商業智慧與分析決策系統，報表所需的各種資料，甚至**與各種各樣的外部系統。
分析一個報表的資料**，就是在梳理各種業務流、資料流，以及各種資料間的關係。如果這方面的分析不到位，最終設計出來的報表往往是不準確的。
另外，使用者使用報表的頻率，常常決定了報表設計的方式。如果報表中的資料總是在實時變化，並且使用者總是在密切關注這些資料的變化，那麼報表必須設計成實時查詢的；如果使用者並不是十分關注資料的實時變化，並且總是以天（或者月，或者年）來檢視報表，則報表可以設計成按天（或者月，或者年）來預運算統計數字，使得報表查詢效率顯著提高，可以保證更多的併發訪問。
最後，一個報表的核心就是展現給客戶的報**式，以及報表與報表間的各種連結。需求人員在進行需求分析階段，應當準確地與客戶敲定這些格式，並最終在用例說明中體現出來。報**式是否體現客戶的意圖，報表資料項是否都能在系統中取到，資料間的邏輯關係是否正確，報**式是否技術可行，都是需求分析人員在前期就必須要分析到位的內容。
否則，報表是專案後期可能出現頻繁需求變更的重災區。
所有這些分析，都體現在了我提供給大家的用例說明格式中。報表作用體現的是報表對於不同使用者的真實意圖；輸出列體現的是對各個資料項及其資料**的說明；假設與約束羅列的是報表中各個資料項的運算公式、資料規則與約束；還有使用頻率、資料連結、非功能需求，以及最後的介面原型，等等。只要我們把這些都分析到了，我們的查詢報表就分析到位了。
我們應當怎樣做需求分析我們應當怎樣做需求調研：初識我們應當怎樣做需求調研：拜訪我們應當怎樣做需求調研：
研討會我們應當怎樣做需求調研：需求研討我們應當怎樣做需求調研：迭代我們應當怎樣做需求調研：
需求捕獲（上）我們應當怎樣做需求調研：需求捕獲（下）我們應當怎樣做需求分析：功能角色分析與用例圖我們應當怎樣做需求分析：
業務流程分析（上）我們應當怎樣做需求分析：業務流程分析（下）我們應當怎樣做需求分析：用例說明我們應當怎樣做需求分析：
子用例與擴充套件用例我們應當怎樣做需求分析：行**和狀態圖我們應當怎樣做需求分析：業務領域分析我們應當怎樣做需求分析：
原文分析法我們應當怎樣做需求分析：領域驅動設計我們應當怎樣做需求分析：非功能需求我們應當怎樣做需求確認：
需求列表我們應當怎樣做需求確認：一個需求列表的例項我們應當怎樣做需求確認：快速原型法我們應當怎樣做需求確認：
需求規格說明書我們應當怎樣做需求確認：評審與簽字確認會（續）
說說面對不同的文化我們應當如何做
當我們的文化發生碰撞的時候肯定是會有一些適應期，但是對我們來說還是需要學會去好好的求同存異吧，因為文化是需要交流溝通的，這樣才可以慢慢的變得比較開心起來 說說對世界各國不同文化禮儀該持怎樣態度？文化具有多樣性的特徵，我們應該在認同本民族文化的同時尊重其他民族的文化，堅持各民族文化一律平等的原則。各國...
在日常生活中，我們應當怎樣關愛自己
多看書，提高修養，是最好的關愛方式。不要和陌生人說話 不要為了面子做力不能及的事情 不要做無意義的整容 除了老婆或老公以外把情人或小蜜的數量嚴格控制在僅1個的範圍之內 凡事不要患得患失 不和男人比酒量不和女人比著裝。這樣應該夠了。關愛自己？我們不是有多關愛他人這個說法麼？額，關愛自己的話，就要注意自...
如何分析社會重大問題和發展需求，怎樣使自己適應社會需求
大學生就業問題一直都是全國性的市場經濟條件下的一個突出的經濟問題，是政治經濟學理論研究的難點，在世界上的許多國家和地區，都在一定程度上受到就業不足的困擾。在我國，隨著知識經濟發展引起的經濟結構調整的和改革的深化，大學生就業問題已成為經濟發展中的特點問題和經濟理論研究中的難點問題，在這樣的背景下，深化...