淺析農村信用社信息系統軟件開發的需求管理

摘要：隨著農村信用社金融電子化建設的深入發展，各項金融軟件產品越來越多，軟件開發規模越來越大，如何提高軟件開發的效率和質量已成為金融軟件開發的核心問題。需求管理是關系到金融軟件產品質量的關鍵，對信用社業務發展具有深遠影響，軟件需求質量的好壞直接關系軟件產品的開發質量和生命力。而需求管理對農村信用社來說，處于邊實踐邊探索階段，只有最佳的需求管理，才會有最好的研發產品，需要在今后工作中認真總結和不斷完善。

關鍵詞：信用社 信息系統 軟件開發 需求管理

一、軟件開發需求管理的內涵及特點

在信息系統項目管理所提及的軟件生命周期中，需求分析是最基礎、最重要的一個階段。軟件需求分析的質量對軟件開發的影響是深遠的、全局性的。需求管理是調度、協調需求工程活動，如獲取、分析、規約及驗證，并編制文檔的整體過程。需求管理具有以下特點：

（一）、需要業務部門和技術部門的雙重確認。由于需求本身是通過業務語言來描述技術需要實現的功能，因此需求管理和以往按職責、按專業進行的管理有本質區別，需求管理需要最大限度地融合了業務部門、技術部門的認識和見解，對需求的理解和認可需要獲得業務部門、技術部門的雙方確認，既要符合或滿足業務需求，又要充分考慮技術實現的可行性和建設成本。

（二）、需求管理的延伸性。需求管理是隨著需求階段的不同而動態變化的過程，且該過程并不因系統應用而結束，反而會因用戶使用中希望功能得到擴展優化，而又延伸出新的需求，從而進入同樣的需求過程，不斷循環往復。

（三）、需求管理的派生性。需求只是項目開發的起因，為什么有需求，需求如何實現，實現過程中是否會產生其他需求則需要進行認真的分析，真正做到對癥下藥，在設計開發中不斷進行改進.“需求派生需求”正是強調了貫穿項目開發始終的需求管理。

二、需求管理的重要意義

金融電子化建設的核心是軟件的開發和使用，而最終目的是使用，它是信用社電子化建設的重中之重，目前農村信用社使用的軟件多為自身軟件開發部門單獨或與外部機構合作開發，只有少量系統軟件是直接購買的商業軟件產品。不論哪種情況，對需求管理都是最為重要的內容。需求是項目開發的根源，而需求管理則是業務、技術人員對需求內容達成共識并最終實現共同目標和結果的重要保障。因此，需求管理是關系到系統開發、應用成敗的關鍵過程之一。如果一個產品滿足了客戶需求，那它無疑就是成功的。需求管理的過程，從需求分析開始貫穿整個項目始終，力圖實現最終產品需求的最佳結合，因此，有效的需求管理工作是項目建設的根本。

三、需求管理的一般過程

軟件的開發過程是由業務管理等應用部門根據業務發展的需要提出開發需求，軟件開發部門根據需求進行研發，最終由應用部門進行驗收并投入使用，大體過程如下：

（一）、業務管理等應用部門根據業務需要提交《業務需求書》。

（二）、軟件開發部門同應用部門的相關人員一起對《業務需求書》進行分析討論，并以某種模型(如數據流圖)表示出來，形成《軟件需求規格說明書》。

（三）、由開發和業務需求部門的主管領導代表本部門對《軟件需求規格說明書》簽字確認。開發部門依據《軟件需求規格說明書》開發相應的業務處理系統并提交給應用部門。

（四）、開發部門根據應用部門后續提交的業務需求變更，及時進行分析。分析結果經雙方認可并簽字后作為原《軟件需求規格說明書》的附件，并由開發人員對軟件進行調整。

（五）、應用部門對軟件產品進行驗收，合格后投入使用。

