如何分析企業管理信息系統的需求

張靖笙舊作新改

摘要:

    文章分析了企業管理信息系統需求的特點，結合作者在工作實踐中分析了傳統需求分析方法在開發企業管理信息系統中遇到的問題，提出相應的解決方法。

關鍵字:

    軟件工程，需求分析，企業管理信息系統

前言:

作者曾在一家大型國有商業銀行擔任軟件工程師工作多年，按照軟件工程理論組織開發工作一直是我對于自己的要求，但為單位開發信息系統的過程中工作實踐中，我發現嚴格套用傳統軟件工程理論在需求分析方面的規范比較困難。

傳統需求分析規范在實踐中的遇到的矛盾

需求分析階段關系到一個軟件開發的成敗，這已經得到了普遍的認識,然而，根據作者在實際開發工作的自身經歷，以及作者曾主動地和許多同行的交流中發現，發現現在國內的許多軟件開發的需求分析階段，基本沒有按照嚴格的軟件工程的規范要求，可以說，在許多開發項目中，按照傳統軟件工程規范要求的需求分析往往是一個非常尷尬的過程，為什么呢?

    這是因為軟件開發人員沒有工程觀念嗎？國際軟件工程理論和技術引入我國也差不多二十年了，特別是在二十世紀九十年代，我國計算機軟件產業得到了長足的發展，涌現了大量成功的軟件開發成果,培養了相當規模的軟件開發隊伍。作為軟件開發生力軍的年輕的軟件工程師大多數是剛剛從學校畢業的大學生，學校教育中軟件工程是一門非常重要的課程，可以說現在的絕大部分程序員在這方面經過了嚴格的教育和訓練，而為什么在實際工作中出現了很大的偏差?

根據我在實際工作中的經驗,問題主要來自以下方面：

1.需求分析本身的難度。需求的任務是了解和描述軟件用戶對軟件的需求，即明確做什么。但在實際的軟件開發中，用戶了解他們的專業領域，但計算機知識，特別是軟件知識往往比較薄弱,而開發人員與此恰好相反，而在需求分析的過程中，雙方面對的往往不是一個可見的產品，而只是頭腦中的構思和想象，由于專業的差異和溝通的有限，用戶的許多需求對開發人員來說往往是難于理解的和準確把握。

2.傳統軟件工程規范沒有量化需求分析工作。傳統軟件工程理論中對需求分析工作的要求只是對軟件要求整體上的分析，不要求陷入實現上的細節。但實際工作中，在許多類型的應用系統開發中，許多技術細節本身就關系到需求能否實現或正確實現，如有企業管理信息系統程序開發經驗的人誰都知道，根本不可能拋開數據類型去定義一個數據實體的屬性。所以在實際的工作中忽略這些至關重要的細節的需求分析往往是不完整的，造成的混亂往往嚴重影響后續的開發。所以需求分析工作到底深入到什么程度，這個并沒有確定的標準。

3. 傳統軟件工程規范在需求分析的嚴格執行有實際管理上的難度。在廣大的應用軟件開發部門，軟件開發工作的地位往往只是本單位業務的輔助，一般沒有專職的而且非常有經驗的系統分析員，需求分析往往由主管經理和開發程序員簡單進行，而領導往往重成績多于重過程，對于一個沒有顯效的需求分析過程，領導的耐心往往有限，這就造成了對需求分析缺乏嚴格的管理和要求。

4.嚴格按照傳統規范要求進行需求分析在時間和開發成本的限制。由于用戶對軟件技術的認識水平，他們對軟件的開發在時間上往往要求過高，他們狠不得明天就可以使用軟件。如果你在那里分析來分析去不動手，在實際工作中，特別當用戶是單位的上層領導，他們往往覺得這種對他們而言空洞無物的分析是開發人員的紙上談兵,時間一長不免就會流露出不滿。這令開發人員非常尷尬，往往非常嚴重地打擊他們的自信心和士氣。

