軟件項目需求分析過程中與用戶溝通的要點問題研究

[摘 要] 成功的軟件產品是建立在成功的需求分析基礎之上的，而高質量的需求來源于用戶與開發人員之間有效的溝通與合作。因此，在軟件項目的需求分析過程中，開發人員需要從項目的需求調研開始前就進行充分的準備，特別是要了解和掌握一定的用戶業務領域知識；溝通中必須注意把握需求的層次，才能從項目的總體目標、業務流程和具體功能實現等方面保證用戶需求的完整；在溝通中掌握不同用戶群體的代表性人物，可以使需求調研分析的成果具有權威性、完整性和一貫性；在開發人員主導下積極引導用戶提出自己的需求，才能保證形成的用戶需求既有合理性，又有可行性。

[關鍵詞] 軟件開發；需求分析；用戶溝通

[中圖分類號] TP311.5 [文獻標識碼] A [文章編號] 1673 - 0194（2013）17- 0057- 03

1 前言

成功的軟件產品是建立在成功的需求分析基礎之上的，而高質量的需求來源于用戶與開發人員之間有效的溝通與合作。當用戶有一個問題需要用計算機系統來解決，而開發人員開始幫助用戶解決這個問題時，溝通就開始了。

需求獲取可能是軟件開發中最困難、最關鍵、最易出錯及最需要溝通交流的活動。有些開發人員對需求的獲取往往有錯誤的認識，認為：用戶知道需求是什么，我們所要做的就是和他們交談從他們那里得到需求，只要問用戶系統的目標特征，要做什么或不做什么或都憑用戶自己確定就行了。但是實際上需求獲取并不如想象的這樣簡單，一個軟件項目的需求要經過開發人員與用戶的有效溝通與認真分析才能確定下來。

這其中還有對問題的理解，用戶對計算機系統的能力和限制缺乏了解，任何一個系統都會有很多的用戶或者不同類型的用戶，每個用戶只關注自己需要的系統，而不知道系統的整體情況，他們不知道系統作為一個整體怎樣工作效率更好，不關心系統中信息資源的規范與共享問題，也不太清楚哪些工作可以交給軟件完成，他們大多不清楚需求是什么，或者說如何以一種精確的方式來描述需求，他們需要開發人員的協助和指導。但是用戶與開發人員之間的交流很容易出現障礙，容易忽略了那些被認為是“很明確”的信息。

本文結合筆者在實際軟件項目開發工作中的經驗，就需求分析時與用戶溝通中應注意的幾個問題進行研究分析。

1 溝通前的準備工作是開發人員必須做的功課

開發人員與用戶溝通前的準備工作一般有常規準備和可能需要的業務領域知識準備兩個方面。

常規的準備工作包括對項目整體環境的熟悉，著重需要了解項目的背景、項目的目的、項目的利益相關方等信息，以便對當前項目的總體情況有一定了解。同時還要圍繞這些方面對將要展開的調研進行需求調研問題的準備、需求調研模板的設計、需求調研時間安排等。

承擔需求調研的開發人員除了做好上述基本的準備工作外，還需要結合自身對用戶業務領域知識的掌握情況，主動積極了解客戶業務和相關知識。這是因為，雖然開發人員可能在信息技術方面非常專業，但對于具體的用戶業務可能并不十分清楚。這個項目對用戶將有什么幫助、某一系統功能是否有用、某一流程處理是否合理，在不了解用戶業務的情況下，我們將很難做出判斷。這一掌握業務領域知識的工作也可能是要貫穿項目發展過程始終的。

因為只有在了解業務的基礎上，我們才能和用戶有共同的溝通語言和業務理解，才能真正理解系統應具有哪些功能。筆者曾在對某鋼鐵企業ERP項目的生產管理系統進行調研的過程中由于缺乏冶金生產方面的知識，有許多問題不能很好理解。

