在進行系統分析時要注意的結合是

1. 在新系統開發之前必須先進行什麼分析

需求分析奠定了軟體工程和項目管理的基礎。我們在建造軟體系統這座大廈的時候，如果需求分析的基礎不夠堅實和牢固，那麼往往會導致軟體系統問題百出，甚至被馬上丟棄。在建造軟體系統的過程中，如果我們經常習慣地沿用一些不規范的方法，其後果便是產生一條鴻溝──開發者開發的與用戶所想得到的軟體存在著巨大的「期望差異」。 因此「需求」這個名詞的定義不僅僅是從用戶角度對系統外部行為的描述，以及從開發人員角度對系統內部特性的描述，其關鍵的一點是「需求」必須文檔化。

需求的類型
軟體需求包括三個不同的層次──業務需求、用戶需求和功能需求。 除此之外，每個系統還有各種非功能需求。
業務需求（BusinessRequirement）表示組織或客戶高層次的目標。業務需求通常來自項目投資人、購買產品的客戶、實際用戶的管理者、市場營銷部門或產品策劃部門。業務需求描述了組織為什麼要開發一個系統，即組織希望達到的目標。使用前景和范圍（vision and scope）文檔來記錄業務需求，這份文檔有時也被稱作項目輪廓圖或市場需求（project charter 或 market requirement）文檔。 用戶需求（UserRequirement）描述的是用戶的目標，或用戶要求系統必須能完成的任務。用例、場景描述和事件響應表都是表達用戶需求的有效途徑。也就是說用戶需求描述了用戶能使用系統來做些什麼。
功能需求（Functional Requirement）規定開發人員必須在產品中實現的軟體功能，用戶利用這些功能來完成任務，滿足業務需求。功能需求有時也被稱作行為需求（behavioral requirement），因為習慣上總是用「應該」對其進行描述：「系統應該發送電子郵件來通知用戶已接受其預定」。功能需求描述是開發人員需要實現什麼。
非功能需求（Non-functional Requirement） 定義了軟體產品為滿足用戶業務需求而必須具有的除功能需求以外的特性。包括系統的完整性（聯機幫助、 數據管理、用戶管理、軟體發布管理、在線升級等）、性能、可靠性、可維護性、可擴充性、對技術和業務的適應性等。
需求分析的任務
1 解決的問題
1) 齊全、准確地找出目標系統全部的功能、性能、限制； 2) 找出全部的輸入流、輸出流； 3) 找出所有的加工；
4) 產生完整的分層的DFD、數據字典、加工的描述； 5) 補充的意見。
2 綜合要求
確定對系統的綜合要求，系統功能要求，系統性能要求，運行要求，將來可能提出的要求。
3 任務
圖1為需求分析任務圖，需求分析階段要完成的具體明確的最終任務就是形成一份經開發方和用戶認可或達成共識的軟體需求分析文檔（需求規格說明書、修改後的項目開發計劃、初步的用戶手冊、確認測試計劃、數據要求說明書）。這個文檔能清晰准確地說明系統將要開發什麼，能夠規定出詳細的技術需求，包括所有面向用戶、面向機器和其它軟體系統的介面。可以說需求文檔在開發過程中一直起指導作用。
為了更好地完成軟體開發第一階段的需求分析任務，提高質量，需求管理是必不可少的。
需求管理的目的是在客戶與開發方之間建立對需求的共同理解，維護需求與其他工作成果的一致性，並控制需求的變更，主要體現在跟蹤和控制需求變更管理。需求管理是開發工作有效進行的保證，是一種很高層次的系統行為，涉及整個開發過程和產品本身。
需求分析的方法
需求分析方法由對軟體問題的信息域和功能域的系統分析過程及其表示方法組成，大多數的需求分析方法是由信息驅動的。信息域具有三種屬性： 信息流、信息內容和信息結構。
常用的需求分析方法有：面向數據流的結構化分析方法（SA），面向數據結構的Jackson方法（JSD），面向數據結構的結構化數據系統開發方法（DSSD），面向對象的分析方法（OOA）等。選擇那種方法要根據哪些資源在什麼時間對開發人員有效，不能盲目套用。這里著重闡述面向數據流的結構化分析方法（SA）。
面向數據流的結構化分析方法
面向數據流的結構化分析方法（Structured Analysis，簡稱SA），是面向數據流進行需求分析的方法，是需求分析使用最多的方法之一。 SA也是一種建模活動，該方法使用簡單易讀符號，根據軟體內部數據傳遞、變換的關系，自頂向下逐層分解，描繪出滿足功能要求的軟體模型。適用於數據處理類型軟體的需求分析，這一方法除了簡單，容易掌握之外，還能和設計階段的結構化設計（SD）銜接，從而取得良好的設計結果。
自頂向下逐層分解的分析策略
SA方法的基本手段：「分解」和「抽象」。這是系統開發技術中控制復雜性的兩種手段。它先將系統「抽象」成一個模型，此模型是有輸入和輸出並有系統名稱的盒子，然後打開這個盒子，對它進行逐層分解，直到能被理解，可以實現為止。因此分析的策略是自頂向下，逐層加細，由抽象到具體的過程。如圖2。
結構化分析方法使用工具
SA方法利用圖形等半形式化的描述方式表達需求，簡明易懂，用它們形成需求規格說明書中的主要部分。描述工具是
1) 數據流圖：描述系統由哪幾部分組成，各部分之間有什麼聯系等等。 2) 數據字典：定義了數據流圖中每一個圖形元素。
3) 描述加工邏輯的結構化語言、判定表、判定樹：詳細描述數據流圖中不能被再分解的每一個加工。
由於分析中的主要依據是數據傳遞及數據變換所形成的數據流，所以結構化分析一般採用的方法是使用數據流圖的分析方法，最終結果是產生需求規格說明書，該文檔包括一套數據流圖，對數據流圖中的成分進行定義的一本數據字典及對加工邏輯的描述。
結構化分析步驟
用結構化分析方法進行系統需求分析的具體步驟是： 1) 了解當前系統的工作流程，獲得當前系統的物理模型。通過對當前系統的詳細調查，了解當前系統的工作過程，同時收集資料、文件、數據、報表等，將看到的、聽到的、收集到的信息和情況用圖形描述出來。也就是用一個模型來反映自己對當前系統的理解，如畫系統流程圖。
2) 抽象出當前系統的邏輯模型。物理模型反映了系統「怎麼做」的具體實現，去掉物理模型中非本質的因素，抽取出本質的因素，構造出當前系統的邏輯模型，反映了當前系統「做什麼」的功能。
3) 建立目標系統的邏輯模型。分析、比較目標系統與當前系統邏輯上的差別，明確目標系統到底要「做什麼」，從而從當前系統的邏輯模型導出目標系統的邏輯模型。
4) 作進一步補充和優化。為了對目標系統做完整的描述，還需要對得到的邏輯模型做一些補充。
說明目標系統的人機界面。
說明至今尚未詳細考慮的細節（包括出錯處理、系統的啟動與結束、系統的輸入/輸出和系統性能方面的需求等）。
其他（系統特有的其他必須滿足的性能和限制，也需要用適當的形式做出書面記錄。 分析階段結束時，系統分析員必須和用戶再次認真地審查系統文件，爭取在系統開始設計之前，盡可能地發現其中存在的一些錯誤並及時糾正，直至用戶確認這個模型表達了他們的要求後，系統文件（軟體需求規格說明書等）才作為用戶和軟體開發人員之間的「合同」而最後得到確定。
結構化分析方法的優缺點
1) 優點： 結構化分析方法是軟體需求分析中公認的、有成效的、技術成熟的、使用廣泛的一種方法，它較適合於開發數據處理類型軟體的需求分析，該方法利用圖形等半形式化工具表達需求，簡明易讀，也易於使用，為後一階段的設計、測試、評價提供了有利條件。 2) 缺點：① 傳統的SA方法主要用於數據處理方面的問題，主要工具DFD體現了系統「做什麼」的功能，但它僅是一個靜態模型，沒有反映處理的順序，即控制流程。因此，不適合描述實時控制系統。② 上世紀60年代末出現的資料庫技術，使許多大型數據處理系統中的數據都組織成資料庫的形式，SA方法使用DFD在分析與描述「數據要求」方面是有局限的，DFD應與資料庫技術中的實體聯系圖(ER圖)結合起來(如同IDEF0功能模型與IDEF1信息模型相結合一樣)。ER圖能增加對數據存儲的細節以及數據與數據之間，數據與處理過程之間關系的理解，還解決了在DD中所包含的數據內容表示問題，這樣才能較完整的描述用戶對系統的需求。③ 對於一些頻繁的人機交互的軟體系統，如飛機訂票、銀行管理等系統，用戶最關系的是如何使用它，輸入命令、操作方式、系統響應方式、輸出格式等都是用戶需求的重要方面，DFD不適合描述人機界面系統的需求，SA方法往往對這一部分用自然語言作補充。④ 描述軟體需求的精確性有待提高。 5 需求的變更
在開發項目過程中，用戶隨時會提出一些新的需求，要求開發方解決，這些需求的提出，有時在開發階段中有時在開發階段後。這種在需求分析的兩個相鄰子階段中，或者在迭代周期的需求分析中，後一段或周期的需求分析結果與前一次不一致，我們把這種不一致稱為需求變更。產生需求變更的原因主要有以下幾個方面：1) 在需求分析階段，開發方與用戶的溝通不夠。在需求分析階段，開發方與用戶沒有很好的交流，開發方就根據用戶提供的大概信息，自己推導出用戶的需求。通過這種需求分析得出的需求往往會和用戶的實際需求相差甚遠，導致用戶提出更改需求。2) 項目的實施周期過長。隨著時間的推移，用戶對整個系統的了解也越來越深入。他們會對模塊的界面、功能和性能方面提出更高更多的要求。3) 技術更新過快。由於技術的快速更新， 企業可能引進一些新的設備， 而這些設備可能就會與我們的目標系統有直接的關系， 由於這一變化可能發生在解決用戶原先問題之前或者之中，那麼開發方不得不加入這一新的需求。[3]
為了盡可能地避免發生需求變更，以及保證需求分析的高穩定性，可以採用以下方法：1) 分工明確，系統分析員和程序員各有不同的職責。系統分析員處在用戶和程序員之間，溝通用戶和開發人員的認識和見解。系統分析員一方面要協助用戶對所開發的軟體提出需求，另一方面還要和程序員充分交換意見，探討其合理性和實現的可能性。如圖3所示，系統分析員在需求分析階段起著重要的作用。
2) 開發方與用戶進行協作和交流。在用戶提出需求變更時系統分析員應該認真聽取用戶的要求並加以整理和分析。分析需求變更的原因並提出可行的替代方案；同時向用戶說明這些需求變更會對整個項目的開發帶來的不良後果。3) 合同約束。由於需求變更可能會對整個項目產生影響，所以，開發方和用戶在簽定項目合同時，可以對需求變更增加一些相關的合同條款。4) 建立需求文檔並進行版本控制。需求分析的最終成果是一份客戶和開發方對所開發的產品達成共識的系統文檔。有了這份文檔， 即使開發方人員的角色有所變動，也不會對需求分析的前期工作有所影響。對每次的需求變更都用一個新的版本來標識。5) 需求評審和設立需求基線。為了讓開發方詳細了解用戶的需求，讓不同人員從不同的角度對需求進行驗證，作為需求的提出者（用戶方），在需求評審過程中，往往能提出許多有價值的意見，同時，也是對需求進行最後確認的機會，可以有效減少需求變更的發生。需求在通過正式評審和批准之後，應該確定需求基線，進一步的需求變更將在此基線的基礎上，依照項目定義的變更過程進行。設置需求基線可以將變更引起的麻煩減至最小。

