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

關鍵字：專案干係人、需求、調研

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

造成上述現象的原因是系統分析人員沒有全面瞭解所有專案干係人的需求，並按照重要性優先順序進行權衡取捨。全面的需求來自所有專案干係人。專案干係人STAKEHOLDER也有的翻譯成利益關係人、利害關係人、利益干係人、利益共享者、涉眾，如此等等，即所有可能受到專案結果重大影響的人。專案干係人即可能是專案的受益者，也是專案的風險承擔者，甚至有可能是專案的受害者。專案干係人的需求包含明確的和隱含的，也可以分為NEED、WANT、WISH等不同層次。

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

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

1、儘快熟悉專案干係人全貌

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

熟悉建設單位內部相關部門的業務劃分及它們之間的相互關係,為功能分析準備了必要的資料, 同時可以熟悉使用者方的各類人員，並及時進行廣泛、有效的溝通與交流。特別要與客戶方業務與技術的規劃者和實際使用者進行深入探討，收集必要的原始資料，保證需求調查的完整性、正確性。
建設單位只是專案干係人中的一部分（當然是主要的部分），為了更好地瞭解專案干係人全貌，還應當在建設單位組織結構圖基礎上全體專案干係人結構圖，以便更好更全面地進行需求調研分析。

2、詳細描述各項業務，以利於讓所有客戶確認

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

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

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

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

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

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

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

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

需求調研分析中的專案干係人概念（轉）

相關文章