荊 澎

一、引言

軟件工程中，軟件需求分析 （Software Reguirement Analysis）是指研究用戶需求得到的東西，完全理解用戶對軟件需求的完整功能，確認用戶軟件功能需求，建立可確認的、可驗證的一個基本依據(jù)。在軟件工程的歷史中，很長時間里人們一直認為需求分析是整個軟件工程中最簡單的一個步驟，從而導致投入分析的精力和時間過少，啟動開發(fā)過快。在過去十年中越來越多的人認識到它是整個過程中最關鍵的一個過程。假如在需求分析時我們作為系統(tǒng)分析和開發(fā)人員，未能正確地認識到用戶的需要的話，那么最后的軟件實際上不可能達到用戶的需要，或者軟件無法在規(guī)定的時間里完工，軟件項目失敗的風險倍增。

我們做需求分析的目的是完整、準確地描述用戶的需求，跟蹤用戶需求的變化，將用戶的需求準確地反映到系統(tǒng)的分析和設計中，并使系統(tǒng)的分析、設計和用戶的需求保持一致。合理劃分需求分析工作流程、掌握科學的方法和手段，進而形成確定、嚴謹?shù)慕桓段?，才能為后續(xù)開發(fā)、測試、運維奠定可靠、堅實的基礎。

二、軟件需求分析的流程劃分

需求分析的流程可劃分為三大階段，分析流程與需求組成如圖1所示：

圖1

（一）明確項目意義、背景以及技術實現(xiàn)框架

第一階段首先要充分理解項目立項的背景、意義及目標要求，即業(yè)務需求。要充分了解項目所處的業(yè)務領域，明確該項目在整個領域的位置、作用以及與正在運行的項目、系統(tǒng)的關系，包括業(yè)務交叉關系以及技術依賴，等等。完成上述工作后，要結(jié)合已知情況選擇技術實現(xiàn)的框架，包括開發(fā)工具、組件 （包括現(xiàn)有平臺組件及可能需要的第三方組件）、開發(fā)、測試和運行的基礎環(huán)境等。

（二）明確項目核心需求定義

第二階段，我們需要做的工作就是確定項目的核心需求，即需求調(diào)研報告中涉及的用戶使用系統(tǒng)必須完成的任務，也叫用戶需求。同時，要完成用戶需求對應的核心功能、質(zhì)量和相關的制約條件。

所謂核心功能是指根據(jù)對項目的分析和調(diào)研規(guī)劃，找出當前最迫切需要實現(xiàn)的、最能體現(xiàn)項目價值的關鍵功能。對于技術風險大的、與現(xiàn)有項目功能有歧義的，或者核心功能中相互沖突的功能要進行前期取舍。確定核心功能的過程是一個和用戶不斷溝通、技術上不斷遞歸的過程。

此階段在確定核心功能的同時要引入質(zhì)量的概念，也叫非功能需求，即結(jié)合功能定義，從性能、可靠性、可擴展性、可維護性、可移植性即易用性、安全性等多個質(zhì)量指標進行篩選，標準就是第一階段獲取的信息。

確定了核心功能、質(zhì)量后還要充分考慮限制條件，即項目需求實現(xiàn)的特殊情況或者可能限制實現(xiàn)的條件，分為業(yè)務級、用戶級和開發(fā)級等。例如業(yè)務表單流轉(zhuǎn)依賴HB2008工作流組件設計等屬于業(yè)務級；某些功能可能需要協(xié)勤人員操作，其認證等需要 “三統(tǒng)一”平臺額外開發(fā)或者審批開通權限等屬于用戶級；必須運行在Windows操作系統(tǒng)下、必須使用國有自主知識產(chǎn)權的數(shù)據(jù)庫產(chǎn)品或者一些不熟悉的技術領域依賴開發(fā)人員的水平等都屬于開發(fā)級。

（三）進行項目詳細需求分析

項目詳細需求分析就是針對核心功能進行細化的業(yè)務邏輯和數(shù)據(jù)流需求調(diào)研分析過程，形成功能需求。此階段要緊緊圍繞核心功能做好以下工作：一要調(diào)查組織機構情況，包括了解部門組成情況，各部門的職能等，對其管理層次與線條建立全局了解，為分析信息流程作準備。二要調(diào)查各部門的業(yè)務活動情況，包括了解各個部門輸入和使用什么數(shù)據(jù)，如何加工處理這些數(shù)據(jù)，輸出什么信息，輸出到什么部門，輸出結(jié)果的格式是什么。特別要針對這些業(yè)務流程，繪制出跨部門職能流程圖，幫助后續(xù)開發(fā)人員對用戶的業(yè)務流程建立宏觀、清晰的認識，以便更加有的放矢地進行進一步的需求捕獲工作，此項過程要與用戶反復驗證，使需求功能描述明確清晰。三要協(xié)助用戶明確對新系統(tǒng)的各種要求，包括信息要求、處理要求、完整性要求。四要確定新系統(tǒng)的邊界，確定哪些功能由計算機完成或?qū)頊蕚渥層嬎銠C完成，哪些活動由人工完成，由計算機完成的功能就是新系統(tǒng)應該實現(xiàn)的功能，同時要注意提醒用戶開始著手建立系統(tǒng)使用和操作規(guī)范及管理制度。

