計算機軟件項目管理中的需求分析

王海濤 馬秀紅

摘要:計算機軟件項目的需求分析是項目開發的一個重要階段，需求分析做的好壞直接關系到系統設計的工作質量，甚至影響到項目的成敗。為此，軟件項目的需求分析必須規范執行其流程，熟悉項目用戶與開發人全貌及項目需求確認和需求評審等，只有這樣才能保證軟件開發的順利完成。

關鍵詞:需求分析；項目干系人；系統分析員

中圖分類號：F270 文獻標識碼：A 文章編號：1003-3890（2012）05-0056-03

需求分析是軟件開發過程的核心，其結果直接影響到整個的軟件開發過程。據相關資料顯示，因需求分析因素所造成的軟件項目失敗或缺陷約占60%，屬于系統實施階段的代碼錯誤，而導致軟件項目失敗的比率約為40%。項目失敗的根源在于需求分析不明確，需求調研不徹底，從而引發需求不斷變更，最終導致項目停滯。這些變更不僅加大了開發成本、項目無法按時完成等嚴重問題，而且，還有可能引發用戶方與開發方之間互相指責，導致項目擱淺。

一、軟件項目需求分析的重要性

軟件系統的開發主要分為五個階段，分別是系統的需求分析階段、系統設計階段、系統實施階段、系統測試階段和系統維護階段。而需求分析階段是整個五階段中的重中之重，在該階段所占的工作量大概是整個軟件開發項目的50%，邏輯方案是該階段的最終成果。邏輯方案不僅是進行系統設計的依據，而且，還是系統最終驗收的說明性文件。從以往的經驗來看，需求分析做的不徹底，沒有深層次的挖掘用戶需求，往往可能導致整個項目無法達到預期的效果，或者說設計開發出來的產品不能滿足用戶的需求。

需求分析首先要對現有系統有充分的認識和了解，在此基礎上，通過識別關鍵問題、分析項目的可行性、詳細調查研究、系統化分析，最終設計完成該項目的新系統邏輯方案。只有系統分析員明白了用戶的真正需求，才能開發出滿足用戶的軟件產品。在這里，要強調一點的是，在做需求分析的時候，開發方一定要指派有實際工作經驗的系統分析員來與用戶溝通，而不是指派具體的開發人員，這將避免一些溝通不暢的問題發生。系統分析員在了解用戶的基本需求之后，要以書面的形式，準確地制定出軟件需求報告。該報告主要說明系統的行為屬性，是項目開發過程中對系統的制約。要實現這一目標，就需要系統分析員與用戶之間做到緊密協作，甚至系統分析員要深入到用戶方的實際業務當中，把自己當做是用戶，從用戶的角度思考問題，只有這樣，開發方才可以真正了解用戶需要什么，系統應該做什么。

二、規范執行需求分析的流程

需求分析的過程，要嚴格執行規范化操作，囫圇吞棗式的需求調研是不可取的。開發方在做需求分析過程中，一定要嚴格把關，從對用戶負責的角度出發，并且也為了降低自己的開發成本，對無法與用戶實現很好溝通的項目經理要及時叫停，避免后續工作無法正常進行。

按照需求分析的過程，同樣也可將其分為五個階段：首先要獲取用戶需求，其次是分析用戶的需求，第三是編寫需求文檔，第四是評審需求文檔，最后是管理需求。規范執行需求分析的流程，是需求分析能否成功的關鍵。圖1是根據實際工作經驗總結出的需求分析工作流程：

在需求分析過程中，開發方要深入用戶方的各個部門，最簡單的項目也要做到用戶確認需求和需求評審兩個過程，復雜的項目甚至要做到多次。

三、盡快熟悉項目用戶方干系人全貌

項目干系人又稱為項目相關利益者，是指積極參與項目、或其利益會受到項目執行或完成情況影響的個人或組織，項目干系人對項目的目的和結果施加影響。項目管理團隊，即開發方，必須識別項目干系人，確定他們的需求和期望，盡最大可能地管理與需求相關的因素，以獲得項目的成功。因此，應當從項目的啟動開始，系統分析員用戶方相關人員的配合下，逐步分清項目用戶方干系人具體包含哪些人和部門，通過開方法與其溝通加之用戶方領導的協調以驅動他們對項目的支持，從而減小其對項目的阻力。

有些項目在做需求調研時，因受用戶方提出的進度要求等因素影響，有些系統分析員不愿與用戶過多地交流，只是發一些調研表做一些大概的了解。往往是因為開發方已有與該建設單位相似的原型，會亟不可待地去推廣，這樣會導致某些差異需求得不到深入了解，用戶方只能被動地去適應原型系統，這樣的做法是不可取的。另一種情況則是開發方與用戶方的技術部門交流比較多，而向業務部門和實際使用人員調查的力度不夠，往往容易造成原型試用后，與用戶的需求不一致，不得不再對需求做較大調整，造成開發周期不斷延期，開發成本大大增加。因此，熟悉項目用戶方干系人全貌是進行需求調研的第一步，也是需求調研的基礎。在定制的開發項目中，最重要的是要弄清楚用戶方中的組織結構關系、業務流程關系、數據流程關系。制定該項目的牽頭單位，在此基礎上，使用圖表的形式將這三種關系表現出來。