軟體架構（software
architecture）是一系列相關的抽象模式，用於指導大型軟體系統各個方面的設計。 軟體架構是一個系統的草圖。軟體架構描述的對象是直接構成系
統的抽象組件。各個組件之間的連接則明確和相對細致地描述組件之間的通訊。在實現階段，這些抽象組件被細化為實際的組件，比如具體某個類或者對象。在面向
對象領域中，組件之間的連接通常用介面_(計算機科學)來實現。
軟體體系結構是構建計算機軟體實踐的基礎。與建築師設定建築項目的設計原則和目標，作為繪圖員畫圖的基礎一樣，一個軟體架構師或者系統架構師陳述軟體構架以作為滿足不同客戶需求的實際系統設計方案的基礎。
軟體構架是一個容易理解的概念，多數工程師（尤其是經驗不多的工程師）會從直覺上來認識它，但要給出精確的定義很困難。特別是，很難明確地區分設計和構架：構架屬於設計的一方面，它集中於某些具體的特徵。
在「軟體構架簡介」中，David Garlan 和 Mary Shaw
認為軟體構架是有關如下問題的設計層次：「在計算的演算法和數據結構之外，設計並確定系統整體結構成為了新的問題。結構問題包括總體組織結構和全局控制結
構；通信、同步和數據訪問的協議；設計元素的功能分配；物理分布；設計元素的組成；定標與性能；備選設計的選擇。
但構架不僅是結構；IEEE Working Group
on Architecture 把其定義為「系統在其環境中的最高層概念」。構架還包括「符合」系統完整性、經濟約束條件、審美需求和樣式。它並不僅注
重對內部的考慮，而且還在系統的用戶環境和開發環境中對系統進行整體考慮，即同時注重對外部的考慮。
在Rational Unified Process 中，軟體系統的構架（在某一給定點）是指系統重要構件的組織或結構，這些重要構件通過介面與不斷減小的構件與介面所組成的構件進行交互。
從和目的、主題、材料和結構的聯繫上來說，軟體架構可以和建築物的架構相比擬。一個軟體架構師需要有廣泛的軟體理論知識和相應的經驗來事實和管
理軟體產品的高級設計。軟體架構師定義和設計軟體的模塊化，模塊之間的交互，用戶界面風格，對外介面方法，創新的設計特性，以及高層事物的對象操作、邏輯
和流程。
一般而言，軟體系統的架構（Architecture）有兩個要素：
它是一個軟體系統從整體到部分的最高層次的劃分。
一個系統通常是由元件組成的，而這些元件如何形成、相互之間如何發生作用，則是關於這個系統本身結構的重要信息。
詳細地說，就是要包括架構元件（Architecture Component）、聯結器（Connector）、任務流（Task-flow）。
所謂架構元素，也就是組成系統的核心"磚瓦"，而聯結器則描述這些元件之間通訊的路徑、通訊的機制、通訊的預期結果，任務流則描述系統如何使用這些元件和
聯結器完成某一項需求。
建造一個系統所作出的最高層次的、以後難以更改的，商業的和技術的決定。
建造一個系統之前會有很多的重要決定需要事先作出，而一旦系統開始進行詳細設計甚至建造，這些決定就很難更改甚至無法更改。顯然，這樣的決定必定是有關系統設計成敗的最重要決定，必須經過非常慎重的研究和考察。
對於較大的通常應用應該使用框架，可能節省不少時間.。能使你很輕松的開發出一款軟體來。
（軟體開發一般比較會關注設計模式而不是架構設計）