此階段形成 《需求規(guī)格說明書》（SRS），內(nèi)容包括功能描述、用戶用例、數(shù)據(jù)流轉(zhuǎn)圖、業(yè)務邏輯圖等，應包括上述三階段軟件系統(tǒng)所應具有的全部外部行為。其在后續(xù)開發(fā)、測試、質(zhì)量保證、項目管理以及相關項目功能中都將起到重要的作用。

三、軟件需求分析過程中存在的問題

由于軟件需求分析的重要地位，這一過程中存在或者隱藏的問題直接會導致項目失敗或者崩潰，應引起高度重視。問題主要存在以下幾個方面：

（一）用戶參與度不夠

很多項目經(jīng)常是由領導層面自上而下提出的，但由于工作繁忙，領導或者發(fā)起人不能保證具體參與需求討論和調(diào)研，下屬用戶有時只能憑靠揣測領導意圖來提需求。有時用戶對項目非?？释?，但由于缺乏軟件系統(tǒng)建設方面的專家和相關知識，對需求只有朦朧的感覺，具體說不清楚，就會泛泛而談或者干脆要求分析人員替代他們設想需求，技術人員主觀性早早帶入分析過程，為未來的開發(fā)建設埋下了隱患。還有部分用戶自侍業(yè)務精通，“越俎代庖”告訴技術人員很多其他部門業(yè)務需求，將需求調(diào)研帶入歧途。

（二）不清晰、不穩(wěn)定或無休止的需求

軟件需求分析人員不可能都是全才，更不可能是行業(yè)方面的專家。對客戶表達不清晰的需求，不同的分析人員可能有不同的理解。如果分析人員理解錯了，后續(xù)可能使測試者與開發(fā)者所期望的不一致，導致開發(fā)工作勞而無功。另一方面，根據(jù)以往經(jīng)驗，隨著用戶對信息化建設的認識和自己業(yè)務水平的提高，他們會在不同的階段和時期對項目的需求提出新的要求和需求變更，這都導致需求的不穩(wěn)定。此外，用戶不斷地補充需求，項目就越變越龐大以致超過其計劃及預算范圍。計劃并不總是與項目需求規(guī)模與復雜性、風險、開發(fā)生產(chǎn)率及需求變更實際情況相一致，這使得用戶業(yè)務問題更難解決。

（三）不重視用戶分類

根據(jù)以往項目經(jīng)驗，大多數(shù)系統(tǒng)是由不同的人使用其不同的特性，使用頻繁程度也有所差異，使用者受教育程度和經(jīng)驗水平也不盡相同。如果不在需求分析階段就針對所有用戶進行分類，考慮個性化需求的話，必然導致有的用戶對交付的系統(tǒng)感到失望。

（四）技術人員的 “自以為是”

“自以為是”是指開發(fā)人員力圖增加一些 “用戶欣賞”但用戶并未提及的新功能。經(jīng)常發(fā)生的情況是用戶并不認為這些功能有用，導致開發(fā)人員徒勞無功。

（五）輕視與過度重視

有些項目組在需求調(diào)研和分析時缺乏計劃性、科學性，“走過場”。需求調(diào)研僅簡單與用戶閑聊、收集一些文檔、表格就草草結(jié)束，輕率地開始編碼，這種輕視的后果往往導致需求無法驗證，很多情況下到項目交付時才開始履行驗證過程，產(chǎn)生大量的需求變更，后果非常嚴重。另一種情況，項目組過度重視需求規(guī)格說明書的編寫，為編寫而編寫，甚至出現(xiàn)工程組內(nèi)部 “白天寫文檔，晚上寫代碼”的情況。產(chǎn)生出的文檔經(jīng)常與實際開發(fā)脫節(jié)，完成后就束之高閣，不再使用、不再驗證和更新，這也是需求崩潰的一個重要原因。

四、軟件需求分析的幾種方法和工具

由于對需求分析的理解不同，使用的方法也多種多樣。根據(jù)以往我們的經(jīng)驗，業(yè)界比較成熟的“三步法”更符合海關實際工作。

（一）“訪談式”（Visitation）

