信息系統需求分析階段的實踐經驗之二---如何有效地得到用戶需求【轉】

（一）有效進行需求調研的方法

一、明確總體思路

軟件項目通常會包含客戶的不少種需求，涉及客戶的多方面業務和多個部門，所以需求調研必定要有一個明確的思路，從大處着眼，而後逐漸細化，直到詳細的需求細節。好比，首 先是客戶的總體要求和目標，而後是各個部門的各類業務項目及主要的業務流程，再到業務過程的每個單據，每一條記錄，以及表現形式等等。需求紛繁蕪雜，在 需求調用的過程當中要常常查看項目規格說明書，明確項目最初提出的目標和範圍，主要是爲用戶解決什麼樣的問題，這樣才能從衆多的需求中分清主次，提取用戶核心的、主要的業務。

2、進行充分準備

不管是面對面的需求會議，仍是電話溝通，都應該注意在交流以前儘可能取得更 多的信息以準備。每次需求會議前先根據當前掌握的信息和需求列出問題提綱，這樣在調研的時候才能問到點上，既提升效率，又增長用戶對咱們專業素養的信任。 不只咱們要充分準備，也能夠先讓用戶提供一份用戶本身寫的書面需求，事先作一個較明晰的闡述。另外，還要提醒用戶必要的材料和數據準備，這些準備將有助於會議的進行，以避免用戶在會議開始後再找材料查資料，中斷會議的進行，影響調研的效果。

3、區分調研對象

對不一樣的調研對象，詢問和討論的主題和內容應注意區分：通常對於用戶的高層領導，不要討論細節問題，要討論高層的業務需求，討論目標、方向等問題，另外要把握好時間，不宜過長；對於用戶的業務層領導，要多詢問一些業務流程方面的問題，他們在這方面最熟悉並有看法，通常來講，軟件的大部分需求都是這個層次的人員提出的，和這個層次的人員要注意關係上的協調；對於具體操做人員，能夠多詢問一些對方的操做習慣、業務處理的細節等問題；對於系統管理員，則能夠討論一些技術上的問題，好比，經過其瞭解客戶公司的軟硬件及網絡環境，用戶的操做水平等。

4、詳細明確的記錄

記錄包括會議記錄和需求記錄。每次溝通都應有詳細的書面記錄。這是造成需求分析結果的基礎和下次需求調研的前提。若是不這樣作，結束調研的時候只有一個模糊的印象，需求分析的結果仍然高不可攀，應力爭每次需求會議都使需求分析向前推動一個階段。討論結束前將記錄的文檔向客戶確認一下，讓客戶進行評論和更正，以保證沒有錯誤和歧義。記錄使用的語言須是用戶熟悉的詞彙，要使用明確確定性語句，不要使用模糊的說法。好比，不能描述爲一天產生的POS業務流水不少，應該明確到10的3次方的數量級，不能僅記錄爲要求日結帳要快，應該明確到在200秒內完成等。

5、多思考多提問

軟件需求是分層次的，用戶對咱們描述的每每只是用戶需求層次的表面問題，只了解這些是不夠的，還要理解用戶爲何要提出這樣的需求，作到知其然又知其因此然。做爲需求分析員，必需要深刻地理解客戶的業務邏輯和需求目的。在大多數的軟件系統中，最終用戶可能都不清楚他的需求是什麼。若是隻知道用戶提出的要求，而不知道其爲何有這個要求，那麼極可能會誤入歧途，獲取不了用戶的真正需求。好比針對上述會員多倍積分需求，用戶要求在POS斷網的時候也能實時執行。事實上若是不採用無線通信這根本不可能，採用無線成本又過高。詢問緣由後，才知道實際上用戶是擔憂數據丟失，咱們只要保證數據不丟失，在網絡鏈接正常後再執行就能夠了。

（二）容易忽視的事項

一、肯定權利與義務

只有當雙方參與者都明白促成當前信息管理系統建設的成功，本身須要作什麼，合做方須要作什麼時，才能創建起一種好的合做關係。爲了需求調研的有效進行，能夠在開始以前向客戶明確其需求權利和應盡義務。可以經過需求權利書規定客戶在項目需求調研過程當中的合理要求，這些權利同時對應着分析人員和開發人員的義務；而經過需求義務書規定客戶在需求過程當中應承擔的義務，固然這些也能夠認爲是分析人員和開發人員的權利。

二、蒐集用戶資料

不少時候用戶對本身需求的語言描述帶有隨意性和模糊性，又加上思惟角度的不一樣，每每會形成咱們理解上的誤差，而企業中的文檔資料則真實地反應了用戶的業務。它們包括，打印出來的各類單據、報表，企業的業務管理規則、制度，內外部考覈辦法等。這些資料將有助於直觀、具體、高效的獲取需求。好比，能夠詢問用戶是否已經制定出多倍積分的書面草案，有沒有相關的會員積分政策文檔做爲參考等。

3、到工做現場考察

對於難於理解的用戶業務或性能方面的需求，必定要進行操做現場的實地考察，觀察正在工做的用戶，親身感覺實際業務流程、瞭解操做狀況。現場考察是理解用戶需求的最好的方式。主觀推斷每每和實際的業務操做有很大的出入。好比，有些開發人員不重視快捷鍵的設置，若是觀察超市POS終端操做員的工做，將會明白這很是重要。再如，離岸BPO用來提交業務數據的軟件系統對網路傳輸的速度、操做響應的速度等有很是高的要求，不然操做員難以忍受，而且大大影響工做效率。若是隻實現了功能，而不能達到性能要求則遠遠沒有知足客戶的需求。

4、非功能性需求

非功能性需求包括，客戶現有的服務器資源、網絡資源及環境、硬件條件、操做系統、操做人員水平、由用戶的工做特色決定的對性能的特殊要求等。若是不事先了解這些狀況，或事先告知客戶進行必要的資源環境準備，可能會致使最終軟件沒法部署，操做人員沒法使用等狀況。好比，用戶服務器用的是免費的Linux操做系統，而咱們開發的軟件只能在收費的Windows操做系統上運行，將直接宣告項目的階段性失敗。

5、舊版本，相關軟件系統和接口

若是項目是對原有的軟件從新開發或升級，那麼必定要仔細研究舊的軟件系統的功能，並 詢問客戶 舊系統不能知足當前需求的緣由，以期在新的系統中得以改善和提升，同時 舊 系統中優秀的功能特色要予以保留。若是用戶當前已經使用了其餘系統，必定要了解這些系統，看有沒有重複開發，或 功能 不 足的補充。還應注意相關係統中的數據編碼規範、操做規範，用戶操做界面，以便於用戶對新系統的適應、培訓和維護。若是用戶要求軟件和現有的系統進行數據交 互或通過調研發現須要數據交互，那麼必定要弄清數據接口的規範、接口雙方的通訊方式、數據存儲方式、採用的數據庫系統、數據結構等。 好比，增長會員多倍積分模塊，就要考慮數據接口，通訊方式，界面一致性，尤爲是 POS 端快捷鍵不能衝突等多個方面。