2. 系統分析要回答系統應該怎麼做的問題,這是對的嗎

是錯誤的,

參見專屬>http://ke..com/view/170100.htm

3. 企業在進行管理信息系統實施過程中的要點有哪些

管理信息系統是一個以人為主導，利用計算機硬體、軟體、網路通信設備以及其他辦公設備，進行信息的收集、傳輸、加工、儲存、更新、拓展和維護的系統。管理信息由信息的採集、信息的傳遞、信息的儲存、信息的加工、信息的維護和信息的使用六個方面組成。
完善的管理信息系統具有以下四個標准：確定的信息需求、信息的可採集與可加工、可以通過程序為管理人員提供信息、可以對信息進行管理。管理信息系統主要有以下幾個功能：
1、數據處理功能；
2、計劃功能；
3、控制功能；
4、預測功能；
5、 輔助決策功能
而企業進行管理信息系統，對企業有以下作用：
1、管理信息是企業重要的資源

對企業來說，人、物資、能源、資金、信息是5大重要資源。人、物資、能源、資金這些都是可見的有形資源，而信息是一種無形的資源。信息資源決定了如何更有效地利用物資資源。信息資源是人類與自然的斗爭中得出的知識結晶，掌握了信息資源，就可以更好地利用有形資源，使有形資源發揮更好的效益。
2、 管理信息是企業決策的基礎
決策是通過對客觀情況、對客觀外部情況、對企業外部情況、對企業內部情況的了解才能做出正確的判斷和決策。所以，決策和信息有著非常密切的聯系。過去一些憑經驗或者拍腦袋的那種決策經常會造成決策的失誤，越來越明確信息是決策性基礎。
3、 管理信息是企業實施管理控制的依據
在管理控制中，以信息來控制整個的生產過程、服務過程的運作，也靠信息的反饋來不斷地修正已有的計劃，依靠信息來實施管理控制。有很多事情不能很好地控制，其根源是沒有很好地掌握全面的信息。
4、管理信息是企業聯系組織內外的紐帶
企業跟外界的聯系，企業內部各職能部門之間的聯系也是通過信息互相溝通的。因此要溝通各部門的聯系，使整個企業能夠協調地工作就要依靠信息。所以，它是組織內外溝通的一個紐帶，沒有信息就不可能很好地溝通內外的聯系和步調一致地協同工作。
企業在進行管理信息系統實施過程中的要點包括：
1、規劃階段
系統規劃階段的任務是：在對原系統進行初步調查的基礎上提出開發新系統的要求，根據需要和可能，給出新系統的總體方案，並對這些方案進行可行性分析，產生系統開發計劃和可行性研究報告兩份文檔。