過程（一）是需求獲取，過程（二）實際上是將需求分析、需求規約、需求驗證結合在一起進行。《業務需求書》相當于應用部門給開發部門提交的一份任務書，不能作為最終的開發依據。原因在于：《業務需求書》是對業務處理的描述，其內容經常是模糊的、不準確的，很多細節往往沒有給出，特別是一些經驗性的、常識性的要求常常被忽略，性能上的要求有時也無法實現。《軟件需求規格說明書》是雙方人員共同對《業務需求書》進行深入理解、詳細分析并完善之后，采用形式化的模型描述的，其中增加了《業務需求書》中缺乏的細節，排除了《業務需求書》中錯誤的、模糊的內容，合理安排《業務需求書》的各項性能指標，以完整清晰的方式對要開發的業務處理系統進行全面描述，是開發的最終依據。在整個過程中，應用部門和開發部門作為互相配合的雙方，各有不同的分工。雙方的密切配合和良好交流是產生高質量業務需求、獲得優秀軟件產品的重要保證。

四、需求管理的容易出現的問題及對策

（一）來自應用部門的問題

1、無足夠的管理人員、業務人員參與，將導致開發的系統無法被接受。在需求的論證、編寫、評審、驗收等階段，如果沒有相關管理人員、業務人員的參與，技術人員只是根據個人理解確定業務需求，那么開發出的系統可能與實際業務需求有較大偏差。所以項目建設初期應讓具有代表性的各個層次的管理人員和業務人員直接參與到開發隊伍中，作為項目組成員參與整個開發過程。

2、需求不明確。在需求描述中，應用部門使用的往往是業務語言，經常根據撰寫人對業務處理的理解，用日常說法加以描述。這種描述常常省略了一些經驗性、常識性的內容，相關的背景內容（如法律、法規等外部約束）也大都不加說明，缺乏計算機處理所需要的很多細節。業務人員可以處理，但計算機卻無法處理，這樣的需求是不明確的。技術人員也常常由于無法準確理解這些業務做法和要求，導致對需求產生理解上的歧義，給開發造成失誤。另外，應用部門有時對所要的處理系統只能提出一個籠統的需求，具體包括哪些業務處理功能自己也說不清楚，這樣的需求根本無法實現。因此，應對提出的需求申請進行充分、全面的論證和評估，才能保證業務功能實現的合規、合法和技術實現的可行性，為項目實施決策奠定堅實的基礎。

3、業務需求編寫不清晰，將導致項目實施時間的浪費。在需求編寫階段，如果編寫的業務需求不清晰，而造成需求模棱兩可，將導致一系列嚴重后果：諸多項目成員對業務需求產生不同的理解；不同級別、不同層次的人員產生不同的期望；技術人員為錯誤問題而浪費時間；測試人員與開發人員所期望的不一致，以致不得不重寫許多測試用例并重做許多測試。因此，編寫需求時必須明確，具體內容描述必須完整、清晰、準確。

4、需求缺乏遠見：這是需求管理中另一個常見的問題。一般包括兩個方面：一是應用部門對自己的業務缺乏研究，不了解該業務當前的發展狀況和發展趨勢以及宏觀經濟形勢的變化，甚至也不了解下屬使用部門的各種業務變化和業務擴展，因而提出的需求缺乏前瞻性和通用性，甚至有些根本就是錯誤的做法，只能在很短的時期內滿足使用，常常是開發部門還在按照《軟件需求規格說明書》開發時，就不斷有新的需求變更提交過來。有時產品使用不久就要大動手術。導致開發部門無法按照既定的進度工作，經常調整程序甚至返工，嚴重影響進度，加大了開發人員的工作壓力，也影響了產品質量。二是應用部門對關聯業務的變化缺乏了解，因而關聯業務的變化導致業務需求不斷變化。這主要是由于同相關部門缺乏必要的交流造成的。以上兩種情況還產生另外一個問題：應用部門提出的多個業務需求缺乏綜合考慮，各自為戰，據此開發的各個應用系統彼此缺乏關聯，導致業務處理系統數量繁多，缺乏綜合性。這在業務系統整合時弊病暴露無遺。因此，要把需求變更范圍控制到最小，嚴格對每種變更進行影響因素分析，并按規定程序充分論證，審批后再進行變更，并保證業務需求書版本及時更新。在項目組中明確專門的需求管理人員，負責整個項目需求管理，確保發生需求變更時，受到影響的內容能即時修改，與需求變更保持一致。

