1. 程式人生 > >企業門戶專案需求調研指南

企業門戶專案需求調研指南

企業門戶專案需求調研指南

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

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

本文會詳細介紹門戶系統的原型建模方法。

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

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

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

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

微信圖片_20181109141757.png

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

一個核心

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

兩項基本原則

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

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

三個基礎方法

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

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

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

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

門戶的原型建模方法

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

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

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

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

圖片21.png

1-2 建立工程

 選擇工程型別為:Portal模型工程,如圖1-3所示。

圖片22.png

1-3 選擇工程型別

 Portal原型建模工程命名,如圖1-4所示。

圖片23.png

1-4 為Portal原型建模工程命名

 定義第一個角色:匿名使用者組,如圖1-5所示。

圖片24.png


1-5 定義第一個角色

 建立其他角色,每個角色代表一個使用者群組,具有獨立的許可權,例如財務部門使用者組、人力資源部門使用者組、集團領導使用者組等,如圖1-6所示。

圖片25.png

1-6 建立其他角色

 輸入該角色的屬性,並建立更多的角色,如圖1-7所示。

圖片26.png

1-7 輸入角色屬性

 為各個角色建立一級、二級、三級導航選單。其中,Place為一級選單,Page為二級選單,Subpage為三級選單,如圖1-8所示。

 從左邊的導航欄裡找到並複製各個Portlet,如圖1-9所示。

圖片27.png

1-8 為各個角色建立導航選單

圖片28.png

1-9 複製Portlet

 使用HTML語法和XML語法(xlst)為每個Portlet編寫內容,如圖1-10所示。支援文字、表格、圖片、JavaScript事件等,頁面或頁面之間可以有複雜的邏輯。

圖片29.png

1-10 為每個Portlet編寫內容

 為每個角色的各個頁面編排佈局,排放Portlet,如圖1-11所示。其中Panel為列,每個頁面上放置幾個Panel就是安排幾列。為每個Portlet指定名稱和Portlet原始碼包。

圖片30.png

1-11 編排佈局,排放Portlet

 wem檔案焦點下,編譯工程,如圖1-12所示。

圖片31.png

1-12  編輯工程

   開啟或拷貝output資料夾,點選index.htm,即可開啟原型,預設介面為所有的角色,如圖1-13所示。

選擇所要使用的角色,可進入該角色的編排頁面,如圖1-14所示。

圖片32.png

1-13  原型介面

圖片33.png

1-14  進入編排頁面

 為了增強演示效果,可以新增一個批處理檔案,命名為“開始演示.bat”,內容如圖1-15所示。

圖片34.png

1-15  批處理檔案內容

 讓使用者用模型,提出意見,根據使用者意見多次迭代、優化模型,直至使用者徹底認可。

至此,原型建模完成。結合下一節將要介紹的用例規約撰寫,讓使用者非常清晰地知道你要把門戶系統設計成什麼樣子,以便達成一致認識。