論軟體需求分析方法和工具的選用—論文4：IC行業內部的CAD應用

【摘要】
    本文通過一個整合電路設計有關的軟體項目，討論了該項目的主要特點和本人所擔任的工作，著重討論了在項目需求分析過程中採用的具體方法和工具以及選用的理由。
    由於項目的專業領域的特殊性，分兩類不同的需求討論了需求分析中遇到的問題及解決方案；在這個過程中給出了對選用的具體工具和方法的效果的描述。接著本文討論了對使用方法的改進的一些想法以及具體的實現過程。最後提出了我對需求分析的某些看法，強調了與客戶溝通的重要性。
【本文】
    近年，我一直從事某企業中有關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）最好再列舉更多的項目或例子，使方法與工具的討論更全面一些。（本文主要參考了上海解亮等人的論文）