第一步關鍵是要與項目提出人、用戶領導層、業(yè)務層，即持有重要業(yè)務信息的人進行訪談式溝通，主要目的是從宏觀上把握用戶的具體需求方向和趨勢，了解現(xiàn)有的組織架構、業(yè)務流程、硬件環(huán)境、軟件環(huán)境、現(xiàn)有的運行系統(tǒng)等具體情況、客觀的信息。訪談的渠道和方式可以多樣，例如需求專題會議、電話、郵件等，并針對具體的部門指定項目的業(yè)務聯(lián)系人。溝通應盡可能高效，應先根據(jù)已掌握的信息和需求列出問題提綱，既提高效率，又增加用戶對技術人員的好感和信任。對不同的訪談對象，詢問和討論的主題和內(nèi)容應注意區(qū)分：一般對于領導，要討論目標、方向以及總體要求等問題，而不是業(yè)務細節(jié)。對于用戶的業(yè)務層領導，要多詢問一些業(yè)務流程方面的問題，他們在這方面最熟悉并有見解，軟件的大部分需求一般都是這個層次的人員提出的，和這個層次的人員要注意關系上的協(xié)調(diào)；對于具體操作人員，可以多詢問一些對方的操作習慣、業(yè)務處理的細節(jié)等問題；對于系統(tǒng)管理員，則可以討論一些技術上的問題。每次訪談都應有詳細的書面記錄，可以使用Excel、Word等工具形成調(diào)查表格、報告，這是形成需求分析結(jié)果的基礎和下次需求調(diào)研的前提，應力爭每次訪談都使需求分析向前推進一個階段。記錄使用的語言須是用戶熟悉的詞匯，要使用明確肯定性語句，不要使用模糊的說法。

（二）“誘導式”（Inducement）

這一步是在充分訪談溝通、對用戶獲取了大量信息數(shù)據(jù)基礎上，結(jié)合現(xiàn)有的硬件、軟件實現(xiàn)方案，通過制作原型、統(tǒng)一建模語言、用例和敏捷軟件開發(fā)等方法，使用Visio或者Axure RP等工具做出簡單的用戶流程演示及系統(tǒng)界面。同時，結(jié)合以往的項目經(jīng)驗，對用戶采用誘導式、啟發(fā)式的調(diào)研方法和手段，和用戶一起探討業(yè)務流程設計的合理性、準確性、便易性、習慣性。用戶可以操作簡單演示的DEMO，來感受整個業(yè)務流程的設計合理性、準確性等等問題，及時地提出改進意見和方法。通過誘導和充分的再次交流，可以形成調(diào)研分析報告、原型反饋報告、業(yè)務流程報告等二次調(diào)研成果。

（三）“確認式”（Confirmation）

這一步是在訪談、誘導兩步成果的基礎上，進行具體的流程細化、數(shù)據(jù)項的確認階段。這個階段技術人員必須提供原型系統(tǒng)和明確的業(yè)務流程報告、數(shù)據(jù)項表，并能清晰地向用戶描述系統(tǒng)的業(yè)務流設計目標。用戶可以通過審查業(yè)務流程報告、數(shù)據(jù)項表以及操作DEMO或者原型系統(tǒng)提出反饋意見，并對已經(jīng)可接受的報告、文檔簽字確認。目前海關科技應用項目管理中推廣使用的 “任務書”即為確認步驟的成果和載體。

整體來講，需求分析的三個步驟是需求調(diào)研中不可忽視一個重要的部分，它們的實施和采用為項目成功提供了保證。在目前廣為流行的 “迭代法”開發(fā)模式時，需求分析的工作將貫穿整個開發(fā)過程，需求改進中，主要工作則集中在后兩個步驟中。

五、軟件需求分析的人員配置

需求分析人員即需求工程師，其必須具有開發(fā)背景和實戰(zhàn)經(jīng)驗，和程序開發(fā)人員針對問題采用技術解題的 “分解能力”相比，其更應該具有的是與用戶溝通交流、找出問題的 “合成能力”。需求工程師與人的交流能力要勝于與機器的交流能力，他的自然語言表達能力要勝于編程語言表達能力。需求分析是一個綜合團隊的工作，是在需求分析理論的指導下，對用戶需要進行漸進方式逐步深化，應以產(chǎn)品的眼光看待每個項目，因此，需求分析可以看做是商務行為，是一個商業(yè)化操作，要求由商務活動人員 （包括需求工程師）、項目管理人員、設計技術人員等結(jié)合的團隊共同合作，各自明確負責范圍、工作目標，解決需求和設計的同步問題，努力做到設計符合需求。

六、結(jié)束語

需求分析作為項目開發(fā)階段的開端，是軟件工程的真正開始。需求分析是所有軟件成功要素發(fā)揮作用的前提，它的好壞直接影響著后面的各個階段，關系著軟件的成敗。軟件項目中40%至60%的問題都是在需求分析階段留下的隱患。青島海關技術處近十年來，注意跟蹤業(yè)界先進的軟件開發(fā)管理理念，高度重視需求分析工作，自2005年以來，先后在所承辦的署級 “保稅作業(yè)監(jiān)控分析系統(tǒng)”、“海關政府采購業(yè)務信息平臺”、H2010工程 “海關綜合業(yè)務管理平臺”等重大軟件應用項目中遵循軟件開發(fā)的客觀規(guī)律，組建專門的需求分析團隊，全面啟用科學的需求分析方法，保證了項目開發(fā)建設質(zhì)量，所開發(fā)的系統(tǒng)易用性、可靠性、穩(wěn)定性以及可擴展性得到顯著提升，獲得海關業(yè)務部門和人員的廣泛好評。

〔1〕Karl E.Wiegers，劉偉琴，劉洪濤 .軟件需求 〔M〕.第2版 .北京：清華大學出版社，2004.

〔2〕徐賽華 .軟件需求分析研究 〔J〕.吉林師范大學學報，2006 （1）.