當時，筆者向用戶虛心請教，并在調研結束后及時對有關生產知識進行了補充。后來在進行該項目的設備管理系統調研前，筆者結合前段時間了解的冶金生產工藝知識，又事先瀏覽式地學習了一下有關冶金設備知識，再進行調研時與用戶的溝通就順暢了許多。

應用領域的知識是無邊無際的，在各種項目的調研過程中，肯定會出現由于需求分析者缺乏某一領域的知識而影響需求分析工作準確、順利進行的問題。遇到此類問題時，需求分析者應虛心向用戶請教，同時應及時補充應用領域的知識。在調研前做好充分的準備是十分必要的。

2 把握好需求的層次是與用戶有效溝通的保證

對于一個軟件系統項目來講，開發人員需要面對不同層次，不同部門的客戶，要廣泛聽取意見。不同組織機構層次，不同業務部門，甚至不同計算機使用水平的客戶對系統的要求都會有不同。比如，總經理級別的客戶可能只是對宏觀報表感興趣，業務細節操作他們一般不會發表什么意見。部門經理則關注日常工作報表，系統功能的實現以及可能的擴展策略。普通業務操作人員則關心操作方式、界面風格、易用性等。因此，把客戶分成不同的群組就變得非常有價值，這樣將會使需求分析的工作變得簡單。因為開發人員可以從不同群組的維度來分析需求，對于特定的需求問題，則需要關注特定的客戶群來合作溝通。

在軟件工程中將軟件需求分為業務需求、用戶需求、功能需求與非功能需求3個層次。從與用戶溝通的角度來看，也可以分別通過3個不同層次的需求將用戶劃分為三大類群體。

業務需求反映了用戶對軟件產品高層次的目標要求。在項目中，一開始用戶高層領導通常會講，我們上這個系統的目標是什么，我們為什么要上這個系統，我們要達到什么樣的一個高度。通過這個層次的調研與分析來確定所開發項目的目標和范圍。

經過上面的業務需求分析確定了項目的目標和范圍后，緊接著就是同用戶中層領導討論，他們主要會講我們的業務是什么，我們怎么工作，我們的工作流程是什么。這就是用戶需求。通過對項目的用戶需求分析，得出了項目的基本業務流程。

得到了這些信息后，開發人員開始整理，把軟件功能點找出來，確定軟件如何完成用戶的工作，這是軟件功能需求。按照功能需求做出來的軟件是否能夠被用戶認可，這時不僅要面對用戶的中層領導人員，還要面對基礎管理人員和現場操作人員。

在功能需求滿足用戶要求的基礎上，用戶自然會提出一些方便性、安全性之類的要求，也就是非功能需求。所謂非功能性需求，是指軟件產品為滿足用戶業務需求而必須具有且除功能需求以外的特性。例如系統的性能、可靠性、可維護性、可擴充性，以及對技術和業務的適應性等。非功能性需求涉及的范圍很廣，軟件產品本身不是孤立存在的，還涉及諸多外在環境的影響。非功能性需求必須考慮軟件既要可用，又要易用。

4 注意在溝通中掌握不同用戶群體的代表性人物

用戶組織中的人員在很多方面存在差異，例如：使用系統的頻度和程度、計算機系統知識、所進行的業務過程以及個人的素質和喜好等。結合不同需求層次的用戶的特點，可對用戶進行一定的分類。將用戶分類并歸納各自特點，詳細描述他們的個性特點及任務狀況，將有助于需求的獲取和分析。

不同的問題需要詢問不同的人，對于操作細節的問題，要和實際負責操作的用戶進行溝通，而對于關乎全局的問題，則要和相應的管理層用戶進行溝通。如通過組織架構圖得知儲運系統的倉儲管理活動涉及3種角色：倉庫主管、計劃員、理貨員。

我們發現倉庫主管是對全盤業務相當熟悉的人，他負責協調本部門的全局事務；計劃員則是負責接收和處理采購計劃和到貨信息，理貨員按出入庫通知單承擔收發貨的具體操作，這些人都將通過建成后的系統操作完成自己的業務。若我們調研的目的是搞清該部門的整體性流程，我們會很自然地選擇倉庫主管作為訪談的對象。

