需求調研分析中的項目幹系人概念

摘要：根據調查，屬于需求分析和軟體設計的錯誤和缺陷約占軟體錯誤的64%，而屬于程式代碼的錯誤僅占36%。因軟體錯誤的積累與放大效應，造成整個軟體業項目拖延的情況高達20%到60%。這些資料表明搞好需求調研分析及軟體設計是提高軟體品質的基礎。以下是一些通過全面了解所有項目幹系人的需求改進需求調研分析效果的體會。

關鍵字：項目幹系人、需求、調研

在需求調研分析階段，項目組對客戶的整體組織結構、有關人員及其關系、工作職責等沒有足夠了解以緻于無法得到完整需求或最終經權威使用者代表确認的需求。由于項目經理和需求分析員的工作問題，客戶參與程度部不高，客戶方相關責任人不明确或對範圍和需求責任心不強，提出的需求具有随意性，項目前期對需求的确認不夠積極；或者是多個使用者代表各說各話、昨是今非但同時又希望軟體盡早傳遞；項目後期需求變化随意，造成項目範圍的蔓延，進度的拖延，成本的擴大。

造成上述現象的原因是系統分析人員沒有全面了解所有項目幹系人的需求，并按照重要性優先級進行權衡取舍。全面的需求來自所有項目幹系人。項目幹系人STAKEHOLDER也有的翻譯成利益關系人、利害關系人、利益幹系人、利益共享者、涉衆，如此等等，即所有可能受到項目結果重大影響的人。項目幹系人即可能是項目的受益者，也是項目的風險承擔者，甚至有可能是項目的受害者。項目幹系人的需求包含明确的和隐含的，也可以分為NEED、WANT、WISH等不同層次。

不同的幹系人其願望和追求的目标往往相差甚遠，是以對項目幹系人的願望進行平衡可能是相當困難的事情。例如政府部門準備建設的不少對群衆辦公的資訊系統，上層管理機關往往希望能夠采集盡可能多的資訊項以便對資料進行多種多樣的統計分析，同時為了對資訊進行有效控制而增加一些審批流程；基層對外辦公的視窗則因為辦公速度的壓力希望減少資訊項的輸入量；甚至有些不良的基層客戶由于害怕建立透明度高的資訊系統會影響他們的工作考核成績而消極地應付，即所謂反需求；而客戶的客戶（辦事群衆）則希望相關政府機構能夠簡化工作流程，加快辦事速度；一些客戶相關的管理機構或組織也會制定一些有關的标準規範；作為項目幹系人的公司上司層也可能會提出一些技術上、接口上、環境上的需求；甚至項目組本身因為技術、資源、進度等原因，需要對一些功能進行優先級排序和取舍。雖然不是所有人的需求都是可以滿足的，特别是消極的反需求是不能接受的，但他們的需求都是應當考慮全面并進行平衡的。

軟體開發項目的目的就是實作項目幹系人的需求和願望。如果對項目所有幹系人沒有進行足夠的溝通和影響，使其盡可能地參與項目，則可能因為項目開始時項目範圍和一些具體需求不夠完整清晰，也可能因為某個項目幹系人後期因為認識的變化而提出新的需求，造成工期的延長，成本的增加，甚至項目的完全失敗。是以，應當從項目的啟動開始，需求分析員及其項目成員就要厘清項目幹系人包含哪些人群組織，通過溝通協調對他們施加影響，驅動他們對項目的支援，調查并明确他們的需求和願望，減小其對項目的阻力，以確定項目獲得成功。以下是一些有效的措施：

1、盡快熟悉項目幹系人全貌

有些項目在做需求調查時，由于受進度要求等客觀因素影響，需求分析員與建設機關的技術部門交流較多，向業務管理部門和實際使用者調查不夠深入，造成軟體試用後不得不再對需求做較大調整，"從頭再來"的部分比例很高，大大超過進度要求時間。是以，熟悉項目幹系人全貌是進行需求調查的第一步，也是需求調查的基礎。在定制開發項目的項目幹系人中，最重要的是建設機關中的人事組織、業務關系。最好是能夠用組織結構圖畫出相關機關的組織結構；用責任矩陣确定各部分的調研對象；建立調研對象通訊錄以保證調研及分析期間及時的溝通。與此同時要注意項目幹系人的主次關系，以便在他們之間的需求出現沖突時能夠進行合理的取舍。

熟悉建設機關内部相關部門的業務劃分及它們之間的互相關系,為功能分析準備了必要的資料, 同時可以熟悉使用者方的各類人員，并及時進行廣泛、有效的溝通與交流。特别要與客戶方業務與技術的規劃者和實際使用者進行深入探讨，收集必要的原始資料，保證需求調查的完整性、正确性。

建設機關隻是項目幹系人中的一部分（當然是主要的部分），為了更好地了解項目幹系人全貌，還應當在建設機關組織結構圖基礎上全體項目幹系人結構圖，以便更好更全面地進行需求調研分析。

2、較長的描述各項業務，以利于讓所有客戶确認