2、分析階段
系統分析階段，也被成為邏輯設計階段。這個階段的任務是根據系統開發計劃所確定的范圍，對現行系統進行詳細調查，描述現行系統的業務流程，指出現行系統的局限性和不足之處，確定新系統的基本目標和邏輯模型。
系統分析階段的工作成果體現在「系統分析說明書」中，這是系統建設的必備文件。它是提交給用戶的文檔，也是下一階段的工作依據，因此，系統分析說明書要通俗易懂，用戶通過它可以了解新系統的功能，判斷是否所需的系統。系統分析說明書一旦評審通過，就是系統設計的依據，也是系統最終驗收的依據。

3、設計階段
系統分析階段回答了新系統「做什麼」的問題，而系統設計階段的任務就是回答「怎麼做」的問題，即根據系統分析說明書中規定的功能要求，考慮實際條件，具體設計實現邏輯模型的技術方案，也即設計新系統的物理模型。所以這個階段又稱為物理設計階段。它又分為總體設計和詳細設計兩個階段，產生的技術文檔是「系統設計說明書」。

4、實施階段
系統實施階段的任務包括計算機等硬體設備的購置、安裝和調試，應用程序的編制和調試，人員培訓，數據文件轉換，系統調試與轉換等。系統實施是按實施計劃分階段完成的，每個階段應寫出「實施進度報告」。系統測試之後寫出「系統測試報告」。

