系統分析員論文1
企業人事信息系統的應用
【摘要】
本文討論《企業人事信息系統》項目的需求分析方法與工具的選用。該系統的建設目標是幫助該企業管理好企業內部的人員和人員的活動，人事信息管理指的是企業員工從招聘面試到離職退休的全過程，涉及的主要活動包括面試、報到、培訓、升職、離職或其他的人事變動，也包括電子化考勤、工資性收入的計算與分發、使用其他公司資源的有關記錄（如宿舍、保險、證件辦理等等）。此外，本系統也涉及到企業在全國各地的人事信息管理，企業的組織架構的設置，級別與職務管理，人力申請直至人力需求報表，從而形成一個對企業真正有用的人事信息管理應用系統。在本文中首先討論了選用面向對象方法與工具的主要理由與策略，進一步通過一個簡例說明該方法與工具使用的效果，也討論了使用多種工具與方法在需求分析中的必要性，最后簡要小結了選用正確工具與方法的意義和作用。
在項目開展期間，我擔任了系統分析、系統設計與數據庫管理等大量工作。
【正文】
人事信息管理系統是一個有著廣泛應用面的實用性系統，但是，我國各個企業有著自身的體制、機制、特點與不同的要求；在開發這類系統時，系統需求分析是極為重要的一環。在整個分析過程中，我們都采用了面向對象的分析方法，這是因為我們在近幾年的實踐中已堅信這種方法能夠更加有效地表達和描述現實世界。軟件要具有適用性和擴展性，就必須更接近于現實世界本身的發展規律。
以一個簡單的例子來看，假設要求設計關于引進人才評估的一個系統，按我們過去的做法，先會要求提供給我們一份相關的引進人才評估表，然后依葫蘆畫瓢地設計相應的表單與界面。在短期來說，這樣做是簡便而實用的，但并不能夠符合現實世界的長遠目標，這套設計方法不具有擴展性，因為任何一份評估表的結構都會有可能發生許多改變的。采用面向對象的方法，可以從中提取出表類型、表結構、評分方法以及能考慮繼承等各方面的要素，這樣就可以保證軟件的通用性，可配置性與可維護性。
在工具的選擇過程中，我們選擇了現在已十分流行的Rational系列，包括Rational Rose、RUP、SoDA等，為什么選取這個系列工具呢？這是基于我們對軟件需求分析目標的看法，我們認為需求分析應當能正確地回答如下的幾個關鍵性問題：
（1）用戶的需求是否已詳盡地被考慮到了？
（2）用戶能理解或明白我們所描述的內容嗎？
（3）分析是否會和設計相脫節，
（4）程序員能明白我們的分析與設計要求嗎？等等。
以下對上述幾個問題逐一簡要地加以說明：
�。�1）詳盡地獲取用戶的需求。
用戶的需求可分為顯式的需求與隱性的需求，用戶的傾向往往只顧及到當前的與明顯的需求。要達到對需求理解的全面性，不僅僅只是依靠有效的用戶談話和調查，因為我們所面對的用戶需求往往會有些片面的，采用Rational Rose（基于UML）提供的用例，以及多種圖的聯合使用，可以使我們發現其中的遺漏。
�。�2）使用戶能充分地理解我們的表示方法，能夠真正明白我們描述的內容。
軟件需求分析規格說明書通常會是冗長而枯燥的，一般的用戶不容易深入理解，這樣就削弱了分析的正確性。通過支持面向對象及UML語言的Rational Rose可以更好地和用戶交流，讓用戶了解系統的運作方式甚至細節的操作。
�。�3）使分析和設計兩個階段互相聯系與貫通。
這是我們選擇面向對象的方法及Rational Rose工具的重要原因，系統分析要向用戶描述的不僅僅是用戶的需求，而且包括解決方法，解決方法當然應包括設計（程序）、數據庫與系統配置，我們當然不希望用戶得到的是一個與需求規格說明不相同的軟件，也不可能要求程序員完成一個不可勝任的任務。然而我們在以前的多項工作中經常發現這類情節，因為系統分析與設計相互脫節，導致一頭扎在分析中不顧設計有關的事宜。
分析與設計的脫節，還不利于設計現格說明的評估，因為分析往往會脫離現實，導致缺乏評估的依據。
因為不可能成功地完成設計而使分析需要重來，就會造成巨大的浪費與損失。一個好的工具可以使分析與設計更緊密地連結起來，甚至于—一對應。面向對象的分析方法使對象之間相對而言有獨立性，減少了任何影響到全局的改動，能避免因需求變化而導致全盤皆動的被動局面。
�。�4）使程序員明白我們的設計。
一個好的設計應該讓程序員感到清晰明白，更少疑問。一個疑問很多的設計加上溝通不暢，絕對會出現在應用環境下所不需要的另一個軟件，所以設計規格說明書務必清楚、形象與明確，當然，Rational Rose具有足夠的圖形與其他形式，能使程序員更加明確，甚至能細微到每一個語句（事實上如果使用VB，程序架構都有可能直接生成了）。
�。�5）選擇UML可能會有更多的理由。
比如用戶文檔的編寫、數據庫設計，我們都需要做到有延續性，有自動化支持和具有質量上的保證。所以，我們選用了以上的方法和工具。
在分析中，面對考勤班次的問題時，由于過去一直使用紙卡方式考勤，使用戶對班次形成了固定的概念，而現在的許多考勤軟件也采用多次刷卡的方法來形成一天的記錄。經過面向對象的分析可以發現，事實上每天的上班記錄是由多個時段所形成的，時段的多少在各個公司，各個工種與部門都不盡相同，每個時段可能有不同的屬性，時段與時段組合可形成為班次，這更適合于現實的情況，使之能更加靈活與更有擴展性。其實，在天與天之間也都有相互之間的關系。在這一點上，我們又發現必須在考勤與薪金工資中加入與MRP中相似的期段（Periods）的基本概念，比如可以稱之為考勤期段，允許為用戶更加方便地設置考勤期段，可能使之不一定與自然年月日相同等等。
Rational Rose使我們更方便地把上面的想法在類上去實現，更進一步地設計好我們的高效率的數據庫。
當然，使用單一的一個工具去完成一個中大型的應用系統的需求分析，是不可能成功的。因為社會在發展，用戶的需求也在改變，如何把握住用戶的需求是需要時間的，面向對象的方法有時也會忽略外在的與表層的要求，不僅僅是要獲得關鍵的需求，其他更多的需求往往要等到用戶在使用后才知道，然而等到用戶使用是不現實的，作為原型開發模型中的原型也是收集用戶需求，描述與解釋需求的一類相當有效的方法與工具。
在我們的開發過程中，為了更好地讓用戶了解我們的系統和我們的設計方案，讓用戶在見面會上更有方向性與針對性，我們首先用Access開發出原型，讓用戶先試用。這樣，我們在真正的分析與設計時就能更加符合用戶的要求。
總之，軟件需求分析方法和工具的使用，對我們軟件開發過程影響是很深遠的，選用高效能的正確的方法與工具，可以使我們的軟件更加正確地反映現實需求，更加具有可用性、可擴展性和可維護性；降低了軟件項目的風險。
評注：（1）寫得有些特色，觀點鮮明。（2）摘要寫得不錯，既反映了項目內容，也小結了本文的寫作要點。（3）文中所舉的例子雖然簡單，但很實際。（4）多種方法與工具的使用，敘述得簡明扼要。（5）內容可更豐富一些，更深入的例子也可再增多一些，則會更有說服力。（6）對需求分析的全過程的描述太少。（本文主要參考了廣東延國慶等人的論文）
系統分析員論文2
企業集團的信息管理系統應用
【摘要】
本文以某個IT產品銷售公司的信息系統項目的開發為背景，討論了一個信息系統需求分析的整個過程，其重要特征是：所涉及的項目是原有系統的一個升級替換版本。因此，需求分析過程不同于建立一個全新的系統，大體上可分為三個階段：（）實施逆向工程獲得對系統的初步了解；（2）在第1步的基礎上寫出基本需求，交由客戶評審補充；（3）在第2步的基礎上開發原型，利用原型與客戶交流，最終獲得基線需求。針對上述三個階段，本文論述了所使用的分析方法與工具以及所遇到過的一些典型問題和措施，最后對需求分析中使用的工具，談一些自己的初步體會。
【正文】
我于1998年8月至2000年7月參加了某個大型集團的企業信息系統的開發工作，該大型集團的業務主要涉及到IT類產品的進銷存。本人在項目中負責系統分析的工作，該集團企業原先已委托某個電腦公司開發過一套IT類產品管理系統，但是該老系統存在兩個主要的問題：（一）系統運行速度非常慢，如商品銷售開單時，從確定開單到開單完成有時需要1～2分鐘左右的響應時間，讓客戶無法忍受。（二）系統數據不準確，經常出現實物庫存與電腦庫存嚴重不相匹配的情況，使銷售數據的統計產生一些混亂，有關財務的數據因此無法有效使用，只能采用人工錄入方式補充進行。在這種情況下，該集團的總經理決定參考原有系統重新開發一個系統，以便解決原系統所存在的上述兩個難以克服的難題。注；原系統采用PB6.5開發，數據庫采用SYBASE，服務器采用Windows2000Server，客戶端采用Windows 98，程序架構采用的是傳統的C/S結構。
鑒于該集團業務操作復雜，流程多，涉及人員多等特點，以及項目完成時間短，經費有限，人員有限等限制約束條件，再考慮到必須避免前一系統出現過的結構混亂與難于維護等問題，我們決定要對原系統的需求做一個比較徹底的和切實可行的分析，由于原有系統已經開發了近兩年，并且客戶也有了一定的使用經驗，業務基本流程本身也并沒有太大的變化，因此，我們把需求分析的過程分為三步：（）分析原有系統的結構，主要是數據庫結構和程序結構，（2）在獲得第（1）步結果的基礎上寫出基本需求，交由客戶評審補充，（3）在第（2）步的基礎上開發原型，利用此原型與客戶交流，從而獲得最終可用的需求結果。下面按上述三步分別加以論述。
第一步是實施逆向工程，獲取原有系統的基本需求。
由于原有系統在功能上大體上能基本滿足客戶的需求，并且在兩年多的開發中也積累了不少經驗，因此，從中可以獲得一些有益的參考，也可以避免多走彎路。在這一階段，我們采用的主要工具是PB自帶的Power Designer和PB Documents；前者主要用來分析數據庫結構，后者主要用來分析程序結構，便于開發人員與高級用戶理解程序。采用這兩個工具的原因是：原系統過于龐大，模塊多，數據庫模式多，表格量很大，僅靠人工的方法很難從中獲得一個比較完整的、明確的系統結構以及整體構成，而且原有系統未能提供一套正確完整有效的設計文檔，于是我們只能依靠工具輔助來進行。在使用Power Designer分析數據庫，并且用PB Documents分析原程序中的PBL以后，我們對原系統的結構有了一個初步的了解，再結合對原系統的使用，基本明確了功能與流程的需求，并在此基礎上用人工錄入方式，產生了初步需求的自然語言文檔。這里指出，使用Power Designer的一個不足之處是：如果一個表中的字段過多，而且又同時依賴多個表時，輸出的表格相關圖形很復雜，有很多交叉，且難于調整，不方便閱讀及打印。
第二步是在第一步的基礎上進行的，即寫出系統基本需求，交由客戶評審和補充。
通過第一步的逆向工程，我們獲得了系統的基本需求。為了充分記錄需求的變化及需求之間的依賴關系，我們決定選用Rational公司的Requisite PRO作為我們的需求管理工具，Rational公司有一整套用于需求管理的工具，功能非常強大，包括Requisite Pro、Clear Quest等等，這些需求分析工具可以對需求進行全面的管理，包括記錄需求的變化情況，需求之間的依賴關系等等。但是，我們考慮到Rational的一套工具全面實施會非常昂貴與復雜，需要非常強的項目管理能力才能全面實施，因此，我們只采用了其中最簡單的一部分功能，那就是記錄需求變更，記錄需求之間的依賴關系，其他跟RUP有關的功能都給略去了。之所以這樣做，主要是考慮到項目的經費、人力以及國內軟件開發的實際情況。正如前面所說，我們根據自己的理解并寫出基本需求后，交由客戶做評審井做適當補充，我們將經過補充整理后的需求作為正式需求記錄入Requisite Pro所維護的數據庫中，并對各個需求進行分類，設定優先級等，這些工作完成后，就可以從數據庫中直觀地了解客戶到現在為止提出了哪些需求，哪些需求是必須優先考慮的，哪些是難度較大的等等。在這個過程中，我們遇到了一些問題，譬如：用戶對我們用自然語言書寫的需求文檔有許多地方不理解，往往在花了較長時間閱讀之后，仍不明白我們所描寫的需求過程與他們所完成的業務之間的對應關系；另外是由于首次采用Requisite Pro進行需求管理，在類型劃分，屬性值的確定上，部分開發人員沒有經驗，造成了不少反復，對于前者，我們的方法是想辦法增加一些示意圖，將大的流程分解為小流程，再與客戶反復交流與溝通，最終達到雙方理解一致的目的。對第二個問題，則參考了一些例子，再結合實際中屬性的使用情況，給予取舍或者選擇，經過這一階段的工作，我們建立了基本的需求庫，定出了基本需求規格說明。
第三步則是在第二步的基礎上建立起原型，利用原型與客戶進行更深入的交流，通過交流修改相應的需求。
在這一階段的工作是在對第二步任務進行報告交流的基礎上進行的。我們用PB開發了一個原型系統，就具體的業務流程與客戶進行交流與溝通，通過原型，客戶發現了許多我們與他們的理解相互不協調的地方，我們在修改需求的同時，也在Requisite Pro需求數據庫中記錄下修改的歷史。事實證明，這種記錄歷史的作用是很有效的，如曾經有客戶在兩個不同的時間對同一需求提了相反的需求，我們根據歷史記錄很快證實了該客戶的提法有錯誤，在事實面前無需再作爭論，同時利用Requisite Pro，我們還發現了一些需求相互之間有矛盾。經過這一階段工作，我們終于獲得了經過用戶認可的需求基線，即是可用于下一步進行詳細設計的基線需求。
在這個項目中，我們利用了Power Designer、PB Documents等逆向工程分析工具和Requisite Pro需求管理工具，這些工具的使用，使我們提高了工作效率，起到了一定的輔助作用。但是，就需求分析工具方面而言。我們覺得國內應用得還是太少了，這一方面是因為對需求分析不夠重視，另一方面是因為管理水平還達不到相應的層次。Rational公司的一整套需求分析工具，其功能是非常強大的，國外已在普遍地使用，在國內也逐漸開始普及，特別是那些通過CMM二級以上評審的單位，都必須使用工具對需求進行管理。在本項目中，我們僅僅利用了Requisite Pro功能的一些小方面，已經體會到該工具對于項目管理的諸多好處。如果一個有實力的公司能夠全面實施RUP，那么需求管理這個老大難的問題會變得不再那么棘手了，項目的質量也會得到相應的提高。目前國內由于CMM熱潮的興起，已經逐漸重視需求分析，也逐漸使用需求分析工具，這是非�？上驳�，當然，更希望在不久的將來，能用上國產的需求分析工具，那時我們的軟件產業也許會真正地騰飛了。
評注；采用逆向工具進行再工程的應用很多，本文給出了一個實際的例子。寫作有條理，也很實際。合理地界定了需求分析的現實水平。所采用的需求分析的方法與工具相對較合理科學。能在對項目討論的同時抒發議論、使用體會、愛國心和事業心。深度還可以提高，例子宜更加豐富一些。（本文主要參考了廣東劉小波等人的論文）
系統分析員論文3
論軟件需求分析方法和工具的選用——論文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）項目相對較小，僅涉及報表系統，對更為復雜的業務流程應舉例分析，才能更充分地體現方法與工具的作用。（本文主要參考了廣東魏福建等人的論文）
系統分析員論文4
論軟件需求分析方法和工具的選用——論文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）最好再列舉更多的項目或例子，使方法與工具的討論更全面一些。（本文主要參考了上海解亮等人的論文）
文章來源于領測軟件測試網 http://www.kjueaiud.com/
