本文通過一個集成電路設計有關的軟件項目，討論了該項目的主要特點和本人所擔任的工作，着重討論了在項目需求分析過程中採用的具體方法和工具以及選用的理由。
由於項目的專業領域的特殊性，分兩類不同的需求討論了需求分析中遇到的問題及解決方法；在這個過程中給出了對選用的具體工具和方法的效果的描述。接着本文討論了對使用方法的改進的一些想法以及具體的實現過程。最後提出了我對需求分析的某些看法，強調了與客戶溝通的重要性。
近年，我一直從事某企業中有關IT項目的開發，有一個系統是用於計算機輔助電路設計的，包括了從上流設計到下流設計的所有流程，如用於可設計百萬門數量級的邏輯門電路。有關方面把電路中路徑的提取、過濾以及表示的某軟件開發任務交給我公司，我有幸擔任了該部分的需求分析以及設計。
我所設計部分爲一單獨可啓動的軟件，主要是解析文件中的連線路徑，以列表視圖和用直方圖等把它們顯示出來，還可以執行諸如查找與過濾等功能。
委託方對此提供了很初步的需求說明，把一些基本功能及性能要求描述了一下。我在需求分析時的工作主要有兩點：第一，對該軟件的界面等詳細需求要自己重新進行分析提取。第二，對於已提供的功能要求需要深化和細化，以形成真正完整的需求分析文檔。
在接到需求分析任務後，我分析了一下所要完成的工作。發現由於是專用領域的軟件，對專業領域要求相當高，所以準備把此項目分成兩部分：
（1）界面所受專業領域影響幾乎沒有，但由於全部沒有任何要求，反而會感到風險和改動可能是最大的。
（2）功能方面由於委託方的許多功能都可以調用相應模塊來得到，並且已有了相應的書面的簡單需求，相應來說只是完成深化。對界面，我採用了部分RUP的思想迭代與漸進。而對功能需求採取了分層細化，每細化一層就要求委託方確認、修改和補充。
首先把風險較大的部分完成，這是現代軟件開發的基本常識。我選擇先進行界面的需求分析。第一步是根據功能描述抽取出邏輯模型，並使邏輯模型與界面元素及功能一一對應，大體上決定了界面應有的功能，然後根據該界面功能描述，確定具體的控件，這時，我參考了委託方已初步完成的主窗口的界面佈局及控件的使用規律，然後根據需要完成的功能從Qt（由於要支持Windows和Unix雙平臺，所以控件庫採用Qt）的類庫中選擇相應的控件。在提取和抽象邏輯模型時，我採用了Rose2000中的用例圖，即以USE-CASE圖來描述與外部的關係。之所以採用Rose，我是基於以下的原因：第一，在已開發的部分中，委託方統一要求我們使用Rose進行類和順序圖等的設計和代碼生成。第二，Rose提供了標準的圖來描述系統與外部的關係，在全球範圍已是一種標準結構。第三，使用上的方便性。我用Rose的USE-CASE圖，理清了我們的軟件窗口與委託方主窗口以及外部角色（操作者）之間的相互關係。
在確定了界面元素後，考慮到文檔的可理解性不是很強，我採用Visio2000把界面的外觀繪製出來，寫上了基本的控件作用，隨後送給委託方評審，幸運的是除了幾個小功能的修改，委託方基本批准了我的方案。
下面的工作是爲控件的行爲及狀態變化制定相應的狀態遷移圖，我選用的'工具仍是Rose，我用了狀態圖和時序圖，把重要的控件狀態變化及相應順序進行了描述，隨後的幾天把相應的DOC文檔建好寫明，基本上界面設計就完成了。
下面的需求是針對功能需求的。雖然委託方技術部門有初步的需求文檔，但由於領域的專門化不對，我不清楚其中複雜的路徑提取關係及較深入的專業術語，一直有一種舉步維艱的感覺。只能採用分層細化的原則，從最初的幾條深入一層變成十幾條。這樣的話，不會一下子碰到太深的專業問題，可以循序漸進從委託方與文獻的解答中不斷學習，深化自己對專業領域的瞭解，這樣在設計中自己始終是層層推進的，不至於一於碰到無法逾越的專業障礙。
在這一階段的開發中，由於一直是與自己不熟悉的專業領域打交道，所以我覺得一些輔助設計工具似乎無法發揮應有的功能。在這期間，對我幫助最大的應是公司的E-Mail系統，所有不清楚的問題的提出，以及對問題的解答都通過它進行週轉。換句話說，在需求分析階段，它起到了一個與客戶的交流溝通和客戶需求的提取作用。所以，我認爲在這一階段，E-Mail系統是對我幫助最大的工具，其次是Excel，我用它建立了問題跟蹤圖表，對每一個提出的問題，均需要記錄上去，把問題結果（可分爲已清楚、仍不太清楚、不清楚、尚未回答）均記錄下來，根據這些表，我可以很好地瞭解自己工作中的核心問題，並有瞭解決它的方向，提高了工作效率。
每進行一層的細化，我都把結果交付委託方審覈，由他們進行提出何時能終止細化，大約在八層細化後，對方認爲已達到了效果，確認可以結束。至此，分析工作全部完成，項目的需求分析基本成功了。
在這次需求分析中，我認爲取得成功的原因主要是方法和工具選擇得正確。在界面設計中採用了流行的輔
助工具，對需求及邏輯模型的建立提供很大的幫助，可以更方便幫助自己理清思路。選用了迭代法，把一些錯誤的影響在功能分析和界面分析的不斷迭代過程中加以改正。在後期，以功能需求爲主時，我主要依賴的是溝通工具和表格工具，這也說明輔助工具不是萬能的，需求分析的關鍵之關鍵，應是與客戶的交流與溝通。
通過這次案例，我認爲在軟件的需求分析工作中，方法的重要性應遠超過工具的使用，應當首先確定分析中的風險，把風險分類，用不同的方法去解決各類風險，而工具的選擇不僅是要看影響力和名氣，而是要真正爲我所用，應把握其精髓，即是此工具到底可以對開發有什麼幫助，而不是僅限於如何使用。我認爲在需求分析中工具的作用不外乎兩個：一是實際系統與環境模型等的抽象工具，二是需求表達工具。第一類的代表是Rose，第二類的代表是Word，WPS，Visio等，在這次項目中由於地理上的限制還用到了溝通工具，Web瀏覽與E-Mail服務系統。
最後我還是總結一下，在需求分析中工具方法都只是輔助項目成功的因素，真正的決定因素還是—一“與客戶的溝通”。