5、維護與評價
系統投入運行後，需要經常進行維護，記錄系統運行情況，根據一定的程序對系統進行必要的修改，評價系統的工作質量和經濟效益。

4. 系統分析的任務是什麼 如何進行系統分析

任務是：在充分認識原信息系統的基礎上，通過問題識別、可行性分析、詳細調查、系統化分析，最終完成新系統的邏輯方案設計，或稱邏輯模型設計。邏輯方案不同於物理方案，前者解決「做什麼」的問題，是系統分析的任務；後者解決「怎麼做」的問題，是系統設計的任務。 沒有系統分析的內容，只有系統化分析的主要內容。可能不太一樣，系統化分析是系統分析的一個步驟呢。 如果硬要講內容,也許就是問題識別、可行性分析、詳細調查、系統化分析、邏輯模型設計吧 系統分析方法是指把要解決的問題作為一個系統，對系統要素進行綜合分析，找出解決問題的可行方案的咨詢方法。蘭德公司認為，系統分析是一種研究方略，它能在不確定的情況下，確定問題的本質和起因，明確咨詢目標，找出各種可行方案，並通過一定標准對這些方案進行比較，幫助決策者在復雜的問題和環境中作出科學抉擇。 系統分析方法來源於系統科學。系統科學是20世紀40年代以後迅速發展起來的一個橫跨各個學科的新的科學部門，它從系統的著眼點或角度去考察和研究整個客觀世界，為人類認識和改造世界提供了科學的理論和方法。它的產生和發展標標志著人類的科學思維由主要以「實物為中心」逐漸過渡到以「系統為中心」，是科學思維的一個劃時代突破。 系統分析是咨詢研究的最基本的方法，我們可以把一個復雜的咨詢項目看成為系統工程，通過系統目標分析、系統要素分析、系統環境分析、系統資源分析和系統管理分析，可以准確地診斷問題，深刻地揭示問題起因，有效地提出解決方案和滿足客戶的需求。 系統分析的主要任務是將在系統詳細調查中所得到的文檔資料集中到一起，對組織內部整體管理狀況和信息處理過程進行分析。它側重於從業務全過程的角度進行分析。分析的主要內容是：業務和數據的流程是否通暢,是否合理；數據、業務過程和實現管理功能之間的關系；老系統管理模式改革和新系統管理方法的實現是否具有可行性等等。系統分析的目的是將用戶的需求及其解決方法確定下來，這些需要確定的結果包括：開發者關於現有組織管理狀況的了解；用戶對信息系統功能的需求;數據和業務流程;管理功能和管理數據指標體系;新系統擬改動和新增的管理模型等等。系統分析所確定的內容是今後系統設計、系統實現的基礎。