盡可能全面詳細地調查并且描述原有系統和使用者希望将來系統具有的各項業務的流程，并将這些業務流程文檔化後與客戶進行讨論，對描述錯誤或不準确不精确的進行修改，最終讓客戶進行确認。從近年來開發的軟體看，對業務處理過程了解的完整性和準确性非常重要。雖然對資料來說都是SIDUT（查增删改傳），但具體業務都是分為若幹步驟，每個步驟都有其業務名稱，同一步驟可能對多個資料集進行不同操作，需要調查了解清楚才能設計出适合各流程業務節點使用者業務特點和習慣的軟體，使開發出來的軟體更受歡迎。當然在進行軟體概要設計時，要盡量排除業務流程的制約，即把流程中的各項業務結點工作作為獨立的對象，充分考慮他們與其他各種業務對象的接口，在流程之間通過業務對象的互相調用實作其業務流程，這樣，在業務流程發生有限的變化時，就能夠比較友善地修改系統程式而實作新的需求。

對于各項業務的調查可以通過對以下資料的收集整理分析，這些資料來自各種各樣的項目幹系人：遵循的标準、組織發放的工作手冊、作業流程、有關業務的上級通知、有關業務的辦事指南、辦理業務時需要填寫的登記表、各種相關的統計報表及通過其他途徑收集的類似系統的介紹、技術資料等等。

3、可視化需求調研，引導各種客戶挖掘他們的需求

有的客戶因為自己缺乏計算機知識，無法提出完整準确、隐含的或潛在的需求。但若這些需求不能滿足将導緻使用者的不滿。是以需求調研分析人員應善于想使用者所想，不但要确定明确的需求，還要善于用啟發的方式與使用者探讨隐含的或潛在的需求，并結合各種調研分析技術挖掘超出客戶期望的令人興奮的需求。這就要求需求調研分析員要盡快完整地熟悉相關業務，進而能夠站在使用者的立場看待軟體需求，想使用者所想，做好業務與計算機之間的橋梁。利用可視化需求調研的方法可以很好地啟發使用者深入挖掘潛在的需求。可視化需求調研就是使用圖表等工具來啟發引導使用者清楚地叙述需求，并且使需求更加全面完善。

對于高層上司，可以提供系統總體架構圖；對于業務管理人員，可以用業務流程圖來描述新舊系統的業務流程；對于客戶中的技術人員，可以用資料流圖、實體關系圖或UML中的各種圖形對系統進行各種角度的描述；而對于業務管理人員、客戶中的技術人員、以及各層次各流程中的使用者，畫出使用者界面圖來進行需求挖掘，是個比較有效的溝通方式。

這裡特别說明一下使用者界面的重要性。使用者界面的設計按理來說是軟體設計的責任，當然客戶自己對界面有特别提出要求的除外。但是，如果把它提前到需求調研時（緊接着原有系統調研分析和系統模型完成之後）與客戶進行讨論，則可以大大改善需求調研的效果。是以不少需求分析的著作把使用者界面說成是“設計層”的需求之一。因為這時客戶對于将來的系統還沒有一個形象上的概念，或者有一個模糊的預想的概念需要表述、驗證、明晰化、完善化。以筆者的經驗，畫出使用者界面草圖與客戶進行讨論，可以大大激發他們提供更為準确全面的需求。原來收集資料，描述業務，說明系統模型到了山窮水盡的時候，這種方法可以達到柳暗花明又一村的效果。在《微軟項目：求生法則》的第8章“需求開發”中，從頭到尾都是圍繞着“使用者接口”（USER INTERFACE也可以翻譯成“使用者界面”）進行讨論，如“建立簡單的使用者接口雛形”、“不斷修訂使用者接口雛型，直到使用者對軟體感到興趣盎然為止”、“完全擴充使用者接口”，同時還要“區分一份非使用者接口需求檔案”，等等。是以，所謂需求就是“當你按下各種相關按鈕（或輸入各種相關指令）時系統做什麼”，所謂設計就是“當你按下各種相關按鈕（或輸入各種相關指令）時系統怎麼做”。雖然在英語中“接口”與“界面”實際是同一個單詞，但“接口”的含義似乎比“界面”來得廣泛，如功能之間的接口、與其他軟體的接口、與其他硬體的接口等等。需求的最終目的實際上是完整準确地描述系統需要的各種接口或“界面”，及它們的互相關系或與外部環境的關系，如界面中的某個按鈕按下去時，可能産生新的界面、新的按鈕、或者調用其他軟體硬體完成某些功能。自頂向下，把這些界面及涉及到的資料描述清楚，就是一份不錯的需求。

4、與其他項目小組成員共同協作、持續完善系統需求

需求文檔完成之後，并不是萬事大吉，把它扔給後面的設計人員就了事了。作為項目幹系人之内的項目組其他成員，對需求的有效性也起到某種程度的驗證作用。雖然軟體項目的生命周期按照各種開發模型有不同階段的劃分，但每個階段的結束不是簡單地把階段工作成果塞給下一階段的成員就可以了。特别是高科技的軟體開發項目，上一階段的工作成果往往要通過多次的溝通才能更為清晰地被下一階段成員接受，其有效性、合理性也要被下一階段的工作所檢驗，通過檢驗有時也有必要對上一階段的工作結果進行相應的調整，需求更是如此。是以，無論是同一階段不同人員之間，或是不同階段人員之間都應根據需要互相協作，互相配合，共同完成軟體開發任務。

參考文獻：

《實用軟體工程》第二版，鄭人傑、殷人昆、陶永雷等著

《微軟項目：求生法則》Steve McConnell著，餘孟學譯

《軟體需求》Soren Lauesen著，劉曉晖譯

《軟體工程：實踐者的研究方法》（第5版）Roger S.Pressman著