『壹』 闡述業務建模流程2，從業務模型到系統模型需要做哪些工作
業務建模（Business Modeling）是以軟體模型方式描述企業管理和業務所涉及的對象和要素、以及它們的屬性、行為和彼此關系，業務建模強調以體系的方式來理解、設計和構架企業信息系統。
根據環境和需求的不同，業務建模工作可能有不同的規模。以下列出了六種這樣的場景。
場景 #1 - 組織圖
您可能需要構建組織及其流程的簡圖，以便更好地了解對正在構建的應用程序的需求。在這種情況下，業務建模就成了軟體工程項目中的一部分，它主要是在先啟階段執行的。通常，這些工作在開始時僅僅是畫出組織圖，其目的並不是對組織進行變更。但實際上，構建和部署新的應用程序時往往會進行一定程度的業務改進。
場景 #2 - 領域建模
如果您構建應用程序時的主要目的是管理和提供信息（例如，訂單管理系統或銀行系統），那麼您可能選擇在業務級別上構建該信息的模型，而不考慮該業務的工作流程。這就稱為領域建模。請參見工作流程明細：開發領域模型。通常，領域建模是軟體工程項目的一部分，它是在項目的先啟階段和精化階段中執行的。
場景 #3 - 單業務多系統
如果您正在構建一個大的系統（即一系列的應用程序），那麼一個業務建模工作可能成為數個軟體工程項目的輸入。業務模型幫助您找出功能性需求，並且也作為構建應用程序系列構架的輸入。詳情請參見概念：從業務模型到系統。在這種情況下，通常將業務建模工作本身當做一個項目。
場景 #4 - 通用業務模型
如果您正在構建一個供多個組織使用的應用程序（例如，銷售支持應用程序或結賬應用程序）。一種有效的做法是：從頭到尾進行一次業務建模工作，從而按這些組織的經營方式對它們進行調整，避免一些對於系統來說過於復雜的需求（業務改進）。但如果無法對組織進行調整，那麼業務建模工作能夠幫助您了解並管理這些組織使用該應用程序時存在的差別，並使您更容易確定應用程序功能的優先順序。
場景 #5 - 新業務
如果某個組織決定要啟動一項全新的業務（業務創建），並將構建信息系統來支持該業務，那麼就需要進行業務建模工作。在這種情況下，業務建模的目的就不僅僅是要找出對系統的需求，而且還要確定新業務是否可行。在這種情況下，通常將業務建模工作本身當做一個項目。
場景 #6 - 修改
如果某個組織決定要對其經營方式進行徹底修改（業務重建），那麼業務建模通常本身就是一個或多個項目。通常，業務重建分數個階段完成：新業務展望、對現有業務實施逆向工程、對新業務實施正向工程以及啟動新業務。
『貳』 簡歷上的項目描述（JAVA）怎麼寫
想要成為合格的Java程序員或工程師到底需要具備哪些專業技能，面試者在面試之前到底需要准備哪些東西呢？本文陳列的這些內容既可以作為個人簡歷中的內容，也可以作為面試的時候跟面試官聊的東西，你可以把這些內容寫到你的簡歷中，當然更需要的是你在面試的時候向面試官展示這些專業技能。相信此文對正在尋覓Java程序員（Java工程師）職位的freshman以及希望成為中高級Java開發者的junior都會有所幫助。
專業技能
1.熟練的使用Java語言進行面向對象程序設計，有良好的編程習慣，熟悉常用的JavaAPI，包括集合框架、多線程（並發編程）、I/O（NIO）、Socket、JDBC、XML、反射等。
2.熟悉基於JSP和Servlet的JavaWeb開發，對Servlet和JSP的工作原理和生命周期有深入了解，熟練的使用JSTL和EL編寫無腳本動態頁面，有使用監聽器、過濾器等Web組件以及MVC架構模式進行JavaWeb項目開發的經驗。
3.對Spring的IoC容器和AOP原理有深入了解，熟練的運用Spring框架管理各種Web組件及其依賴關系，熟練的使用Spring進行事務、日誌、安全性等的管理，有使用SpringMVC作為表示層技術以及使用Spring提供的持久化支持進行Web項目開發的經驗，熟悉Spring對其他框架的整合。
4.熟練的使用Hibernate、MyBatis等ORM框架，熟悉Hibernate和MyBatis的核心API，對Hibernate的關聯映射、繼承映射、組件映射、緩存機制、事務管理以及性能調優等有深入的理解。
5.熟練的使用HTML、CSS和JavaScript進行Web前端開發，熟悉jQuery和Bootstrap，對Ajax技術在Web項目中的應用有深入理解，有使用前端MVC框架（AngularJS）和JavaScript模板引擎（HandleBars）進行項目開發的經驗。
6.熟悉常用的關系型資料庫產品（MySQL、Oracle），熟練的使用SQL和PL/SQL進行資料庫編程。
7.熟悉面向對象的設計原則，對GoF設計模式和企業應用架構模式有深入的了解和實際開發的相關經驗，熟練的使用UML進行面向對象的分析和設計，有TDD（測試驅動開發）和DDD（領域驅動設計）的經驗。
8.熟悉Apache、NginX、Tomcat、WildFly、Weblogic等Web伺服器和應用伺服器的使用，熟悉多種伺服器整合、集群和負載均衡的配置。
9.熟練的使用產品原型工具Axure，熟練的使用設計建模工具PowerDesigner和EnterpriseArchitect，熟練的使用Java開發環境Eclipse和IntelliJ，熟練的使用前端開發環境WebStorm，熟練的使用軟體版本控制工具SVN和Git，熟練的使用項目構建和管理工具Maven和Gradle。
說明：上面羅列的這些東西並不是每一項你都要爛熟於心，根據企業招聘的具體要求可以做相應的有針對性的准備。我個人覺得前6項應該是最低要求，是作為一個Java開發者必須要具備的專業技能
項目介紹
本系統是X委託Y開發的用於Z的系統，系統包括A、B、C、D等模塊。系統使用了Java企業級開發的開源框架E以及前端技術F。表示層運用了G架構，使用H作為視圖I作為控制器並實現了REST風格的請求；業務邏輯層運用了J模式，並通過K實現事務、日誌和安全性等功能，通過L實現緩存服務；持久層使用了M封裝CRUD操作，底層使用N實現數據存取。整個項目採用了P開發模型。
說明：上面的描述中，E通常指Spring（Java企業級開發的一站式選擇）；F最有可能是jQuery庫及其插件或者是Bootstrap框架，當然如果要構建單頁應用（SPA）最佳的方案是前端MVC框架（如AngularJS）和JavaScript模板引擎（如HandleBars）；G顯然是MVC（模型-視圖-控制），最有可能的實現框架是SpringMVC，除此之外還有Struts2、JSF以及Apache為JSF提供的MyFaces實現，可以使用JSP作為MVC中的V，也可使用模板引擎（如Freemarker和Velocity）來生成視圖，還可以是各種文檔或報表（如Excel和PDF等），而Servlet和自定義的控制器是MVC中的C，當然SpringMVC中提供了作為前端控制器的DispatcherServlet；J通常是事務腳本，K應該是AOP（面向切面編程）技術，L目前廣泛使用的有memcached和Redis；M的選擇方案很多，最有可能的是Hibernate和MyBatis，也可以兩種技術同時運用，但通常是將增刪改交給Hibernate來處理，而復雜的查詢則由MyBatis完成，此外TopLink、jOOQ也是優秀的持久層解決方案；底層的數據存取傳統上是使用關系型資料庫，可以是MySQL、Oracle、SQLServer、DB2等，隨著大數據時代的來臨，也可以採用NoSQL（如MongoDB、MemBase、BigTable等）和其他大數據存取方案（如GFS、HDFS等）；項目的開發模型P可以是瀑布模型、快速原型模型、增量模型、螺旋模型、噴泉模型、RAD模型等。
項目開發流程
1.可行性分析>>>可行性分析報告/項目開發計劃書
2.需求分析>>>需求規格說明書
1.OOAD（用例圖、時序圖、活動圖）
2.界面原型：幫助理解需求、業務層設計時推導事務腳本
3.設計>>>概要設計說明書/詳細設計說明書
1.抽取業務實體（領域對象）：類圖、E-R圖（概念設計階段）
2.分層架構：確定各層的技術實現方案（具體到使用的框架、資料庫伺服器、應用伺服器等）。業務層設計：事務腳本模式（事務：用戶發送一次請求就是一個事務；腳本：一個方法或一個函數；事務腳本：把一次請求封裝為一個方法或一個函數；事務腳本模式：一個事務開始於腳本的打開，終止於腳本的關閉）。業務層涉及的對象本有三種類型：事務腳本類（封裝了業務的流程）、數據訪問對象（DAO，封裝了持久化操作）、數據傳輸對象（DTO，封裝了失血/貧血領域對象），三者之間的關系是事務腳本類組合（聚合）數據訪問對象，這二者都依賴了數據傳輸對象
3.正向工程（UML類圖生成Java代碼）和逆向工程（Java代碼生成UML類圖）
4.資料庫物理設計（ER圖轉換成表間關系圖、建庫和建表、使用工具插入測試數據）
4.編碼5.測試>>>測試報告/缺陷報告
1.單元測試：對軟體中的最小可測試單元進行檢查和驗證，在Java中是對類中的方法進行測試，可以使用JUnit工具來實施。
2.集成測試：集成測試也叫組裝測試或聯合測試。在單元測試的基礎上，將所有模塊按照設計要求組裝成為子系統進行測試。
3.系統測試：將已經確認的軟體、硬體、外設、網路等元素結合在一起，進行信息系統的各種組裝測試和確認測試，系統測試是針對整個產品系統進行的測試，目的是驗證系統是否滿足了需求規格的定義，找出與需求規格不符或與之矛盾的地方，從而提出更加完善的方案。
4.驗收測試：在軟體產品完成了單元測試、集成測試和系統測試之後，產品發布之前所進行的軟體測試活動。它是技術測試的最後一個階段，也稱為交付測試。驗收測試的目的是確保軟體准備就緒，並且可以讓最終用戶將其用於執行軟體的既定功能和任務。
5.交付和維護>>>用戶手冊/操作手冊
項目管理
版本控制：CVS/SVN/Git
自動構建：Ant/Maven/Ivy/Gradle
持續集成：Hudson/Jenkins
系統架構
負載均衡伺服器：F5、A10
應用伺服器：
HTTP伺服器：Apache、NginX（HTTP、反向代理、郵件代理伺服器）
Servlet容器：Tomcat、Resin
EJB容器：WildFly（JBossApplicationServer）、GlassFish、Weblogic、Websphere資料庫伺服器：MySQL、Oracle
第三方工具（插件）應用
圖表工具：基於jQuery的圖表插件（如jQchart、Flot、Charted等）、Chart.js、Highcharts等。
報表工具：PentahoReporting、iReport、DynamicReports等。
文檔處理：POI、iText等。
工作流引擎：jBPM、OpenWFE、Snaker、SWAMP等。
作業調度：Quartz、JobServer、Oddjob等。
緩存服務：EhCache、memcached、SwarmCache等。
消息隊列：Open-MQ、ZeroMQ等。
安全框架：Shiro、PicketBox等。
搜索引擎：IndexTank、Lucene、ElasticSearch等。
Ajax框架：jQuery、ExtJS、DWR等。
UI插件：EasyUI、MiniUI等。
富文本框：UEditor、CKEditor等。
面試提問
項目是為哪個公司開發的？
項目的投入是多少？
有多少人參與了項目開發？
整個團隊中，測試人員、開發人員、項目經理比例是多少？
項目開發了多長時間？
項目總的代碼量有多少？
你的代碼量有多少？
項目採用了怎樣的開發模型或開發流程？
項目的架構是怎樣的？
項目的技術選型是怎樣的？
你在項目中承擔了怎樣的職責？
是否經常開會或加班？
項目完成後有哪些收獲或是經驗教訓？
項目中最困難的部分是什麼？
如何解決團隊開發時遇到的各種沖突？
明：對於沒有實際項目經驗的，可以在前程無憂、智聯招聘、拉勾網等網站上搜索招聘Java程序員的公司，找到他們的官方網站了解他們做的項目，查看項目的詳細介紹，然後嘗試完成其中一部分功能，最好請教一下高人看看自己的設計和代碼是否恰當，這樣相當於積累了一定的項目經驗。
面試時可以反問面試官的問題
我注意到你們使用了X技術，請問你們是如何解決Y問題的？
為什麼你們的產品使用了X技術而不是Y技術？據我所知，X技術雖然有A、B、C等好處，但也存在D和E問題，而Y技術可以解決D和E問題。
我對您說的X技術不是太熟悉，但我感覺它是一個不錯的解決方案，您能多講講它的工作原理嗎？
你們團隊是如何進行項目規劃的？一周會有幾次例會？每周的代碼量大概是多少？
就X問題我能想到的解決方案目前就只有Y了，請問您會怎麼解決這個問題？
錄用談判
要理直氣壯的提出具體的待遇要求
開出比預期稍高的價碼
不要只盯著薪水（很多公司更願意就薪水之外的條件做出讓步）
使用最合適的方法（可以嘗試在電話或E-mail中談判待遇）
自我評價
學習能力（搞IT行業的人需要不斷的了解新的技術、工具和方法）
團隊意識（相比個人英雄主義，IT行業更倡導團隊合作）
抗壓能力（很多IT企業的工作強度相對來說還是比較大的）
自學編程，免費獲取精品IT教程以及資料，搜索：黑馬程序員
網頁鏈接
『叄』 銀行計算機儲蓄系統的流程圖
我有銀行的金融信息系統資料，但不同銀行有所不同，如需要可聯系我 [email protected]
『肆』 關於"銀行儲蓄管理系統"的軟體設計,請高手幫幫忙吧
【設計題目】：儲戶的存款單或取款單由業務員輸入系統，密碼由儲戶輸入。如果是存款，系統記錄帳號，存款人姓名，地址，存款類型，存款日期，利息等信息；如果是取款，計算利息，並列印利息清單給儲戶。
【設計目的】：通過對銀行儲蓄管理系統的分析，進一步理解和掌握面向對象方法論，尤其是面向對象的三個模型：對象模型、動態模型、功能模型。
【設計條件、軟體工具】：專業的資料庫管理系統，採用面向對象的方法。
【設計思想、演算法】：用面向對象方法分析上述系統，建立它的對象模型、動態模型、功能模型。
【設計過程，操作步驟說明】：
（一）建立對象模型
1. 確定類—&—對象
經分析本系統問題域及功能需求，得出主要的類—&—對象：總行、分行、營業廳（儲蓄所）終端、儲戶、帳戶、業務員、事務。
2. 確定關聯
（1） 總行由若干個分行組成；分行擁有一個營業廳、若干個儲蓄所；
（2） 分行僱用業務員；
（3） 儲戶擁有一個或多個帳戶；
（4） 分行處理針對帳戶的事務；分行維護帳戶；
（5） 業務員輸入針對帳戶的事務；
（6） 終端與用戶交互；
（7） 終端列印帳單；
3. 對象模型
（二）建立動態模型
1. 正常情況腳本（取款）
業務員將儲戶所填寫資料輸入儲蓄所終端；
終端要求儲戶輸入密碼；儲戶輸入對應帳號的正確密碼；
終端要求總行驗證密碼；總行要求分行核對儲戶密碼，然後通知終端密碼正確；
終端確認取款額在預先規定的限額內，然後要求決行處理這個事務；
總行把請求轉給分行；分行成功地處理完這項事務並返回該帳戶的新余額；
終端列印存摺和帳單；
業務員與儲戶交接現金、存摺和帳單。
異常情況腳本（取款）
業務員將儲戶所填寫資料輸入儲蓄所終端；
終端要求儲戶輸入密碼；儲戶不小心輸入錯誤密碼；
終端要求總行驗證密碼；總行在向有關分行咨詢後通知終端密碼有錯；
終端顯示「密碼錯」，並請儲戶重新輸入密碼；終端請總行驗證後知這次輸入的密碼正確；
儲戶改變主意不想取款了，業務員敲「取消」鍵；
業務員把存摺、取款單退回給儲戶。
正常情況腳本的事件跟蹤圖
儲戶終端總行分行
業務員輸入儲戶填寫資料
要求密碼
輸入密碼
請求驗證密碼
請求分行驗證密碼
密碼正確
業務員交接現金存摺帳單
儲戶取走現金存摺帳單
結束
（三）建立功能模型
1. 基本系統模型
2. 功能級數據流圖
【設計心得體會】：通過本實驗，使我更清晰地理解了面向對象方法論的分析和設計過程，對三種模型之間的關系更加清楚。通過對系統的對象模型的分析，理解到對象模型確實是三種模型中最重要、最關鍵的，只有對對象模型進行了較透徹的分析，才能清楚地得出其它兩個模型。
『伍』 求銀行儲蓄系統詳細設計
銀行儲蓄系統詳細設計
一、模塊設計
系統總體結構方圖：
銀行儲蓄系統又大致分為兩個模塊：存款模塊和取款模塊。
1.身份驗證模塊：
設置身份驗證模塊的目的保證儲戶信息的安全。功能在於對申請登錄的用戶進行身份驗證，通過者才能進入系統。
銀行業務員輸入儲戶用戶ID，儲戶輸入密碼並確定，系統保存用戶輸入的用戶ID和密碼，並在customer表中查找customerid和customername欄位值，看是否等於業務員輸入的用戶ID和密碼，如相同則通過驗證，否則不通過，並給出「密碼錯誤」的提示，如資料庫中不存在這樣的記錄，則給出「該用戶不存在」的提示。
2.存款模塊：
設置存款模塊的目的在於將儲戶的金額存到系統中並記錄信息。存款模塊將儲戶存款金額錄入存儲到系統中，並附帶顯示其他儲戶信息。
該模塊的輸出項為存款金額，並且附帶顯示其他信息：用戶名、賬號、賬戶余額、利息金額。當銀行業務員輸入存款金額後，系統進行處理，顯示出賬戶余額，並且顯示其他固定信息。
3.取款模塊：
設置取款模塊的目的在於將儲戶的取款金額錄入並存儲到系統中。取款模塊將儲戶取款金額錄入存儲到系統中，並附帶顯示儲戶其他信息。該模塊的輸出項為取款金額，並且附帶顯示其他信息：用戶名、賬號、賬戶余額、利息金額。當銀行業務員輸入取款金額後，點擊確定按鈕，系統進行處理，顯示出賬戶余額，並且顯示其他固定信息。
4.存款單列印模塊:
設置存款單列印模塊的目的在於將儲戶的存款信息以單據的形式及時反饋給儲戶。存款單列印模塊將儲戶存款金額以及儲戶帳戶信息以單據形式反饋給儲戶。該模塊的輸出項為存款人、存款銀行、業務員編號、存款金額、存款日期、手續費、帳戶余額。當銀行業務員輸入存款金額後，系統進行處理，顯示出賬戶余額，並且顯示其他固定信息。
5.取款單列印模塊：
設置取款單列印模塊的目的在於將儲戶的取款信息以單據的形式及時反饋給儲戶。取款單列印模塊將儲戶取款金額以及儲戶帳戶信息以單據形式反饋給儲戶。該模塊的輸出項為取款人、取款銀行、業務員編號、取款金額、取款日期、手續費、帳戶余額。當銀行業務員輸入取款金額後，系統進行處理，顯示出賬戶余額，並且顯示其他固定信息。
6.按用戶名和ID查詢模塊
設置「按用戶名和ID查詢」模塊的目的在於方便用戶獲知自己的存取款信息。功能在於通過儲戶輸入用戶名和ID來查詢自己的信息。
該模塊的輸出項為儲戶各項信息。輸入用戶名和ID，單擊檢索按鈕，系統判斷用戶名和ID是否與資料庫中的customername , customerid相同，若相同則輸出儲戶各項信息，若不同則輸出「輸入有誤！請重新輸入！」的提示信息。
二、數據設計
1.用戶驗證模塊流程圖：
該模塊的輸入項：
名稱 標識 數據類型 數據值 輸入方式
用戶ID customerid 字元 鍵盤輸入
密碼 password 字元或數字 鍵盤輸入
2.存款模塊流程圖：
該模塊的輸入項：
名稱 標識 數據類型 數據值 輸入方式
存款金額 cunkuancount 數字（ Double ） >0 鍵盤或滑鼠
3.取款模塊的流程圖：
該模塊的輸入項：
名稱 標識 數據類型 數據值 輸入方式
取款金額 qukuancount 數字（ Double ） >0 鍵盤或滑鼠
三、、對話設計
在對話設計的過程中遵循了對話設計的原則：
1．對話要清楚、沒有二義性。
2．對用戶的響應要快，而且要進行了回答的有效性檢驗。
3．對話比較適合用戶的要求與習慣，應該問的問題問了，問得不頻繁。
4．注意詢問格式的美觀、實用，而且採用了統一的格式，體現了一定的風格。
四、可靠性設計
這里所說的可靠性是指數據的安全與保密。所謂系統的可靠性設計就是確定保證數據的安全與保密措施。
就保密措施採取了二重確認的方法。通過加強應用程序的容錯性，設置了用戶的許可權，系統中信息資源的存取、修改、查詢等使用許可權進行了控制。對於用戶管理員的頂級許可權在程序運行的過程中進行了控制工作。
『陸』 關於銀行系統---儲蓄業務子系統的需求分析的一些問題（高分
我覺得你可以再詳細一些：
1 儲蓄開戶； 開戶的時候要憑的證件要點名一下，未蠻16周歲的開始需要什麼東西。
2 儲蓄續存的話可以看成一種預約存款多數指定期到期後沒有支取，但是開通約存後可自動幫自己存利滾利的那種，是儲蓄存款中的一部分，是能是儲蓄存款而不能是儲蓄續存 儲蓄存款分活期 /定期利息 整存整取 零存整取 存本取息 整存取息
儲蓄支取分到期日後支取或者提前支取；外地支取要手續費，定期提前支取是活期 定期到期後支取到期日按約定之後的安活期這個時候可以用約存，如果有人在到期日後的半年來取款，那就是說這個半年的存款是後期讓費了，所以在辦理定期存款後再辦一個約存的業務可以不必擔心不劃算了。
儲蓄銷戶，可以分本人和死亡銷戶
帳戶查詢
掛失業務，口頭掛失和正式掛失
=========================個人感覺這樣分，開戶、存款、查詢、取款、改密、掛失、解除掛失、轉帳、銷戶。
二、各個銀行都是不一樣的，可以有登陸系統的，這個比較的繁瑣需要請專業人事調試。
三 轉帳等同於現金，現金從銀行的atm中取出來後是有每天是有限制2w的，轉帳就不同了，但是轉帳只能同行同行轉。或者你也可以用本票也行，可以和取款分開的因為性質是不一樣的。
================================================================
可能不是很全我是新手希望對你有利吧。
『柒』 業務模型，功能模型和數據模型三個模型建模思想有怎樣的優缺點
軟體建模中的三個模型是指業務模型、功能模型和數據模型。
功能模型是描述系統能做什麼什麼，即對系統的功能、性能、介面和界面進行定義。
業務模型是描述系統在何時、何地、由何角色、按什麼業務規則去做，以及做的步驟或流程，即對系統的操作流程進行定義((怎麼做 ))。
數據模型是描述系統工作前的數據來自何處，工作中的數據暫存什麼地方，工作後的數據放到何處；以及這些數據之間的關聯，即對系統的數據結構進行定義(數據怎麼組織 ) 。
三個模型建模思想的優點：簡單、直觀、通俗、易懂、易學、易用，非常適合於關系資料庫管理系統RDBMS RDBMS支持的信息系統。缺點還入門容易，但想搞懂成為高手就難了。
『捌』 應該從什麼樣的角度描述web系統的業務流程項目描述可以是系統業務流程嗎
1 構成企業管理信息系統的5個基本要素 對企業需求的描述可以從2個方面來進行描述，一個方面是對客戶現行系統的描述，一個方面是對系統未來的設想。總的而言，無論是從那個方面來描述，構成企業信息系統主要包括5個基本要素：企業的組織結構、流程、數據、商務規則與功能（性能）。其中從用戶的角度主要關注流程，是以流程為核心的，通過流程將其他幾個要素貫穿起來，需求分析人員也應該從這個角度來和用戶溝通；從開發者的角度主要關注企業的數據、商務規則與功能，以便於系統的實現；從實施者的角度主要關注企業的組織結構與功能，以便於系統的發布與實施。 1） 企業的組織模型 即企業的組織結構關系，包括部門設置、崗位設置、崗位職責等。樹型組織結構圖是描述企業的組織模型的一種常用方法，它可用來搞清各部門之間的領導關系,每個部門內部的人員配備情況, 職責分工等情況,它是劃分系統范圍,進行系統網路規劃的基礎。在組織結構圖中應將用戶的組織結構逐層詳細描述，每個部門的職責也應進行簡單的描述。組織結構是用戶企業業務流程與信息的載體，對分析人員理解企業的業務、確定系統范圍具有很好的幫助。取得用戶的組織結構圖，是需求獲取步驟中的基礎工作之一。 用戶環境中的企業崗位或角色，和組織機構一樣，也是分析人員理解企業業務的基礎，也是分析人員提取對象的基礎。 對用戶角色的識別常常遺漏的是計算機系統的系統管理人員，角色識別不全，對以後的功能識別會造成盲區。 （2） 企業的流程模型 即企業的業務流程，包含哪些流程、流程之間的關系、每個流程中包括哪些活動、每個活動涉及到的崗位。企業的作業流程首先要有一個總的業務流程圖，將企業中各種業務之間的關系描述出來，然後對每種業務進行詳細的描述，使業務流程與部門職責結合起來。詳細業務流程圖可以採用直式業務流程圖形式。對企業而言需要定義關於業務流程圖的描述標准，大家採用相同的圖例來描述，便於管理。 業務流程圖的優點 : ■繪圖的過程,實際上是作業流程條理化的過程 ■表達形象直觀,易於和用戶交流,易於項目組內部交流調研的結果,需要得到用戶的認同,這就需要和用戶交流調研的結果,交流的文檔要通俗、易懂, 不能採用專業術語。 ■可以作為培訓實施人員與技術服務人員的文檔 業務流程圖的缺點 : ■對高層管理人員的實際需求調查的不清楚. 這一方面是由於用戶沒有接觸過計算機, 對採用計算機後的管理會是什麼樣子?計算機能夠完成當前手工操作的哪些內容?能夠作哪些現在手工無法完成的工作等等沒有清楚的概念,因此用戶無法將這些問題反應出來. 另一方面說明分析人員沒有經驗,對原始材料挖掘不深,不能從用戶 提供的材料中提煉處來用戶的真正需求,不能找到當前管理中的問題。 ■對各種業務之間的總體關系沒有表達出來. 採用直式業務流程圖可以將企業的每一種業務的處理流程清楚地表達出來, 但是各業務之間的聯系卻沒有表示出來,單看一種業務的流程圖很清楚,但是卻不能綜合在一起,沒有整體的概念,作為需求分析的文檔,在這方面表達的不夠完整。 ■在不利用工具的情況下,畫法煩瑣。 圖形可以將流程描述的很清楚，但是還要附加以一些文字說明，如關於業務發生的頻率、意外事故的處理、高峰期的業務頻率等，不能在流程圖中描述出的內容，需要用文字進行詳細描述。 （3） 企業的數據模型 即企業中的信息載體有哪些？以及對這些信息載體的詳細刻畫，包括企業的各種單據、帳本、報表的描述。在需求報告中，應該將單據的描述格式化，需要描述的內容包括： 單據的用途，即單據用在什麼地方？ 單據的格式：需要明確的畫出來，並有實際的有數據的樣例，能夠具體直觀地說明問題； 單據中的數據項的具體描述：長度、類型、計算生成方法、約束條件等； 單據的數據項是由哪些不同類型的角色來填寫地，包括用計算機可以填那些數據項。 單據中哪些數據是必填的，哪些是可以不用填的。 單據流量：平均每天產生多少條記錄，高峰期的數量； 單據的分類：可以從多個角度上進行分類，如：按業務類型來分類（采購/銷售/生產），按生成的方式來分類（手工錄入型/自動生成型），按格式變化的頻繁程度來分類（易變型/穩定型），按表現形式來分類（列表型/卡片型）等等。 單據之間的關系：引用關系等等。 同樣對於需要的報表與帳本也可以參照上面的條目進行詳細的刻畫。