5. 企業在什麼情況下要進行系統的工作分析，明確崗位職責

企業在組織架構發生變化、崗位部門名稱發生變化、部門的隸屬關系發生變化、主要職能變內動、企業容剛剛成立的時候要進行系統的工作分析，明確崗位職責。

工作分析以便確定每一項工作的6w1h：用誰做（Who）、做什麼（what）、何時做（When）、在哪裡做（Where）、如何做（How）、為什麼做（Why）、為誰做（Whom）。分析的結果或直接成果成為崗位說明書。

(5)在進行系統分析時要注意的結合是擴展閱讀：

工作分析類型

1、崗位導向型是指從崗位工作任務調查入手進行的工作分析活動。（以崗位為核心，韋伯官僚層次理論）

2、人員導向型是指從人員工作行為調查入手進行的工作分析活動。（以員工為核心，前提條件人崗匹配，員工績效良好）

3、過程導向型從產品或服務的生產環節調查入手進行的工作分析活動。（以生產過程為核心，流程的科學性）

6. 如果要做系統分析員要學習什麼知識

基本功
好的系統分析員都是從優秀的程序員中產生的，堅實的編程功底、豐富的經驗是今後做系統分析的基礎。
其實在大學的時候我們就應該夯打基礎，現在工作之才深深的感到，所以讀研期間就惡補基礎的東西。
沒有對系統本身進行過透徹剖析過，很難領會到其中一些難以言述的精華。但並不等於好的程序員就能夠成為好的系統分析員。
合理的知識結構。語言能力、文字表達能力、技術的全面性等是對系統分析員的基本要求。比如說c/s和3 層開發，如果僅僅對Netscape公司的產品熟悉還不夠，還需要了解比如微軟等產品，並且要了解他們中產生歷史，發展思路，技術優劣，以應付各種窮追猛打的提問。但更重要的是，這是你為應用定製技術要求的前提。

思想
全局觀念是系統分析員必須具備的觀念。如果系統分析員設計時太注重細節，往往會陷入在某個問題上糾纏不清的泥潭，系統分析員要有面向用戶的思想。系統分析員應當有能力將自己扮演成用戶，來了解要交付的項目看起來想什麼樣式，感覺想什麼，從而了解用戶的想法並挑選出合理部份去開發。從這個意義上說，系統分析員才能獲得有意義的見解去引導他的開發組成員。系統分析員頭腦中要對項目結局有一個清楚的認識，並保證項目不偏離方向。系統分析員要有根植於技術，高於技術思考問題的思想。純粹的程序員通常對最終結果考慮的不是很多，當一種新的技術在市場上出現時，他們對能否按時交付的考慮就比較少，而強烈希望他們的計劃能夠建立在新的技術之上。因此，系統分析員的想法和行動要像一個用戶，又要能夠站在技術的高度，成為真正的用戶、程序員之間的代言人。

