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

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

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

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

眾所周知，很多軟體專案尤其是大型的整合類專案，由於涉及的部門很多，涉及的應用系統很多、資料庫很多，需求多種多樣，故而需求調研和確認非常重要，甚至直接決定整個專案的成敗。

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

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

一個核心

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

兩項基本原則

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

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

三個基礎方法

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

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

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

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

門戶的原型建模方法

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

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

這需要在 Eclipse 中安裝一個外掛，安裝完成後，啟動 Eclipse ，執行以下步驟。

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