不可能對所有的用戶都進行需求獲取，這樣做時間不允許，效果也不一定好，所以要識別出能夠確定需求和了解業務流程的用戶作為每類用戶的代表。每類用戶至少選擇一位能真正代表他們需求的人作為代表并且能夠作出決策，用戶代表往往是本類用戶中的3類人：對項目有決定權的領導、熟悉業務流程的專家、系統的實際使用者。

每一個用戶代表代表了一個特定的用戶類，并在那個用戶類和開發者之間起溝通連接作用，用戶代表從他們所代表的用戶類中收集需求信息，同時每個用戶代表負責協調他們所代表的用戶在需求表達上的不一致性和不兼容性。

5 注意積極引導與合理利用用戶的需求

由于用戶往往對規劃中的項目沒有直觀的認識，對于計算機系統的應用特點也缺乏了解，所提出的需求大多是以眼前的工作環境為基礎，只關心自己局部的業務與數據要求，不能從全局的視角理解新系統投運后的組織機構與業務流程，對于一些有前瞻性的設計思想會不以為然。

例如在做ERP項目的能源管理系統時，由于數據是以自動采集為主的，我們規劃了每分鐘的能源儀表運行數據和按小時、班和日的結算數據功能，負責能源管理的用戶人員卻說他們只是月底有套月報表就可以了，沒有精力按日管理，更不會按小時來管理。我們根據自己在這個領域的開發經驗，耐心地向用戶介紹了這樣設計對于用戶能源管理的必要性，同時說明這樣一定能夠滿足按月報表的需求，方案獲得了用戶高層領導的認可與贊許。結果在項目投運的一年后，該企業就圍繞節能降耗和降成本工作，利用能源計量系統的小時量和班量數據在基層車間開展了現場能源管理與指標考核活動，利用日量數據上形成的周報、旬報，開展了全面的旬成本分析和重點工序的周成本分析。

這個案例說明開發人員在具備充分的業務領域能力后，在與用戶的需求溝通中主動發揮引領作用，可以實現項目開發中的甲乙方雙贏效果。

還有些時候，用戶的想法在實際實施過程中是不現實的。若一味地求全和盲目遵從用戶的設想，將為項目的后續工作帶來很大的風險。因此應盡量避免在需求分析中包含技術實施上有難度的功能。如在筆者曾經負責的一個項目中，用戶要求新的管理系統應實現和社保、醫保等管理系統的數據接口，以方便這些系統中的數據導入新的管理系統。

許諾提供與社保、醫保等系統的數據接口，將為新系統的成功實施帶來很大的風險。因為熟悉這些系統需要時間，開發與它們的接口也需要時間，而且與社保、醫保這樣的系統談接口條件，也不是我們單方面能夠決定的。因此與外部系統接口的可行性結論為：不可行。

6 結語

將知識從一個地方傳送到另一個地方并不是一件簡單的事情，而且原始的需求通常是以不完整的形式呈現的。它也許只是在某個現有系統的用戶腦中，甚至有時用戶都沒有意識到他們知道什么。因此，作為一個稱職的開發人員，在項目的需求調研開始前必須進行充分的準備，特別是要了解和掌握一定的用戶業務領域知識，還要注意在整個項目活動中主動向用戶學習；溝通中把握需求的層次，就能夠根據項目的總體目標與任務范圍、業務流體與數據關系、業務作業與功能實現這樣3個基本層面來理清用戶需求的不同層次關系，進而確保與用戶溝通的有效性；在溝通中掌握不同用戶群體的代表性人物，可以使需求調研分析的成果具有權威性、完整性和一貫性；在需求調研的溝通中既不是用戶說什么就是什么，又不是開發人員憑自己的經驗和理解“閉門造車”，而是要在開發人員主導下積極引導用戶提出自己的需求，通過討論分析再歸納形成用戶的合理需求，這樣才能保證設計的新系統在符合計算機系統規律、發揮計算機系統能力特長的基礎上，真正滿足用戶的需求。