淺析需求分析在業(yè)務系統(tǒng)開發(fā)中的重要性

帥曉華

（長江職業(yè)學院，湖北 武漢 430000）

0 引言

功能完善的業(yè)務系統(tǒng)是實現(xiàn)業(yè)務辦理規(guī)范化、流程化、系統(tǒng)化的重要保障。業(yè)務系統(tǒng)功能是否完善，是否符合使用單位的業(yè)務流程以及操作習慣，將直接影響業(yè)務辦理的效率和辦理質(zhì)量。業(yè)務需求是使用單位對業(yè)務系統(tǒng)訴求的直接表現(xiàn)，是業(yè)務系統(tǒng)的核心，需求分析則是實現(xiàn)業(yè)務需求收集、整理、深入挖掘使用單位潛在需求，進行需求確認的過程，該過程為正確的開發(fā)業(yè)務系統(tǒng)奠定基礎[1]。

1 軟件生命周期概述

軟件的生命周期同其他事物一樣，都會經(jīng)歷醞釀、產(chǎn)生、成長、成熟、衰退的過程，根據(jù)各個過程的特點，軟件的生命周期主要分為以下幾個階段：

1.1 問題定義

問題定義就是確定好要解決什么問題，這些問題解決后要達到什么效果，會帶來多少經(jīng)濟效益，生產(chǎn)力能提高多少，出錯率可以降低到什么程度等。要確定解決什么問題，通常是通過對系統(tǒng)使用單位進行深入調(diào)研，通過多次的溝通和詳細訪談，需求分析師整理出關于問題的性質(zhì)、建設目標、預計使用范圍以及系統(tǒng)規(guī)模等內(nèi)容的書面報告，經(jīng)過討論和必要的修改之后得到客戶的確認。

1.2 可行性研究

可行性研究是指對系統(tǒng)使用單位要解決的問題，是否存在一套可以解決的方案、在該階段的任務不是具體的解決問題，而是研究問題的范圍。問題范圍可包括是否存在可以解決的方法，是否存在技術(shù)風險、時間風險、資金風險、運行環(huán)境風險以及人員風險等，如果存在這些問題，是否有穩(wěn)妥的解決方案。可行性研究的結(jié)果以可行性研究報告體現(xiàn)，可行性研究報告是業(yè)務系統(tǒng)使用單位決定是否進行該業(yè)務系統(tǒng)開發(fā)的重要依據(jù)。在可行性研究報告中，要對項目執(zhí)行過程中可能產(chǎn)生的問題和風險進行逐一論述，給出明確的處理辦法。

可行性研究報告包括技術(shù)可行性、資金可行性、時間可行性等方面。技術(shù)可性主要對技術(shù)是否可以實現(xiàn)進行詳細闡述；資金可行性主要是根據(jù)用戶預算情況以及資金情況進行可行性分析，該工作由用戶進行分析并給出分析結(jié)論；時間可行性主要是涉及用戶對業(yè)務系統(tǒng)的上線時間的預期，該工作由雙方共同進行分析并給出分析結(jié)論。只有可行性分析報告中的重要問題全部解決，才能進行后續(xù)工作。

1.3 需求分析

需求分析首先要收集需求，然后再對收集到的需求進行分析。收集需求主要是通過深入了解業(yè)務系統(tǒng)使用單位的訴求，在業(yè)務系統(tǒng)中要解決什么問題以及解決問題的方式方法等細節(jié)與業(yè)務系統(tǒng)使用單位達成完全一致；明確業(yè)務系統(tǒng)的建設目標、檢驗標準、業(yè)務系統(tǒng)必須實現(xiàn)哪些功能以及系統(tǒng)界面中要包含哪些數(shù)據(jù)元素等。分析需要主要是分析需求的合理性、完整性、冗余性、可擴展性、可合并性以及需求是否收集完整、是否還有遺漏、多個需求之間的強關聯(lián)性，通過多次與使用單位使用人員以及高層領導進行溝通，最終形成《需求規(guī)格說明書》，《需求規(guī)格說明書》需要得到使用單位的最終認可和確認[2]。

1.4 系統(tǒng)設計

系統(tǒng)設計以《需求規(guī)格說明書》為依據(jù)。按設計的詳細程度不同，系統(tǒng)設計又分為概要/總體設計和詳細設計。在實際工作過程中，根據(jù)業(yè)務系統(tǒng)的復雜程度決定是進行概要/總體設計還是詳細設計。

概要/總體設計是對系統(tǒng)整體功能、系統(tǒng)架構(gòu)、運行環(huán)境、網(wǎng)絡結(jié)構(gòu)以及系統(tǒng)實現(xiàn)方式進行粗略設計，不要求詳細到完整的功能界面和功能點的輸入輸出參數(shù)的定義和說明。概要/總體設計以《概要/總體設計說明書》的形式呈現(xiàn)。

