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

zhengwenping發表於2018-11-10

需求用例規約成功運用於門戶專案

用例規約指的是使用用例建模技術幫助描述系統模型,它是描述使用者功能性需求的一種方法。用例建模技術的定義如圖 1-16 所示。

1-16  用例建模技術的定義

用例建模技術關注以下幾個步驟。

找出系統中所有的參與者,也就是在這套系統上線之後,誰可能會點選滑鼠或者按動鍵盤。示意圖如圖1-17所示。

1-17   用例建模技術第 1 步:必須找出參與者

    如果參與者不好發現,那麼我們從以下方面進行分析(見圖 1-18 )。

1-18   確定參與者的秘訣

對所有的參與者進行用例分析,確定每個參與者可能的活動或者需要,對他們的活動場所和可能的活動目標進行定義並分類,每個包含獨立目標的活動就是一個用例。我們可以從以下方面進行分析(見圖 1-19 )。

1-19   找出參與者的用例的方法

 ③ 對每個用例進行描述和介面原型設計(見圖 1-20 )。


1-20   如何描述用例

對使用者在這個活動中的所有操作進行定義和規約,例如可能的意外活動。舉個例子:使用銀聯卡在 ATM 上取款的操作,就可以這樣描述(見圖 1-21 )。

1-21   使用者使用 ATM 的用例規約示例

客戶身份驗證的場景定義,如圖 1-22 所示。


1-22   定義客戶使用 ATM 的特殊需求

使用該技術,可以保證系統需求調研人員真正掌握使用者的需求,開發人員不會遺漏需求,同時為測試人員設計測試用例提供輸入。

需求調研過程組織

    門戶專案涉及的部門、領導、使用者之多,也是空前的,沒有任何一個專案能像門戶一樣涉及企業內幾乎每一個人。從上一章的講解中我們知道,企業門戶專案實施方法論中非常強調門戶系統的整體規劃。

1-23  門戶專案方法論

而需求調研是規劃來源的根本,所以需求調研是個非常重要的階段。也正因為如此,企業門戶專案需求調研階段的組織非常考驗一個專案組的能力。

需求調研交付的是需求規格說明書(含系統原型),它主要由圖 1-24 所示的幾個因素決定。

本節著重介紹如何有序地組織門戶專案的需求調研,使專案組快速、有序、保質保量地完成需求調研階段,準確拿到使用者需求,避免後期需求發生變化,降低專案風險,提高門戶專案實的施質量。

需求調研,顧名思義,就是調查和研究客戶的想法,瞭解使用者需要一個什麼樣的系統。需求調研非常重要,因為:

1 需求調研是為需求規格說明書做前期工作,可以說需求規格說明書是從需求調研表中得到或抽取出來的。

2 需求調研是要了解現實世界中做實際工作的人真正需要什麼樣的程式的過程,再把這些需求改進細節整理出來由設計部實現。


1-24  軟體需求規格的決定因素

  大致來說,以下幾項工作是必須按照順序認真組織的。

 ① 確定我們的目標和需求調研的目標(見圖 1-25 )。

1-25  確定目標

 ② 做足充分的準備工作,包括人員的組織、統一思想的培訓等(見圖 1-26 )。

   ③ 確定關鍵使用者,對需要訪談的人制定詳細的、確定的訪談計劃表(見圖 1-27 )。

1-26  做足充分的準備工作

1-27  訪談計劃表


 ④ 初步制定欄目列表明細,並結合簡要描述,提前下發給各部門,讓他們提前知道要談話的內容(見圖 1-28 )。

 ⑤ 針對每個部門制定一個訪談提綱,以便在談話過程中查漏補缺(見圖 1-29 )。

1-28   欄目列表明細

圖1 -29   訪談提綱

 ⑥ 客戶訪談。做客戶訪談時要把握以下幾個問題。

1 客戶想要什麼?

認真傾聽客戶說話,因為客戶在說的時候,他多半同時在想自己要什麼東西。客戶說完了,輪到我們了,首先複述客戶需求,在複述的同時我們就可以發表建議了。此時態度要把握好,要把客戶的需求合理化、簡單化,說白了就是程式別太複雜,風險能排除就全排除掉,別搞個邏輯既複雜又不實用的東西出來。

2 客戶要這幹什麼用?

聽完客戶的所有需求後,提煉出客戶所要東西的重點,圍繞重點開始研究,複述客戶的需求。做事千萬別說: 我以為 。別怕麻煩,現在多說幾遍大家都還客氣,比以後大家對需求有爭執強。

3 他為什麼這麼想?

需求客戶大多不是 IT 專家,而是行業專家,至少對本公司的行業流程比較清楚,所以我們就需要搞清楚客戶的行業流程或者說業務邏輯,看看客戶到底想讓我們用程式為他們實現什麼功能,他們要幹什麼。

4 會不會有別的想法?

 需求的不少關鍵問題,透過了解其具體想要幹什麼就很容易地化解掉了。

  客戶需求的梳理。注意區分清楚什麼是強勢客戶,什麼是強權客戶,從而識別出真正的客戶。

  跟領導溝通的語言技巧。務必明確我們說出的每一句話,目的是使對方明確我們有什麼意思,同時也要清楚地使對方明確我們沒有什麼意思,以避免惹來不必要的麻煩。

  堅持 “重視領導”的思路。我們知道這麼大型的專案離不開領導的支援,領導越重視這個專案,我們就越接近成功。但是,如果領導就是不重視怎麼辦?絕招是:我們要首先“重視領導”。用“重視領導”換取“領導重視”,正如我們要做一個“使用者要用”而不是“領導要使用者使用”的系統一樣(見圖 1-30 )。

1-30  堅持“重視領導”的思路

 ⑩ 訪談結束後,當天要梳理訪談內容,寫成用例規約,並清晰地知道每一個用例(見 1-31 )。

1-31   用例圖

 ⑪ 彙總成需求用例規約說明書(見圖 1-32 )。

1-32   需求用例規約說明書

    ⑫最後,也是最重要的一點:記得把握需求底線(見圖 1-33 )。門戶專案很容易做大,而且是大得沒邊沒界。如果需求沒有底線,投入將無法計算,而這,不是我們想要的。

1-33   把握需求底線

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/9116427/viewspace-2219360/,如需轉載,請註明出處,否則將追究法律責任。

相關文章