綜上所述，傳統軟件工程規范中需求分析理論在實踐中的矛盾是成本，效率和規范要求間的矛盾。而忽略規范要求的代價也是慘重的，那我們能找到一種方法解決以上矛盾嗎？我覺得提高軟件工程規范要求中在需求分析階段的可操作性是解決問題的關鍵。當然由于計算機應用的多樣性，我們不可能找到能醫百病的靈丹妙藥，但在開發比較常見的企業管理信息系統中，下文試圖提出一種比較有針對性的需求分析方法。

企業管理信息系統程序的需求特點

    數據庫技術的核心思想是數據的獨立與共享，所以開發企業管理信息系統，就是利用計算機數據庫技術來組織，管理和使用企業經營和管理活動中的各種信息。不同形式的企業管理信息系統可謂多種多樣，但功能需求的核心是圍繞著數據庫管理的信息來展開的。筆者曾開發過多個不同應用領域的數據庫的應用，我發現在企業管理信息系統中雖然功能很多，許多功能在邏輯上相似，往往只是處理的數據不同，很多時候，信息管理軟件功能基本上是數據的查詢，更新，維護,并不需要復雜的算法。所以，我認為企業管理信息系統需求分析應該圍繞數據(信息)，而不是功能展開。這與傳統的需求分析中以分析功能需求為核心有明顯的不同。從這個意義上，如果傳統需求分析階段是“做什么”，在企業管理信息系統需求分析階段就是先要解決“有什么”，然后再明確“做什么”。

企業管理信息系統的需求特征

    需求分析作為軟件工程的第一階段，是整個軟件開發項目進行設計和實現的基礎，決定了一個項目的成敗。但是需求分析不能只看成是一個獨立的階段，第一個階段了解的需求也只是初步的需求，對需求的了解貫穿整個項目的始終，了解需求的過程是一個逐步細化，逐步深入的過程，整個項目自始而終都需要與用戶交流。

    既然企業管理信息系統需求以數據為中心，在需求分析階段就強調數據和數據結構的分析一點也不過分。所以，對于企業管理信息系統系統，應該把數據庫的詳細設計向前移，即從傳統軟件工程階段的詳細設計階段提前到需求分析階段進行。

    需求分析大體上分為以下幾個階段：

    1)模型需求分析(總體設計)

    2)概念需求分析(概念設計)

    3)細節需求分析(詳細設計)

    4)輸入輸出需求分析(界面設計)

    這些需求分析貫穿整個項目的各個環節中，與設計是穿插在一起。

需求分析過程活動

1)模型需求分析

    這個階段體現了系統的總體構思與設計，任務是了解系統的組織形式和功能需求概貌，解決“是什么”的問題。我認為模型需求分析主要任務是系統架構的定義，這涉及到硬件，用戶環境，系統功能等多方面的全局考慮。如系統是C/S模式還是Internet模式，如何進行功能的分層。這些都需要在模型需求分析過程中決定。

    模型需求分析工作是項目的早期，所以對功能的描述應該有高度的抽象性，在理想的情況下，一個系統最好由一句話或一張紙內描述，便于開發人員對系統目標的整體把握，也保持了與用戶交流的靈活性和一致性。所以在項目初期，我不贊成用功能模塊圖對功能需求做太多層次的金字塔式羅列，特別如果是系統的分布式分層設計，詳細的功能模塊圖在項目早期沒有什么實際意義，反而容易舍本求末。

    我們完全可以把完整的功能模塊圖放在細節需求分析階段完成。

2)概念需求分析

    概念需求分析的任務是對系統中涉及的概念進行調查和分析，分析有什么信息，如何組織和描述數據，數據由那些數據項組成，各數據項是什么含義，數據的走向是什么樣的？概念需求分析的目的是建立系統的概念模型，主要是建立描述數據的靜態模型和描述系統運行流程的動態模型，解決“有什么”問題。

    當完成模型需求分析后，就要進入到概念需求分析。做概念需求分析，首先要收集原始資料，然后請用戶講述手工的工作流程，根據用戶提供的原始資料和對工作流程的了解的基礎上，我們才可以著手進行概念設計。