系統(tǒng)詳細設計以《概要/總體設計說明書》或《需求規(guī)格說明書》為依據(jù)，對系統(tǒng)具體的功能實現(xiàn)方式、業(yè)務流程、頁面元素以及數(shù)據(jù)邏輯校驗規(guī)則進行詳細的闡述，同時詳細說明各項功能之間的邏輯關系，數(shù)據(jù)約束關系，數(shù)據(jù)庫表之間的關聯(lián)關系、各個數(shù)據(jù)表中字段名稱、字段類型、數(shù)據(jù)長度、是否為空，字段取值范圍的詳細規(guī)劃，各業(yè)務功能模塊使用到數(shù)據(jù)表說明等。詳細設計以《詳細設計說明書》的形式體現(xiàn)。

1.5 編碼和單元測試

編碼和單元測試以《詳細設計說明書》或《概要/總體設計說明書》為依據(jù)進行編碼和單元測試，最終形成系統(tǒng)源代碼和《單元測試報告》。在編碼過程中對功能需求有疑問時，需要查看原始需求、需求規(guī)格說明書以及與需求分析人員進行討論，甚至需要到客戶現(xiàn)場與具體使用人員進行溝通并確認。單元測試主要是測試功能模塊的完整性、健壯性、執(zhí)行結(jié)果的正確性以及與設計說明書中對功能描述的一致性，特定功能性能是否達到設計要求等多方面的測試。

1.6 綜合測試

綜合測試以《測試方案》、《需求規(guī)格說明書》、《概要/總體設計說明書》、《詳細設計說明書》為依據(jù)進行系統(tǒng)各項功能測試，測試內(nèi)容和范圍包括業(yè)務功能實現(xiàn)的正確性，數(shù)據(jù)邏輯正確性，業(yè)務功能實現(xiàn)與需求規(guī)格的一致性，業(yè)務模塊之間的耦合性、完整性以及業(yè)務功能實現(xiàn)是否有遺漏，系統(tǒng)并發(fā)處理能力以及業(yè)務響應速度等方面進行測試。綜合測試以《綜合測試報告》的形式體現(xiàn)。同時《綜合測試報告》的結(jié)果直接決定該業(yè)務系統(tǒng)是否具備上線試運行以及是否達到交付標準。

1.7 系統(tǒng)上線試運行

業(yè)務系統(tǒng)經(jīng)過綜合測試并達到上線標準后，進行客戶現(xiàn)場安裝部署，進入試運行期。試運行期間主要收集系統(tǒng)業(yè)務功能是否滿足日常業(yè)務辦理需要，系統(tǒng)運行是否穩(wěn)定、業(yè)務功能實現(xiàn)與實際工作流程是否一致等，根據(jù)收集結(jié)果定期對系統(tǒng)進行系統(tǒng)功能完善和系統(tǒng)性能調(diào)整，使系統(tǒng)逐步完善和穩(wěn)定。

1.8 系統(tǒng)維護

系統(tǒng)正式上線后，在業(yè)務系統(tǒng)功能滿足的條件下進行系統(tǒng)驗收，系統(tǒng)驗收后進入系統(tǒng)維護階段。在系統(tǒng)維護階段主要解決系統(tǒng)功能缺陷問題以及系統(tǒng)運行性能問題。

2 需求分析在業(yè)務系統(tǒng)開發(fā)中的重要性

通過對軟件生命周期的分析可以發(fā)現(xiàn)需求分析貫穿于軟件的整個生命周期，只是在項目前期階段需求分析的工作量比較大，在進入系統(tǒng)設計、編碼、測試、上線試運行以及維護階段，需要分析的工作量占比明顯減少。

通觀軟件生命周期，我們發(fā)現(xiàn)需求分析階段的工作是后期所有工作的基礎，如果在需要分析階段出現(xiàn)問題，可能導致項目嚴重延期、甚至造成系統(tǒng)功能完全不能滿足或完全錯誤的情況發(fā)生。

2.1 需求分析的正確性

需求分析需要專業(yè)的需求分析人員與業(yè)務系統(tǒng)使用人員進行充分溝通，認真聽取并記錄業(yè)務系統(tǒng)使用人員的全部訴求，用自然的、通俗易懂的語言對用戶需求進行完整的、原始的記錄，并將記錄給客戶確認，做到記錄與客戶描述一致，從而正確理解用戶的原始需求，形成原始需求。對客戶訴求是否能夠正確理解將直接關系到后期開發(fā)出來的業(yè)務功能是否是用戶最終所需，如果對客戶的原始需求理解錯誤將導致后期開發(fā)出來的功能不是用戶所需，甚至與用戶需求大相徑庭，可能導致某個業(yè)務功能開發(fā)返工、甚至造成為正確滿足用戶業(yè)務需求而進行系統(tǒng)基礎架構(gòu)重構(gòu)、造成人力成本增加、交付延期、客戶滿意度下降等不良后果。

