本文以某個IT產品銷售公司的資訊系統專案的開發為背景，討論了一個資訊系統需求分析的整個過程，其重要特徵是：所涉及的專案是原有系統的一個升級替換版本。因此，需求分析過程不同於建立一個全新的系統，大體上可分為三個階段：（）實施逆向工程獲得對系統的初步瞭解；（2）在第1步的基礎上寫出基本需求，交由客戶評審補充；（3）在第2步的基礎上開發原型，利用原型與客戶交流，最終獲得基線需求。針對上述三個階段，本文論述了所使用的分析方法與工具以及所遇到過的一些典型問題和措施，最後對需求分析中使用的工具，談一些自己的初步體會。
【正文】
我於1998年8月至2000年7月參加了某個大型集團的企業資訊系統的開發工作，該大型集團的業務主要涉及到IT類產品的進銷存。本人在專案中負責系統分析的工作，該集團企業原先已委託某個電腦公司開發過一套IT類產品管理系統，但是該老系統存在兩個主要的問題：（一）系統執行速度非常慢，如商品銷售開單時，從確定開單到開單完成有時需要1～2分鐘左右的響應時間，讓客戶無法忍受。（二）系統資料不準確，經常出現實物庫存與電腦庫存嚴重不相匹配的情況，使銷售資料的統計產生一些混亂，有關財務的資料因此無法有效使用，只能採用人工錄入方式補充進行。在這種情況下，該集團的總經理決定參考原有系統重新開發一個系統，以便解決原系統所存在的上述兩個難以克服的難題。注；原系統採用PB6.5開發，資料庫採用SYBASE，伺服器採用Windows2000Server，客戶端採用Windows98，程式架構採用的是傳統的C/S結構。
鑑於該集團業務操作複雜，流程多，涉及人員多等特點，以及專案完成時間短，經費有限，人員有限等限制約束條件，再考慮到必須避免前一系統出現過的結構混亂與難於維護等問題，我們決定要對原系統的需求做一個比較徹底的和切實可行的分析，由於原有系統已經開發了近兩年，並且客戶也有了一定的使用經驗，業務基本流程本身也並沒有太大的變化，因此，我們把需求分析的過程分為三步：（）分析原有系統的結構，主要是資料庫結構和程式結構，（2）在獲得第（1）步結果的基礎上寫出基本需求，交由客戶評審補充，（3）在第（2）步的基礎上開發原型，利用此原型與客戶交流，從而獲得最終可用的需求結果。下面按上述三步分別加以論述。
第一步是實施逆向工程，獲取原有系統的基本需求。
由於原有系統在功能上大體上能基本滿足客戶的需求，並且在兩年多的開發中也積累了不少經驗，因此，從中可以獲得一些有益的參考，也可以避免多走彎路。在這一階段，我們採用的主要工具是PB自帶的PowerDesigner和PBDocuments；前者主要用來分析資料庫結構，後者主要用來分析程式結構，便於開發人員與高階使用者理解程式。採用這兩個工具的原因是：原系統過於龐大，模組多，資料庫模式多，表格量很大，僅靠人工的方法很難從中獲得一個比較完整的、明確的系統結構以及整體構成，而且原有系統未能提供一套正確完整有效的設計文件，於是我們只能依靠工具輔助來進行。在使用PowerDesigner分析資料庫，並且用PBDocuments分析原程式中的PBL以後，我們對原系統的結構有了一個初步的瞭解，再結合對原系統的使用，基本明確了功能與流程的需求，並在此基礎上用人工錄入方式，產生了初步需求的自然語言文件。這裡指出，使用PowerDesigner的一個不足之處是：如果一個表中的欄位過多，而且又同時依賴多個表時，輸出的表格相關圖形很複雜，有很多交叉，且難於調整，不方便閱讀及列印。
第二步是在第一步的基礎上進行的，即寫出系統基本需求，交由客戶評審和補充。
通過第一步的逆向工程，我們獲得了系統的基本需求。為了充分記錄需求的變化及需求之間的依賴關係，我們決定選用Rational公司的RequisitePRO作為我們的需求管理工具，Rational公司有一整套用於需求管理的工具，功能非常強大，包括RequisitePro、ClearQuest等等，這些需求分析工具可以對需求進行全面的管理，包括記錄需求的變化情況，需求之間的依賴關係等等。但是，我們考慮到Rational的一套工具全面實施會非常昂貴與複雜，需要非常強的專案管理能力才能全面實施，因此，我們只採用了其中最簡單的一部分功能，那就是記錄需求變更，記錄需求之間的依賴關係，其他跟RUP有關的功能都給略去了。之所以這樣做，主要是考慮到專案的經費、人力以及國內軟體開發的實際情況。正如前面所說，我們根據自己的理解並寫出基本需求後，交由客戶做評審井做適當補充，我們將經過補充整理後的需求作為正式需求記錄入RequisitePro所維護的資料庫中，並對各個需求進行分類，設定優先順序等，這些工作完成後，就可以從資料庫中直觀地瞭解客戶到現在為止提出了哪些需求，哪些需求是必須優先考慮的，哪些是難度較大的`等等。在這個過程中，我們遇到了一些問題，譬如：使用者對我們用自然語言書寫的需求文件有許多地方不理解，往往在花了較長時間閱讀之後，仍不明白我們所描寫的需求過程與他們所完成的業務之間的對應關係；另外是由於首次採用RequisitePro進行需求管理，在型別劃分，屬性值的確定上，部分開發人員沒有經驗，造成了不少反覆，對於前者，我們的方法是想辦法增加一些示意圖，將大的流程分解為小流程，再與客戶反覆交流與溝通，最終達到雙方理解一致的目的。對第二個問題，則參考了一些例子，再結合實際中屬性的使用情況，給予取捨或者選擇，經過這一階段的工作，我們建立了基本的需求庫，定出了基本需求規格說明。