任務難度的預測能力
系統分析員要具備快速的任務難度預測能力以及具備快速確定開發小組人員構成和任務劃分的能力。昆蟲自然會長出翅膀，而思想卻需要長期的浸潤。要做到這點，需要大量的思考、學習。設計遠比編程重要。當今軟體業的發展，各種開發工具的出現，編程已經不是什麼問題，程序員的工作某種程度上講是將別人現成的東西拼湊堆砌起來。系統分析員要清楚的認識到，現在大多數程序員沒有學會怎麼去整體的了解一個系統，有些甚至不了解編程（這不是說他們不會寫代碼）。可視化的開發工具加五花八門的控制項，程序員可以偷點懶了，基於技術，跳出框架。基於現有技術結合用戶需求思考問題，設計時跳出框架。

關鍵
獲得信任。系統分析員最重要的素質是獲得信任，這是成為優秀系統分析員的關鍵。成熟最為關鍵。成熟可以為整個項目組提供正確的支持,能夠理解技術怎樣才能解決用戶的需求。

准備工作
統一的各種文檔模式，這其中包括今後軟體變數、欄位命名規則。我推薦用 Java 制定的規則做基礎，通過改造成為適合自身實用的標准。統一的文檔管理。統一的分析軟體。比如說rose（UML太規范，國內的軟體管理水平根本用不上，只不過盡量應用，你自己對系統分析的理解有好處）方法是思想的放映.
我在拙作"在中國沒有人懂計算機"里發了點牢騷，聽說挨了部分人（習慣性的）罵。其實，bbs本來就是發泄的地方，在這里從來就罕有有內容的文章。
自從"維納斯"登陸深圳後，大家更著眼於從宏觀看中國的IT業了。中國IT這棵小樹，說實在的，長到今天實在是不容易。一些人提出了"反對微軟霸權"的口號，不少人呼喚中國"矽谷"的出現。微軟的成功不是技術的成功，更多的是商業運作的成功。中國IT這棵樹能長多高，取決於他所植根於的土壤。而現在的事實是，這片土壤實在是太貧瘠了！如果按我們現在的思路和搞法，是長不成大樹，更別指望能結出像「微軟」、「矽谷」這樣豐碩的果實。如果說，我們的軟體技術落後美國十年，我們的硬體製造技術則落後美國二十年，我們的管理水平落後美國至少三十年。而最終決定發展速率的恰恰是我們的死穴---低劣的管理水平。低劣的管理水平的形成的原因有著深厚的背景和多方面的原因。

系統分析工作是解決一個問題的工作,目標是將一個對計算機應用系統的需求轉化成實際的物理實現,其中復雜就復雜在實際的面太多。在系統分析過程之中注意問以下的問題,可能會所進行的系統分析設計工作有幫助。
(1)您所完成的系統目的是什麼?注意不是功能要求,而是目的.也就是為什麼要建設、為什麼要現在建設。在考慮系統目的時，我更多的側重於系統的最終目標考慮，因為一個系統不可能一下子完美，為系統留些餘地。
(2)您所完成的系統有哪些方面參與，各方面的初衷是什麼？那些人可能在系統建設中起重要作用，他們會採取什麼樣的態度？你對他們有多少影響力？中國IT行業的失敗之一就是人"太年輕"，一定要有領導的支持，否則完蛋。不要認為自己對他們會有多少影響力，即便有，也要盡可能的認為是決策者再影響他們。在中國，一個技術員，你算老幾？說到這里我很悲哀。哪些人在系統中起重要作用並弄清楚他們的態度，這點十分關鍵。
(3)您的系統是否有一個明確的評價標准？最好從參與的各方面都進行考慮。不知道這樣說對不對，在系統建設之前，對你的程序員、對你的領導要有至少不同的兩種評價。
(4)你的系統設計思想是什麼？是否能夠得到各方面的認可。如果高明，對領導、對程序員都採用引導，得到認可的最好辦法，就是讓他們認可他們自己的想法。
(5)你對參與系統設計開發的人員了解嗎？他們的特長在哪裡，是否願意與你合作，為什麼？你對他們有足夠的影響力嗎？軟體發展到一定的程度，不是編程，不是數學，而是管理。
(6)你的系統開發計劃是否完善？你的計劃表有明確的階段嗎？任何一階段都應該怎樣完成？如何對這一階段完成的情況進行評價？
(7)你對所採用的系統開發方法以及工具是否熟悉？你的夥伴是否熟悉？事實上，不是每種好的工具都要使用，也並不一定都要他們熟練掌握。提醒諸位一句，當你將方案做得可以不依賴某個程序員，你在程序員面前就無信任可言，因為從此程序員將受到更大的生存壓力。我堅決不在公司使用rose。
(8)你所完成的系統是否有原型？計算機的或者物理的。
以上的幾個問題都是在系統分析以及系統規劃時涉及到的，供各位參考。