2.2 需求分析的完整性

需求分析是否完整將直接影響業(yè)務功能、業(yè)務流程是否完整。如果在需求分析階段對用戶需求沒有記錄完整或沒有詢問完整，后期將導致部分業(yè)務功能缺失，給用戶使用造成極大不便，甚至導致部分或全部業(yè)務功能無法正常使用，從而不得不對已開發(fā)完畢的業(yè)務功能進行打補丁，這樣有可能造成已有業(yè)務系統(tǒng)的架構(gòu)混亂，甚至造成只有大量修改系統(tǒng)基礎架構(gòu)才能勉強滿足用戶真正的業(yè)務需求的情況出現(xiàn)，給系統(tǒng)的穩(wěn)定性埋下禍根，造成系統(tǒng)性能下降，甚至嚴重影響到開發(fā)測試人員的情緒，給項目團隊管理增加額外的負擔，給客戶造成不良影響。

2.3 潛在需求的挖掘

在實際工作中，大多數(shù)業(yè)務系統(tǒng)使用者是不專業(yè)的，他們提出的業(yè)務系統(tǒng)需求在通常情況下是不完整的，大多數(shù)只是提到在工作中經(jīng)常使用的業(yè)務功能，對于部分在工作中使用頻率不高但是又必須使用的功能往往會忽略，甚至會由于考慮不周而沒有提出來，對于這部分潛在需求，在進行需求分析時需要專業(yè)的需求分析師給用戶提出來，告訴用戶這些功能如果沒有將會給后期系統(tǒng)使用造成哪些不便，以便用戶進行選擇和確認是否需要這些功能。

這些潛在需求一般情況下是在業(yè)務系統(tǒng)開發(fā)完畢交付用戶正式使用后，用戶在實際的業(yè)務辦理過程中才會逐漸發(fā)現(xiàn)，這些潛在的需求對用戶順利使用系統(tǒng)可能會造成極大不便，甚至給用戶使用系統(tǒng)辦理業(yè)務增加不必要的工作量，導致用戶抵制使用系統(tǒng)的情緒產(chǎn)生，甚至影響到系統(tǒng)的正常驗收。

對于強勢的用戶可能會要求在本期項目建設中將這些潛在的功能全部實現(xiàn)，造成項目建設周期延長，人力成本增加；同時由于在項目前期完全沒有考慮這些潛在需求的存在，要實現(xiàn)這些潛在的需求可能會造成數(shù)據(jù)庫大量數(shù)據(jù)表的修改，通過大量程序代碼修改以及系統(tǒng)界面的調(diào)整用于滿足這些潛在需求，導致開發(fā)測試人員抵制情緒加深以及對需求分析師的不滿、產(chǎn)生內(nèi)部矛盾，使團隊的穩(wěn)定性受到影響。

由此可見，在需要分析階段對用戶潛在需求的深入挖掘和正確引導、可以減少系統(tǒng)功能的缺失和功能不完善的情況發(fā)生，將這些問題解決在系統(tǒng)設計和編碼之前，從而使系統(tǒng)功能更完整，系統(tǒng)運行更穩(wěn)定，最終用戶更滿意，開發(fā)團隊更和諧，系統(tǒng)交付進度更快速。

2.4 需求分析貫穿系統(tǒng)開發(fā)整個過程

需求分析貫穿于業(yè)務系統(tǒng)開發(fā)的整個過程，直至業(yè)務系統(tǒng)下線。只是在項目前期工作比較集中，在代碼開發(fā)、綜合測試、系統(tǒng)上線試運行以及業(yè)務系統(tǒng)維護階段需求分析工作比較少，但并不表明在這些階段需求分析的工作不存在。

3 正確的需求分析方法及注意事項

正確的、完整的需求分析，以及對潛在需求的深度挖掘是保證系統(tǒng)成功交付的重要條件。只有使用正確的需求分析方法才能保證需求分析的正確性、完整性以及對潛在需求的深度挖掘。

在進行需求調(diào)研前，需求分析師要先深入了解用戶業(yè)務特征、業(yè)務流程、業(yè)務涉及的政策法規(guī)和法律條文等，從而為進行需求收集做好充分的準備。在進行需求收集和需求分析時，可以根據(jù)不同的用戶對象以及系統(tǒng)分析師的自身技能選擇使用有效的需求分析方法。

3.1 表格記錄法

