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