5、需求驗收不全面、不細致，將導致系統項目失敗。在業務需求驗收、測試階段，如果未嚴格按需求說明書進行驗收或驗收內容不全面、不細致，將導致系統項目的失敗。因此，應嚴格按業務需求書設計測試方案、測試案例、測試用例。實踐證明，在開發人員完成程序編碼后，才開始著手測試方案、測試案例的編寫啟動時間太晚、效果不佳，原因是測試人員介入項目時間太晚，對測試項目業務實現的流程和功能不甚了解，錯過了發現架構設計和業務邏輯設計 中存在問題的最好時機，到系統完成時修復這些缺陷將很不方便，缺陷已經擴散到項目各個子系統中去了，錯誤將很難尋找和修復，增加了項目開發的難度和成本。正確的做法是，測試人員應在業務需求分析階段介入，參與業務需求分析，依據定稿的業務需求書編寫測試方案、設計測試案例，然后再通過測試審查驗證業務需求是否能夠實現，是否達到業務部門的要求。

（二）來自開發部門的問題

1、開發人員對需求理解不準確：這是一個常見問題。經過需求分析之后產生的《軟件需求規格說明書》是軟件產品開發的依據，也是應用部門最后驗收的依據。原則上說，《軟件需求規格說明書》是開發者和用戶之間的一份事實上的技術合同。然而，由于以下幾方面的原因，開發人員對《軟件需求規格說明書》理解不準確，使得軟件開發過程中和交付使用之后不斷出現用戶不期望出現的問題，軟件產品不能準確地按用戶的期望工作。這就要求開發人員要深刻理解《軟件需求規格說明書》，特別是其中的一些業務處理方法和處理原則，要了解涉及到的有關政策規定等背景。另外要減少開發部門人員變動，后加入的人員由于時間緊和知識背景的限制，有時無論是對需求的整體還是對需求的各部分之間的有機聯系都缺乏清楚深入的理解，因此不能準確地實現業務需求。還有開發人員要了解具體業務的流程，以避免在開發過程中按自己的理解去做，導致出現偏差。

2、開發人員不嚴格按需求開發，自以為是：開發部門是服務和技術支持部門，金融軟件產品的開發必須符合用戶的需要，而不能以自己對系統的理解代替用戶的要求。分不清自己的職責，按自己的理解而不是業務上的理解去做，是缺乏服務意識的表現。業務人員和技術人員由于知識背景各異，長期受到的訓練不同，有很多差別。這些差別表現在：由于金融業務處理本身比較簡單，業務人員在描述問題時常常根據當前的實際做法簡略描述，許多細節被忽略，一些常識性的、經驗性的知識隱含于其中。事實上，業務人員在日常處理上也正是這樣做的，處理起來很靈活。技術人員處理問題則往往很“較真”，必須把每一個細節都清楚無誤地描述出來，在實際開發中，個別開發人員可能對業務需求中的一些提法和做法不愿接受，覺得從技術角度看，換一種處理方式可能更合理、更簡單。因此，有時個別開發人員可能會在某些處理中按自己的“更為合理”的理解去做。為避免此類問題的出現，就要求開發技術人員樹立真正的服務觀念，加強對業務人員的尊重和理解，加強同業務人員的深入交流。開發出符合業務需求，符合客戶實際需要軟件產品。

3、缺乏稽核部門的介入。農村信用社電子化建設中一個普遍的問題就是缺乏稽核人員的參與，直到目前也仍然存在。往往是系統已經投產使用了，稽核部門才知道有這么一個系統，對系統的整體了解、功能實現、安全機制、內控原則、具體操作的了解都非常滯后，因而對系統的一些安全點、隱患、漏洞也就難以發現，更不用說提出對系統改進的合理化建議了。稽核應從軟件需求開始就全程介入整個軟件開發過程，包括系統驗收、投產和后續管理。

軟件開發的需求管理是關系到金融軟件產品質量的關鍵，對業務發展具有深遠影響。它是整個開發項目中最重要的工作，需要應用部門和開發部門密切配合，并按需求工程的要求和開發工作的規律進行。良好的需求管理會減少開發工作中不必要的調整，保證開發工作的順利進行和最終投入使用，從而降低開發成本。

（作者單位：山東省農村信用社聯合社臨沂辦事處）