表格記錄法是指在進行業(yè)務功能調(diào)研前，對該業(yè)務功能可能涉及的法律條文、業(yè)務特征、業(yè)務流程、業(yè)務功能、業(yè)務數(shù)據(jù)元素、數(shù)據(jù)間的約束關系進行表格化和明細化，在與客戶溝通過程中對表格中已記錄的內(nèi)容進行不斷完善和修改，使表格中最終記錄的內(nèi)容與用戶描述完全一致，最終由業(yè)務系統(tǒng)使用人員進行確認，避免雙方對相同的業(yè)務功能理解產(chǎn)生分歧。

在使用表格記錄法時，對業(yè)務功能中涉及的數(shù)據(jù)元素的來源、取值范圍、數(shù)據(jù)元素之間的邏輯關系也要詳細說明并與最終用戶進行一一確認。

3.2 系統(tǒng)原型法

系統(tǒng)原型法是最直接最有效的需求分析方法，該方法通過與客戶進行詳細溝通，制作系統(tǒng)原型，在系統(tǒng)原型中除了業(yè)務數(shù)據(jù)是靜態(tài)的以外，其他的業(yè)務流程、業(yè)務數(shù)據(jù)項、數(shù)據(jù)項在界面中的位置、數(shù)據(jù)項之間的約束關系全部得以體現(xiàn)，同時在使用系統(tǒng)原型法進行需求分析時，最好能夠拿用戶實際辦理的業(yè)務，與用戶一起在原型系統(tǒng)中進行全流程的操作，從而記錄系統(tǒng)原型與實際業(yè)務之間的差別，進行修改系統(tǒng)原型并進行再次確認，直到系統(tǒng)原型完全滿足用戶業(yè)務需求。

在使用系統(tǒng)原型法時，一定要與客戶一起拿實際業(yè)務進行演練，不可將系統(tǒng)原型直接發(fā)給客戶，最后問客戶該原型是否滿足他們的業(yè)務要求。如果這樣做則可能會因為客戶只是對系統(tǒng)原型進行大致瀏覽，總體上感覺已滿足實際工作需要，可能導致實際上并不能完全滿足業(yè)務需求的情況發(fā)生，為后期業(yè)務系統(tǒng)功能開發(fā)埋下禍根。

在使用系統(tǒng)原型法時，特別是對業(yè)務系統(tǒng)各功能界面中的以選項形式出現(xiàn)的數(shù)據(jù)要與客戶確認這些選項是固定的還是可變的，選擇不同的選項是否會對業(yè)務流程造成影響、選項數(shù)據(jù)的來源依據(jù)。

系統(tǒng)原型法在實際使用過程中會增大人力成本的投入，如果人力成本緊張可選擇重點業(yè)務功能使用系統(tǒng)原型法，部分業(yè)務功能使用表格法的方式進行[3]。

3.3 類似項目對比法

類似項目對比法也是行之有效的需求調(diào)研方法，該方法可以讓用戶直接的體驗系統(tǒng)的各項功能，從而判斷哪些功能是用戶需要的，哪些與用戶的實際工作類似但又不能滿足實際工作需要。

該方法是在用戶基本上無法提出自己的具體業(yè)務需求或用戶已經(jīng)考查過多家兄弟單位的系統(tǒng)后又覺得已有系統(tǒng)均無法完全滿足自己實際業(yè)務需求的情況下使用。在使用該方法時，最好能夠找到兩個以上的應用系統(tǒng)，需求人員與最終用戶一起對多個系統(tǒng)中用戶要使用的功能進行具體操作，詳細記錄用戶需要的功能以及這些功能不滿足日常工作的原因或需要加強的內(nèi)容，提出改進建議并征得用戶的確認。在此基礎上可結(jié)合表格法、系統(tǒng)原型法進行最終需求收集及確認，完成需求調(diào)研工作及確認工作。

3.4 需求一致性確認法

該方法適用于同一個業(yè)務功能有多人使用的情況，在這種情況下不同人對同一業(yè)務功能的要求也不完全相同，甚至對于界面操作提出完全不同的要求，在此情況下應該將所有的需求全部進行收集整理，最后給出多套解決方案，通過開會討論的形式進行確認，使所有使用該業(yè)務功能的人員對需求達成一致，否則該功能將導致后期系統(tǒng)推廣障礙。如果在開會討論時無法達成一致，可以再次開會討論會并邀請用戶的領導參與，最由終領導督促形成統(tǒng)一意見。

4 結(jié)束語

正確的、科學的需求分析方法有效的保障需求分析的正確性和完整性；正確的、完整的、全面的、深入的需求分析是業(yè)務系統(tǒng)能夠準確順利開發(fā)和按時交付的重要保障，在業(yè)務系統(tǒng)開發(fā)過程中起著至關重要的作用，為業(yè)務系統(tǒng)的順利開發(fā)保駕護航。