用例驅動的需求過程實踐

2021-09-09 02:49:39 字數 1799 閱讀 6092

根據筆者多年來從事軟體需求捕獲、分析工作的實踐經驗,認為造成這一現象的根本原因在於客戶與開發人員之間的溝通存在障礙,雙方都以自己的角度、自己的專業術語進行溝通,這使得大家並不能夠很好地就軟體需求達成共識。

由於幫助客戶更好地利用資訊化工具提高工作效率,是我們軟體開發團隊的責任,因此我們沒有權利讓使用者理解我們所用的語言,而是反過來,我們有義務去理解使用者的語言,站在使用者的角度看問題。

而事實上,許多開發團隊經常抱怨"我們的客戶連需求都說不清楚"、"我們的客戶對計算機了解太少了"。多年以來,大家都習慣從自己的角度來定義、分析問題,這也就造成了軟體行業成為了乙個最缺乏信任的行業,我們需要改一下習慣了。

二、現代需求實踐

針對這些現象,許多先賢們開始了實踐,並且總結出了一系列優秀的需求實踐:

1)use case:用例分析技術

鼎鼎大名的rup是這樣總結自己的:用例驅動,以體系結構為中心,迭代、增量的開發過程。use case也伴隨著rup、uml一起名揚天下。

用例用來描繪乙個系統外在可見的需求情況,是代表系統中各個專案相關人員(風險承擔人,stakeholder)之間就系統的行為所達成的契約。

2)user story:使用者故事、使用者素材

使用者故事是kent beck在極限程式設計(xp)方**中推薦的最佳實踐之一。它由客戶參與編寫,說明他們需要系統為他們做什麼,一般用客戶的術語寫就,三句話左右。

3)feature:特徵

這是特徵驅動開發(fdd)方**的核心實踐之一。乙個特徵就是乙個小的,具有客戶價值的功能,通常表示為。

從上面的定義來看,這三種現代軟體工程需求實踐無一例外地遵從兩個原則:一是站在使用者的角度看待系統、定義系統;二是用使用者看得懂的語言表達。而在筆者的實踐中,鑑於以下兩點考慮還是先在團隊中應用了"用例分析技術":

1)使用者故事略顯粗糙,掌握起來需要經驗,沒有詳細的規則用於按部就班,一開始採用容易迷失方向;而用例相對來說更加形式化,易於上手;

2)特徵看上去很有吸引力,但畢竟相關的理論還未完整,引入團隊實踐有些困難。

三、用例分析技術簡介

在使用用例分析技術時,很多人都覺得如何確定用例的粒度是乙個難點,而且感覺到用例沒有什麼規則遵從,甚至有無所適從的感覺。正如cockburn先生提出的學習用例分析技術的"守、破、離"的三個階段:

1)守:練習基本功夫,遵循規則,照章行事;

2)破:能突破傳統,因地制宜地靈活應用; 3)離:超脫任何招式與規則,達到無招勝有招的境界。

但用例分析技術卻讓第一階段的初學者感到無法很快地掌握。而其所著"編寫有效用例"則想為用例分析技術補充規則,讓大家能夠更好地掌握。

cockburn先生在ivar jacobson的基礎上,做了一些補充:

1)用例是契約,是系統與涉眾之間達成的契約。也就是將用例朝著形式化的方向發展;

2) 將用例分成**:

◆ 概要級:包括多個使用者目標(顯示使用者目標執行的語境,顯示相關目標的生命週期、為低層用例提供乙個目錄表);

◆ 使用者目標級

◆ 子功能級

不過,對於cockburn先生的貢獻,用例始祖ivar大師並未做出任何反應。本人在實踐中認為,cockburn先生的思路與理念對於初學用例分析技術的人來說,十分有價值,使得用例分析技術更具操作性,當其同時也有點畫地為牢的感覺,也許cockburn先生也意識到這點,因此第三階段就是"離",沒有規則,按需靈活使用。

五、如何在開發過程中應用用例分析技術

在使用中要注意:

1)用例源於涉眾,請不要自己杜撰出用例;

2)用例的事件流的編寫過程中,應充分加入團隊的參與;

3)雖然用例源於涉眾,但不要企圖向他們直接問"你還有什麼用例?這樣的問題。

試析RUP以用例驅動的需求管理

試析rup以用例驅動的需求管理 rup是rational統一過程 rational unified process 的簡稱,它是rational公司 現歸屬ibm公司 推出的一種軟體過程產品。從軟體過程模式角度看,rup又是一種典型的軟體過程模式,它以迭代增量式 架構為中心 用例驅動的軟體開發方法為...

試析RUP以用例驅動的需求管理

試析rup以用例驅動的需求管理 rup是rational統一過程 rational unified process 的簡稱,它是rational公司 現歸屬ibm公司 推出的一種軟體過程產品。從軟體過程模式角度看,rup又是一種典型的軟體過程模式,它以迭代增量式 架構為中心 用例驅動的軟體開發方法為...

需求的細化方法之用例驅動

在專案啟動階段,您是否遇到過這樣的問題呢?專案啟動的時候,只給你一本巨厚無比的標書,不知道從何下手。認真的看了一遍標書之後,只知道要做的是什麼,卻不知道如何推進。從標書上無法對任務進行細化。團隊的人不知道該如何分配任務。盡量將所有的資訊以紙質的形式列印出來,貼到白板或者牆上,以便大家隨時查閱。思考測...