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

帥曉華

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

0 引言

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

1 軟件生命周期概述

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

1.1 問題定義

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

1.2 可行性研究

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

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

1.3 需求分析

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

1.4 系統(tǒng)設(shè)計

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

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

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

1.5 編碼和單元測試

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

1.6 綜合測試

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

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

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

1.8 系統(tǒng)維護(hù)

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

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

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

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

2.1 需求分析的正確性

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

2.2 需求分析的完整性

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

2.3 潛在需求的挖掘

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

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

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

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

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

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

3 正確的需求分析方法及注意事項(xiàng)

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

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

3.1 表格記錄法

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

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

3.2 系統(tǒng)原型法

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

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

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

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

3.3 類似項(xiàng)目對比法

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

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

3.4 需求一致性確認(rèn)法

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

4 結(jié)束語

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