3)細節需求分析

   細節需求分析要在完成概念設計之后進行，這個階段是分析如何具體實現用戶需求,就是解決“怎么做”的問題。這個階段要對用戶的需求完整而清晰地確定下來，所以與用戶的交流比前兩個階段多，交流的內容應該更加具體。

   細節分析的具體任務是要根據概念設計定義的概念模型制定具體的實現細節。對于靜態模型，要給出詳細的數據字典，包括了表，數據項，數據項限制條件等詳細信息。對于動態模型，要給出具體的狀態定義，事件定義，狀態改變的流程，對數據所有操作的定義等等詳細的設計信息。要求根據細節需求分析的成果應該能成為編碼和建庫的依據。

4)輸入輸出需求分析

   用戶能否用好軟件最終決定項目的成敗，良好的用戶使用界面是不可忽視的。用戶界面的好壞并不是追求界面的花巧(這是程序員經常犯的毛病),而是界面的設計是否能提高用戶使用軟件的效率，這需要了解用戶的使用環境，操作水平，操作習慣，個人喜好等多方面。輸入輸出需求分析要做到界面設計和概念設計的相互獨立，不能因為界面的表示影響概念設計的穩定，同時也要保持能適應用戶各種不同操作要求的靈活性。具體可以先和用戶共同草擬一些界面設計大綱，在開發過程中邀請用戶試用軟件，根據反饋意見不斷改進和修改。

分析信息內容的工具選擇

    我們分析“有什么”信息，傳統的需求分析理論用數據流圖和數據字典來表達“有什么”信息。數據流圖核心是功能，而在許多企業管理信息系統特別是信息管理系統開發初期，在沒有清晰完整的信息構成分析前，功能的需求往往難以穩定。在開發企業管理信息系統的需求分析初期，我不提倡使用數據流圖，因為在企業管理信息系統中，數據流圖往往不能令人滿意地說明信息構成問題，而且隨著數據的增加，功能流程的變遷需要經常修改早期的設計，這會造成工作的反復。數據字典可以表達數據的構成，但卻沒有定義數據的類型。在一個企業管理信息系統中，數據的類型的通過字段類型表達，有開發經驗的人應該知道，清楚每一個數據字段的含義和類型在開發企業管理信息系統中有重要的意義，試想一下，如果一個字段是圖象型，對數據的功能需求不言而喻。而傳統的需求分析過程不要求確定數據的具體類型，而在開發一個企業管理信息系統時，需求分析階段忽略了這一步就會毫無疑問地造成對需求理解的模糊，并使得需求分析變成空洞無物的紙上談兵。

小結

    設計過程更要和人工智能，知識庫，程序語義等最新研究成果結合起來，實現用邏輯方法檢驗數據庫設計的完整性，用推理方法使許多設計步驟可以自動進行，并開發自動編碼功能，把詳細設計的成果直接轉換成SQL代碼，更大地提高開發效率。進一步我們應該把這些成果產品化，開發一系列CASE工具，最終發展成為一個全功能的軟件開發平臺。

參考文獻:

[1]中山大學軟件所:設計規范與實例分析

[2]張海藩:軟件工程導論,清華大學出版社，1998年1月

[3]Roger S.Pressman:Software engineering,a practitioner’sapproach,Fourth Edition,McGraw-Hill ,1997

[4]鄭人杰，殷人昆，陶永雷:實用軟件工程第二版,清華大學出版社，1997年4月

注：本文的原稿2001年6月2日發表在核心學術雜志《中國計算機工程與應用》，當時作者是在讀中山大學軟件研究所碩士研究生。