四、采取正確的方法獲取用戶需求

軟件開發項目的首要目標就是要發現用戶的需求。在對用戶進行需求調研過程中，使用的方式很多，初期調研可以采用會議的形式，后續的詳細調研以及需求確認，可以采用電話、郵件、小組討論等方式，模擬演示也是一種很有效的形式，用戶比較直觀，容易發現、提出問題，但每一次調研過程當中，都要做好筆錄，當與用戶交流完畢以后，要對交流的結果進行整理、分類，便于后續的分析活動。系統分析人員要對收集到需求做進一步的梳理和分析工作，在這個過程中，首先要對用戶提出的具體需求，包括可能該項目目前不涉及的需求，都要知道“為什么”，并且判斷用戶提出的需求是否合理，對于不合理的需求，開發方要給出不合理的理由和原因。其次，要集中精力，把關注點放在需求分析階段關注的目標上，即“做什么”，而不是“如何做”，第三就是要分析用戶提出的需求當中所衍生出的隱含需求，這一點往往容易忽略掉，這就需要系統分析員在與用戶交流當中，關注用戶的表情、眼神、用語，因為對隱含需求不加以考慮或考慮不充分，往往會引起永無止境的需求變更。

在需求調研中，還要把握要求相關業務人員與領導同時出席，這將避免用戶所提需求的不負責任性和隨意性，以及對需求的確認不夠積極等問題。項目開發方應掌握用戶干系人需求，用戶干系人也應具有一定的技術基礎，兩者缺一不可，只有這樣雙方溝通起來才比較容易達成一致。對某些需求，用戶可能無法想到，系統分析員要做到引導用戶的作用，并且要有足夠的耐心聆聽用戶的講述。

五、分析用戶需求并編寫需求調研報告

調研結束后，開發方要根據用戶的需求編寫需求調研報告，即提出新系統的邏輯方案。獲取用戶需求與分析用戶需求二者之間并不沖突，完全可以同時進行，關鍵問題是如何詳細地描述用戶的需求，常用的方式是通過建立相關的模型來操作。通過建立模型，抽象出用戶的需求，以一種可視化的方式與用戶進一步溝通。獲取用戶需求與分析需求二者之間有著類似的步驟，不同之處僅在于分析用戶需求時采用模型來描述。分析用戶需求所執行的活動如下：

1. 用業務流程圖描述系統的整體業務活動，包括系統之間的接口和邊界。

2. 用數據流程圖模型來描述系統的數據流關系。可以采用多層次的數據流程圖加以描述，對于復雜的數據流關系或功能處理模塊要配以數據字典。

3. 通過原型向用戶展示系統界面以及各項功能模塊，用戶可以拿自己的需求與其相比較，存優去劣。

4. 采用實體關系圖描述實體、屬性、關系三者之間的聯系。

在編寫需求說明書時，可以采用自然語言或結構化語言來加以描述，當然，可以將需求分析階段的各類圖表列入到需求調研報告中，需求文檔應該包括用戶的所有需求（包括功能性需求和非功能性需求），這便于在需求確認和需求評審階段，使用戶一目了然，容易理解。

六、項目的需求確認和需求評審

開發方要從兩個角度出發來描述系統，一是全面詳細地描述現行系統的缺陷和不足，以及業務流程存在的不合理之處。二是在業務流程重組的基礎上，提出新系統所優化的各項業務流程和系統所具有的優點。并將二者業務流程文檔化后與客戶進行探討，對于描述不準確不精確的地方要加以細化，對于錯誤的地方要進行修改，最終讓客戶進行確認。需求評審的目的就是對需求分析階段的成果做出評價，提出不足，進一步優化流程，糾偏、完善需求調研報告。需求確認與評審是不可逾越的兩個階段，有研究表明：由客戶發現的一個錯誤，然后更正錯誤，約需要多花90倍的時間，可以看出，需求確認和評審階段的重要性。

需求評審的關鍵在于邀請這方面的專家、用戶、領導對新系統進行評價。當然，在確認評審階段，開發使用雙方都要在場，開發方在講解需求報告時，要做到細致入微，不能放過任何一個功能模塊，使得雙方共同找出需求調研中不合理的、不完善的、有歧義的、遺漏的問題。需求評審的目的是要獲得用戶的認可，如果用戶用戶以種種理由不以確認，那么系統分析員要盡快拿出原型系統來給用戶確認，否則后續的工作將無法順利開展，并伴隨著無窮無盡的需求變更。

參考文獻：

[1]黃梯云.管理信息系統（第四版）[Ｍ].北京:高等教育出版社，2008.

[2]吳潔明.軟件工程應用實踐教程[M].北京：清華大學出版社，2003，（８）.

[3]趙池龍.實用軟件工程[M].北京:電子工業出版社，2006.

[4]徐鋒.軟件需求最佳實踐:SERU過程框架原理與應用[Ｍ].北京：電子工業出版社，2008.

責任編輯、校對：秦學詩