企業門戶項目需求調研指南

由於企業門戶技術對大多數企業或用戶來說是陌生的，所以企業門戶項目的需求調研採用的工作方法有別於傳統的項目。在實際的實施中通常採用兩種方法。

第一，原型建模方法。即：構建一個HTML版本的界面與操作原型，引導用戶嘗試操作，在操作中發現問題，然後不斷完善。注意：在執行該方法的過程中，很多項目組偷懶了，採用JPG靜態圖片的方法來代替操作原型，這是很不可取的。門戶技術對用戶來說本來就陌生，單純使用靜態的幾個圖片根本引導不出用戶的真實想法。等到項目開發差不多了，用戶試用時纔會發現問題，所以很多項目組抱怨：門戶項目難做，因爲用戶需求多變。實際上並不是用戶需求多變，而是一開始就沒有把用戶需求引導出來。本文會詳細介紹門戶系統的原型建模方法。

第二，需求用例。通常，人們認爲撰寫需求用例是個比較複雜的工作，所以這種需求調研方法應該只用於大型項目。錯了！門戶中的功能點本來就繁瑣，如果不用用例規約定義清楚，用戶根本沒法理解你的需求描述。毫無疑問，不採用用例規約，你壓根就不會拿到用戶的真實需求。本文會詳細介紹如何使用需求用例規約方法來撰寫門戶項目的用戶需求描述。

另外，門戶項目涉及的部門、領導、用戶之多，也是空前的，沒有任何一個項目能像門戶一樣涉及企業內幾乎每一個人，所以企業門戶項目需求調研階段的組織非常考驗一個項目組的能力。本文會着重介紹如何有序地組織門戶項目的需求調研，使項目組快速、有序、保質保量地完成需求調研階段，準確地拿到用戶需求，避免後期需求發生變化，降低項目風險，提高門戶項目的實施質量。

衆所周知，很多軟件項目尤其是大型的集成類項目，由於涉及的部門很多，涉及的應用系統很多、數據庫很多，需求多種多樣，故而需求調研和確認非常重要，甚至直接決定整個項目的成敗。

爲了透徹瞭解需求，確認用戶的需要，我們經過多年的積累，總結出一二三，如圖1-1所示。

圖1-1　項目需求調研階段堅持的核心理念與思想

一個核心

一個核心思想指的是我們考慮需求的時候，除了把自己當做用戶來親自使用這套系統外，還要拋開其他的利益衝突，例如，任何人都不要擔心引導並擴展了用戶需求後，是不是增加了自己的工作量。我認爲，用戶的利益纔是第一位的，需求的擴展帶來的技術變更始終不是問題。我們現在多一點點的付出，可以給用戶將來的使用增加無窮的樂趣。

兩項基本原則

第一項基本原則是重點關注最關鍵用戶的關注點。如果不是用戶關心和需要我們解決的問題，即使投入再多的精力其結果也是事倍功半，我們的效率與用戶的成本息息相關。我們把精力聚焦於用戶最關心的問題、用戶最頭疼的事情、用戶最需要我們解決的問題，是在節省我們的成本，更是在節省用戶的成本。一個講求效率和成本的項目組，相信是所有用戶都需要的。

第二項基本原則是變用戶“我想要的”爲“我需要的”。在一些需求複雜的項目尤其是大型的門戶集成項目中，用戶往往表達不清楚自己的軟件需求，他們只能從自己的業務角度講想要什麼，但是他們想要的東西離真正的軟件需求與設計還有很大的距離。我們需要藉助大量的項目經驗，循循善誘，將用戶想要的東西表達清楚，然後轉換成軟件需求，並製作系統原型，給用戶確認。在用戶使用了系統原型並提出意見後，我們來修正需求理解和系統模型，並對需求描述進行迭代。經過多輪、多層次的需求迭代，讓每個用戶都滿意後，基本上可以達到最大程度地理解和掌握用戶的真正需求，保證軟件下階段的設計工作接近用戶的實際需要，從而保證整個項目的成功。

三個基礎方法

第一個基礎方法是原型建模迭代技術。

第二個基礎方法是基於用例規約的需求調研方法。

第三個方法是足夠多的用戶參與、培訓。

對於以上三個方法，下面將分別進行詳細描述。

門戶的原型建模方法

系統需求建模的意思是根據用例規約生成的各種場景，彙總成一個一體化的綜合需求描述，並由用戶交互接口設計師（美工）製作翔實的HTML版本的系統模擬，然後請用戶嘗試使用。這種原型建模要高於傳統的界面設計，更高於效果圖，它在最大程度上接近於用戶最終使用的系統，有助於用戶理解和了解將來的系統功能，及時提出不符合要求的操作點。

本節介紹如何使用Portal建模工具開發一個需求引導與功能確認模型。這個模型的目的是用於啓發用戶思維，引導用戶需求，經過多輪的修正與優化後，再用於用戶確認功能需求。

這需要在Eclipse中安裝一個插件，安裝完成後，啓動Eclipse，執行以下步驟。

①創建一個工程，如圖1-2所示。