論軟體需求分析方法和工具的選用—論文3：通訊行業的應用

【摘要】
    本文以某通訊公司的業務報表系統開發為例，討論了軟體需求分析工具與方法的選用。我們認為，軟體需求分析是軟體工程中重要的一步，直接關係到後繼工程的進行以及最終的產品能否滿足使用者的需求，因此在整個工程中起著關鍵性的作用。採用適當的工具，有可能顯著減少需求階段的錯誤，也可大幅度提高需求分析的品質和工作效率。當然工具的選用應當與實際的項目相結合，充分地發揮工具的作用。本文結合我們工作的實際經曆，簡要討論了開發系統時所選用的工具及其應用，選用時所考慮的原則以及所碰到的問題。在文中也結合多種開發方法（即傳統的瀑布法、資訊工程法、物件導向的方法）的比較，指出各種方法的不足之處，說明我們所採用的工具對軟體需求分析所起的作用，以及相應產生的效果。
【本文】
    我在某市一家通訊公司工作，作為一名技術骨於，受領導委託，參與了開發本公司的業務報表系統，我擔任系統的需求分析、總體設計和部分代碼的編寫工作。
    我所在的企業作為一家通訊運營公司，分為總部、省級公司和地市級分公司三級，各級公司之間都有資料報表的要求。但是，每一個地市分公司因所處的地方不同，經營環境不同，所面臨的問題也不一樣，因此形成了各具特色的資料報表（除地市分公司向省公司彙報的之外）。公司又分設了許多部門，這些部門也都會需要資料，作為分析決策的依據。因此，瞭解各個部門的需求就成了業務報表系統的關鍵。
    在調研的過程中，我選用了一種工具叫Play CASE，可以從網上免費下載，有很強的功能。下面就介紹一下，在需求分析階段，我是如何使用這一工具的。
    第一步，瞭解業務組織圖。公司內部的資料實際上是在部門之間流動的。業務部門需要知道在本地覆蓋區內各基站的話務量、當天的話務量（即話務量的時空分布）。財務部門需要知道本月各類使用者的話費收入、預交款收入、與其他電信電訊廠商的網間結算等。計劃部門需要各部門的分析資料。計費部門需要提供本月的賬革統計資料、話單統計資料分布（比如分別按照基站分布、時段分布以及按使用者類別分布）、預交款統計資料、當前的欠費總額分布、催繳情況等等。這些部門時常為了資料而產生了大量無謂的爭議。在使用Play CASE工具時，先要將這些部門錄入到Play CASE的“業務部門”中．構成了一個資訊源的接收點（或發送點）；而Play CASE通過圖示表示了這些部門的關係，並轉換成了相應的軟體結構。實際上，這是一種系統建模的方法，即把業務系統中的各個組織轉變為軟體功能中的各個結構。這樣，在需求分析階段，明確哪些部門需要資料，從而保證了需求分析對整個公司的全面性，而不會忽略掉某一個部門，導致需求分析的不完整。
    第二步，瞭解各個業務部門中的商務程序，使之通過Play CASE轉換成軟體的運行過程，這是一種動態建模的方法。在上一步的基礎上，追蹤各個部門的行為，錄入到Play CASE中，並以形式化的語言描述各過程。對於複雜的過程，該工具還提供了進一步細化的方法，並且形成了商務程序圖和業務狀態圖。根據這些流程圖、狀態圖與實際業務部門的業務相結合比較，還是較為吻合的。在此步的實施過程中，運用了動態建模技術，使各部門商務程序的情況在軟體的運行過程反映出來，從而保證了需求分析階段中運行過程的描述能真實地反映實際情況，防止在後繼的程式編寫過程中，可能會經常發生的一類情況：程式員因為沒有理解商務程序而出現“閉門造車”的現象，從軟體的功能角度上保證了軟體的正確性。
    第三步，將業務資料轉變為軟體資料，這一步工作實際上就是收集各部門所需要的資料。分析各部門需要的資料都有哪些；以及資料是如何轉換的，這可以歸入“功能建模”的範疇。將這些相應資料錄入到Play CASE中，選定所屬的部門。這時就自動地建立了DFD圖（資料流程圖），資料字典，省去了人工建立時的很大麻煩。
    第四步，將業務上的資料關係轉變成軟體中的資料關係。這裡採用了物件導向的方法，把業務部門所需要的資料看作一個實體，部門間的資料關係就是實體之間的關係。比如：經營部門所需要的使用者資料、使用者話費，實際上就是使用者這一實體與賬單這一實體間的關係。Play CASE提供了構件（不過我覺得是組件更為合適一些），來表示對應的資料，並提供了三種構件的表示關係即組裝關係、分類別關係與相連關係。這三類別關係基本上反映出了現實世界中的業務資料之間的關係。例如現實世界中的使用者資料與使用者話費，在Play CASE中，可將使用者構件與賬單構件用相連關係表示。這種方法，實際上是借鑒了OOA物件導向的分析方法中的類、聚集、繼承、封裝等概念，能較好地反映出現實中的業務；同時，這一步的工作也為總體設計中資料庫的概念模式設計奠定了很好的基礎。
    經曆了上述四個步驟以後，利用Play CASE工具自動產生了軟體需求規格說明書、初步的DFD圖和商務程序圖，為下一步的總體設計打好了基礎。
    使用Play CASE工具，使需求分析既能繼承傳統的結構化分析方法，又能吸收物件導向設計方法的優點。比如能把商務程序轉變成為運行過程，業務組織轉變成了軟體的結構等都體現了這一點。而在運行過程中，對複雜過程的細分以及追蹤則反映了傳統方法中的自上到下分解的分析思想，這對於解決複雜系統的分析是很有協助的。
    通過使用，我覺得這個工具還是很不錯的。因為它實際將以下四個方面的問題結合起來了：軟體、業務、開發人員和使用者。對於使用者而言，Play CASE用圖形化的方式顯示出商務程序，使使用者瞭解業務在軟體中的運行過程，提供了將來驗收軟體時的依據。對於開發人員來說，使開發人員能更清楚地瞭解商務程序，不會再發生“因為不理解使用者的需求而出現的閉門造車情況，從而導致開發出來的產品不符合使用者需要”的現象。因此，Play CASE所自動提供的需求說明書能夠很好地溝通使用者與開發人員之間的理解，使他們都能對需求有共同的理解。
    使用Play CASE工具後，使我們的需求分析取得了很好的效果，不但能自動地提供許多結果，如需求說明書等；還使需求的品質有了很大的提高，受到領導的讚揚（領導不是學電腦的，但對公司的業務十分熟悉）；在後繼的設計與維護工作中，我們感到工作似乎輕鬆了很多。
    當然，該軟體工具也有不足之處，一個突出問題是靈活性不夠，一縣公司的部門或者組織機構發生變化時，整個設計都要重新來過。因此，在改進的過程中，我們在第一步過程預留了好多個虛擬部門，以備將來進一步的擴充或者變動。
評註：（1）具體項目有些體會，完成情況似乎不錯。（2）條理較清晰，比較系統地描述了使用Play CASE的過程和體會。（3）偏重於工具的討論，對需求分析的方法分析還嫌不夠。（4）項目相對較小，僅涉及報表系統，對更為複雜的商務程序應舉例分析，才能更充分地體現方法與工具的作用。（本文主要參考了廣東魏福建等人的論文）