7. 在系統分析階段，做系統詳細調查前為什麼要先對用戶進行培訓求解，

因為系統分析的難點之一就是用戶與設計者的溝通，用戶了解原系統的使用，系統設計者則關心實現系統。培訓一方面讓用戶理解設計者關心的事，一方面理解設計者調查的方式和手段

8. 在進行系統分析時,應特別注意抓住管理系統的幾個主要特性

在進行系統分析時，應特別注意抓住管理系統的三個主要特性。

9. 在進行系統聚類分析時，不同的類間距離計算方法有何區別

聚類分析有兩種主要計算方法，分別是凝聚層次聚類（Agglomerative hierarchical method）和K均值聚類（K-Means）。
一、層次聚類
層次聚類又稱為系統聚類，首先要定義樣本之間的距離關系，距離較近的歸為一類，較遠的則屬於不同的類。可用於定義「距離」的統計量包括了歐氏距離 (euclidean)、馬氏距離(manhattan)、 兩項距離(binary)、明氏距離(minkowski)。還包括相關系數和夾角餘弦。
層次聚類首先將每個樣本單獨作為一類，然後將不同類之間距離最近的進行合並，合並後重新計算類間距離。這個過程一直持續到將所有樣本歸為一類為止。在計算類間距離時則有六種不同的方法，分別是最短距離法、最長距離法、類平均法、重心法、中間距離法、離差平方和法。
下面我們用iris數據集來進行聚類分析，在R語言中所用到的函數為hclust。首先提取iris數據中的4個數值變數，然後計算其歐氏距離矩陣。然後將矩陣繪制熱圖，從圖中可以看到顏色越深表示樣本間距離越近，大致上可以區分出三到四個區塊，其樣本之間比較接近。
data=iris[,-5]
dist.e=dist(data,method='euclidean')
heatmap(as.matrix(dist.e),labRow = F, labCol = F)
X
然後使用hclust函數建立聚類模型，結果存在model1變數中，其中ward參數是將類間距離計算方法設置為離差平方和法。使用plot(model1)可以繪制出聚類樹圖。如果我們希望將類別設為3類，可以使用cutree函數提取每個樣本所屬的類別。
model1=hclust(dist.e,method='ward')
result=cutree(model1,k=3) 為了顯示聚類的效果，我們可以結合多維標度和聚類的結果。先將數據用MDS進行降維，然後以不同的的形狀表示原本的分類，用不同的顏色來表示聚類的結果。可以看到setose品種聚類很成功，但有一些virginica品種的花被錯誤和virginica品種聚類到一起。

10. 9如何進行系統分析

系統分析階段的任務很多，本課程設計僅要求大家完成幾個重要環節的工 版作，主要有繪制系統功能結構權圖和業務流程圖等。該階段結束後要提交系統需求 分析說明說。具體內容如下： 需求分析說明書 1 、系統功能結構圖（ HIPO 圖） （在該功能結構圖中選一個子系統進行逐層分解） 2 、系統功能說明 （對以上選中的子系統進行功能描述） 3 、現有系統的業務流程圖及說明 （對以上選中的子系統繪制手工系統或舊的計算機系統的業務流程圖並進行簡 單的功能說明） 4 、新系統的業務流程圖及說明 （對以上選中的子系統繪制計算機系統下的業務流程圖（重組後的）並進行簡單的功能說明）