人機協(xié)作的用戶故事場景提取與迭代演進*

王春暉,金 芝,趙海燕,劉 璘,張 偉,崔牧原

1(北京大學(xué) 信息科學(xué)技術(shù)學(xué)院,北京 100871)

2(高可信軟件技術(shù)教育部重點實驗室(北京大學(xué)),北京 100871)

3(清華大學(xué) 軟件學(xué)院,北京 100084)

4(內(nèi)蒙古師范大學(xué) 計算機科學(xué)技術(shù)學(xué)院,內(nèi)蒙古 呼和浩特 010022)

軟件開發(fā)過程中,需求很難一次性完整獲得,而且也會頻繁發(fā)生變更.傳統(tǒng)方法試圖在開發(fā)前完成并確認整個需求文檔,但這樣開發(fā)出的軟件產(chǎn)品常常因不滿足用戶需要而使項目以失敗告終[1].敏捷方法注重領(lǐng)域用戶與開發(fā)團隊的頻繁交互,能夠快速響應(yīng)需求變化,在較短的時間內(nèi)開發(fā)出滿足用戶需求的軟件產(chǎn)品[2].但開發(fā)者如何能夠準確理解領(lǐng)域用戶需求并有效地維護和管理需求變更,仍然是困擾敏捷開發(fā)團隊的難題.

一方面,在敏捷方法中,用戶故事是領(lǐng)域用戶表達需求的最主要方式,該種方式只對意圖進行簡短說明[3],需要開發(fā)者與領(lǐng)域用戶進一步溝通,以形成系統(tǒng)功能說明.另一方面,在發(fā)布規(guī)劃時[3](規(guī)劃迭代開發(fā)選擇的用戶故事,確定項目時間表),需要根據(jù)領(lǐng)域用戶對特定功能特征的急切程度以及用戶故事間的關(guān)系排列用戶故事的優(yōu)先級.目前,一般通過領(lǐng)域用戶與開發(fā)者之間的反復(fù)交流和討論,建立起用戶故事索引表,人工梳理故事間的關(guān)系[1-3].大型軟件開發(fā)一般會產(chǎn)生大量用戶故事,每天都出現(xiàn)大量的新增需求,比如百度公司每天新增需求卡片近6 700 個[4].用戶故事間的關(guān)系可能錯綜復(fù)雜,它們常常重復(fù)和不一致.建立起完整的故事關(guān)系,特別是建立新增的和已有的用戶故事間的關(guān)系非常困難.如果能有一種(半)自動化的手段幫助處理用戶故事文檔,進行需求抽取以及關(guān)聯(lián)關(guān)系挖掘,將有可能輔助實現(xiàn)高效的用戶故事管理.

為了降低敏捷團隊成員間溝通和理解的困難程度,領(lǐng)域用戶可以描述更多的系統(tǒng)行為,以方便開發(fā)者確定系統(tǒng)功能.行為驅(qū)動的敏捷方法[5,6]提出使用場景(scenario)更細粒度的描述用戶故事,表達用戶故事在不同狀況下的系統(tǒng)活動,便于在開發(fā)前進行需求驗證及測試.場景描述了用戶故事在特定上下文中的結(jié)果.這種描述方法以領(lǐng)域用戶所希望的系統(tǒng)行為出發(fā),引導(dǎo)領(lǐng)域用戶提出需求.系統(tǒng)行為源于待開發(fā)軟件產(chǎn)品的業(yè)務(wù)結(jié)果,表明,為了達成業(yè)務(wù)結(jié)果應(yīng)該如何去做.因而,容易被領(lǐng)域用戶接受.同時,在場景中關(guān)注目標系統(tǒng)的細粒度行為需求,更容易被開發(fā)者理解和實現(xiàn).

一個軟件系統(tǒng)通常有很多用戶故事,需要一種有效的方式將這些用戶故事組織在一起,建立用戶故事之間的關(guān)系,形成對未來系統(tǒng)的整體需求[7,8].目前已有一些整合用戶故事的方法[9-11],它們通過建立用戶故事與需求模型之間的映射,實現(xiàn)從一組用戶故事到需求模型的轉(zhuǎn)換,包括從用戶故事到Use-Case 模型[12]、業(yè)務(wù)流模型[10]以及目標模型[11]等的轉(zhuǎn)換.也有方法借助自然語言分析技術(shù)自動地從用戶故事中提取概念模型,并檢查需求的完整性[9,13,14].但是由于自然語言描述本身的二義性及用戶故事描述的不規(guī)范,全自動的模型轉(zhuǎn)換非常困難.目前,大多數(shù)方法都僅提供模型編輯工具,輔助模型生成[9-12]等.

敏捷開發(fā)過程中,需求并不是事先定義好的,而是通過利益相關(guān)者之間的頻繁交互,隨著迭代開發(fā)過程逐步變得清晰[1-3,15,16].在每個迭代周期結(jié)束時,領(lǐng)域用戶根據(jù)對已實現(xiàn)功能的測試及評估結(jié)果提出需求變更申請,主要包括添加或刪除功能或修改已實現(xiàn)的功能.變更的功能(用戶故事)應(yīng)該快速地融合到系統(tǒng)需求模型中,以實現(xiàn)模型的快速更新,還需要檢查更新的需求與前期版本需求是否存在沖突[17].目前,用戶故事管理的辦法主要是建立用戶故事列表和索引卡,人工分析用戶故事的變化[3]以及變更的成本和風(fēng)險.有的研究通過分析多個連續(xù)版本的需求文檔來評估需求變更的風(fēng)險[18,19],也有的研究提供輔助平臺,借助相關(guān)領(lǐng)域知識幫助管理需求演進[20].

本文提出一種敏捷需求工程場景下的人機協(xié)作式用戶故事理解和系統(tǒng)功能需求獲取方法.該方法提出帶場景的用戶故事表示,當領(lǐng)域用戶提交一組用戶故事后,可根據(jù)用戶故事元模型,借助用戶故事模板以及句法規(guī)則,采用自然語言分析技術(shù),進行用戶故事的特征抽取和功能表達.提出基于用戶故事概念關(guān)系推理規(guī)則的用戶故事關(guān)系挖掘,識別用戶故事間的合作關(guān)系、執(zhí)行依賴關(guān)系以及近義關(guān)系.經(jīng)過領(lǐng)域用戶的確認,獲得用戶故事間的關(guān)系,生成系統(tǒng)功能場景.出現(xiàn)用戶故事更新請求時,可借助系統(tǒng)功能場景,交互式地更新系統(tǒng)需求.案例研究展示了方法的可行性.

本文第1 節(jié)介紹方法的整體框架.第2 節(jié)介紹用戶故事和系統(tǒng)功能場景的概念模型.第3 節(jié)介紹用戶故事場景抽取.第4 節(jié)介紹用戶故事關(guān)系挖掘及沖突檢查,以及系統(tǒng)功能場景的生成與更新.第5 節(jié)通過一個含有24 個用戶故事、57 個場景的在線購物系統(tǒng)實驗案例,驗證本文方法的可行性.第6 節(jié)介紹相關(guān)工作.最后是結(jié)語和展望.

1 整體框架

人機協(xié)作的系統(tǒng)功能需求管理方法,主要包括用戶故事功能場景抽取、系統(tǒng)功能場景構(gòu)建以及用戶故事場景更新3 部分工作,整體工作流程框架如圖1 所示.

Fig.1 The framework for elicitation and evolution of user stories with scenarios圖1 用戶故事場景抽取與迭代演進整體框架

用戶故事功能場景抽取以帶有場景的用戶故事為輸入,使用自然語言分析方法,抽取功能場景的結(jié)構(gòu)化模型表示,得到功能場景表示.首先,借助用戶故事模板提取帶場景的用戶故事的字段信息,得到帶故事語義標簽的結(jié)構(gòu)化文檔,稱為故事結(jié)構(gòu)文檔.然后,應(yīng)用抽取規(guī)則,從故事結(jié)構(gòu)文檔中抽取功能場景表示,包括故事描述、場景以及功能特征屬性集3 個部分.其中,故事描述部分記錄了故事名字以及角色、意圖等.從故事結(jié)構(gòu)文檔的對應(yīng)存儲字段抽取.場景部分描述故事的意圖達成,表達為在具體的上下文(即用一組業(yè)務(wù)實體屬性的取值表示的狀態(tài)集)中,當某個事件發(fā)生時,意圖達成的結(jié)果(即新的狀態(tài)集).這樣,場景實際上就是從一個狀態(tài)集出發(fā),經(jīng)過事件,達到結(jié)果狀態(tài)集,這稱為一個狀態(tài)變遷.一個用戶故事的意圖是否達成,可能有多種情況.所以,一個用戶故事可能有多個場景.一個用戶故事中的所有場景組成一個狀態(tài)變遷集.應(yīng)用狀態(tài)合并規(guī)則,合并狀態(tài)變遷集,生成狀態(tài)變遷圖.從狀態(tài)變遷集中提取反映意圖達成所需要的系統(tǒng)功能相關(guān)的業(yè)務(wù)實體屬性,得到功能特征屬性集.故事描述、功能特征屬性集以及狀態(tài)變遷圖組合在一起,形成一個用戶故事的功能場景表示.

系統(tǒng)功能場景構(gòu)建以一組帶場景的用戶故事為輸入,通過功能場景的整合,形成系統(tǒng)用戶故事需求.首先,從用戶故事集中抽取用戶故事功能場景,得到具有故事描述、功能特征屬性集及狀態(tài)變遷圖的功能場景表示,稱為功能特征節(jié)點.這樣,用戶故事集就表達為一組功能特征節(jié)點.其次,通過和領(lǐng)域用戶交互確定用戶故事之間的關(guān)系,分為合作關(guān)系、執(zhí)行依賴關(guān)系以及近義關(guān)系3 類,通過相應(yīng)的推理規(guī)則計算用戶故事間關(guān)系的關(guān)聯(lián)強度,將存在較強關(guān)聯(lián)的用戶故事對作為候選關(guān)系集推薦給領(lǐng)域用戶.領(lǐng)域用戶確認后,得到用戶故事間的關(guān)系集.對存在近義關(guān)系的用戶故事要進行沖突檢查(語義冗余或不一致).在沒有沖突發(fā)生的情況下,用戶故事間的關(guān)系將功能特征節(jié)點連接起來,形成系統(tǒng)功能場景.

用戶故事場景更新以用戶提交的更新和當前版本的系統(tǒng)功能場景為輸入,根據(jù)不同的更新請求,交互式地進行需求的更新,得到系統(tǒng)功能場景的更新.更新操作包括添加新用戶故事、刪除和修改已有用戶故事.增加新用戶故事需要領(lǐng)域用戶提供一個帶場景的故事,通過執(zhí)行用戶故事場景抽取創(chuàng)建新的功能特征節(jié)點,在當前版本的系統(tǒng)功能場景中尋找可能與它相關(guān)的片段,進行依賴關(guān)系識別,確定新用戶故事在當前版本系統(tǒng)功能場景中的位置及關(guān)聯(lián)關(guān)系,這個過程也需要領(lǐng)域用戶的參與.然后進行沖突檢查,如果沒有沖突,則插入新故事.刪除用戶故事首先需要領(lǐng)域用戶輸入要刪除用戶故事的關(guān)鍵信息,然后在當前版本系統(tǒng)功能場景中進行用戶故事檢索,以確定要刪除的故事及其關(guān)系.最后刪除該用戶故事并修正其他用戶故事之間的關(guān)系.修改已有用戶故事首先要在當前版本系統(tǒng)功能場景中檢索用戶故事定位要更新部分,然后修改用戶故事文檔,得到修改的用戶故事.最后,再將這個用戶故事作為新的故事文檔添加到系統(tǒng)功能場景中.

圖1 給出的方法整體框架,蘊含著以下3 個方面的問題.

(1)系統(tǒng)功能場景的表示.系統(tǒng)功能場景刻畫了帶場景的用戶故事的結(jié)構(gòu)化表示以及用戶故事之間的關(guān)系.系統(tǒng)功能場景實際上是系統(tǒng)的功能模型,基于系統(tǒng)功能場景的用戶故事管理是一種模型驅(qū)動的管理,它直接制導(dǎo)了用戶故事功能抽取、整合和更新.第2 節(jié)將對此給予重點介紹.

(2)用戶故事場景抽取.這是指根據(jù)帶場景的用戶故事構(gòu)造系統(tǒng)功能場景中的功能特征節(jié)點,具有故事描述、功能特征屬性集以及狀態(tài)變遷圖3 個屬性.它是生成系統(tǒng)功能場景和實現(xiàn)更新管理的基礎(chǔ).本文借助自然語言分析技術(shù)和故事特征句法規(guī)則,從用戶故事文檔中構(gòu)建功能特征節(jié)點.這方面的內(nèi)容將在第3 節(jié)加以介紹.

(3)系統(tǒng)功能場景的生成與更新.建立用戶故事間的關(guān)系是生成和管理系統(tǒng)功能場景的關(guān)鍵.由于用戶故事都是獨立提交的,其中并沒有顯式表達和其他用戶故事的關(guān)系,如何輔助領(lǐng)域用戶快速識別用戶故事間的關(guān)聯(lián),并檢查用戶故事之間的沖突,成為關(guān)鍵.第4 節(jié)將主要討論這一問題.

2 用戶故事及系統(tǒng)功能場景的概念模型

領(lǐng)域用戶采用用戶故事描述他們對軟件系統(tǒng)的需求.講述作為一個特定角色的使用者,需要什么功能,完成什么操作,帶來什么好處[3].為了對用戶故事進行細粒度的分析,提取其中的功能需求,可以進一步引入場景描述.即用戶故事包括至少一個場景,表達用戶故事發(fā)生的實例.另一方面,系統(tǒng)功能場景則站在未來軟件系統(tǒng)的角度表達系統(tǒng)應(yīng)該具有的功能及完成的操作.本節(jié)通過ATM 機系統(tǒng)的案例介紹帶場景的用戶故事描述以及系統(tǒng)功能場景的概念模型.

2.1 帶場景的用戶故事

帶場景的用戶故事包括故事描述及場景.故事描述包括故事名、角色、意圖以及收益.場景包括場景名、上下文、事件以及結(jié)果.一個用戶故事可以包括一個或多個場景.其描述模板及其概念元素層次關(guān)系如圖2所示.

Fig.2 The template and the hierarchical relation of elements in user-story description document圖2 帶場景的用戶故事描述模板及其概念元素層次關(guān)系

故事名一般以短句概括用戶故事的功能.角色表示誰將使用這個功能,意圖表示角色希望系統(tǒng)提供什么樣的功能,收益表達了系統(tǒng)實現(xiàn)該功能后的好處.場景描述了用戶故事在特定上下文中,發(fā)生某個事件而產(chǎn)生的結(jié)果.上下文和結(jié)果一般描述與功能相關(guān)的業(yè)務(wù)實體(屬性)的某種取值,體現(xiàn)了功能業(yè)務(wù)的狀態(tài)特性,用一個描述狀態(tài)(實體-屬性-值)的短句表達,分別用關(guān)鍵字Given 和Then 連接.當上下文或結(jié)果涉及多個狀態(tài)表達時,將每個狀態(tài)描述短句分開,并用and 連接.上下文和結(jié)果之間的切換是由于發(fā)生某個事件(如動作或條件達成),事件用關(guān)鍵詞When 連接.

表1 描述了持卡人在ATM 機上取現(xiàn)金的用戶故事.該用戶故事分3 個場景描述意圖是否達成:成功取款、卡余額不足不能取款和卡無效無法取款.取現(xiàn)金業(yè)務(wù)與賬號余額、卡是否驗證通過(是否是合法用戶)、取款金額以及ATM 機余額等實體屬性相關(guān),稱為與用戶故事功能(意圖)相關(guān)的功能特征屬性集.這些功能特征屬性在每個場景中實例化(取值),表示這些功能特征屬性處于“上下文”狀態(tài)下(前置狀態(tài)),由于某個事件發(fā)生,功能特征屬性處于“結(jié)果”狀態(tài)(后置狀態(tài)).如scenario1 前置狀態(tài)中描述的短句含義是:在賬號的余額是balance,卡被驗證通過且ATM 機有足夠的現(xiàn)金.事件是“持卡人取現(xiàn)金cash”.后置狀態(tài)描述的短句含義是:ATM 吐出現(xiàn)金,系統(tǒng)提示取款成功,賬號余額會修改.

Table 1 The user story for card holder withdrawn money表1 “持卡人取現(xiàn)金”用戶故事描述文檔

為了讓開發(fā)者能夠充分理解用戶故事中每段描述的含義.建議在每個關(guān)鍵詞后面使用規(guī)范的句型,見表2.

Table 2 Recommended pattern for a sentence followed by a key word in a user story表2 用戶故事場景自然語言描述關(guān)鍵詞后面對應(yīng)短句的推薦描述句型

2.2 系統(tǒng)功能場景

系統(tǒng)功能場景是一個由功能特征節(jié)點和關(guān)系組成的圖.系統(tǒng)功能場景的概念模型如圖3 所示.

Fig.3 The conceptual model of system feature-scenario圖3 系統(tǒng)功能場景的概念模型

每個功能特征節(jié)點有3 部分信息:故事描述、功能特征屬性集以及狀態(tài)變遷圖.故事描述包括故事名、角色、意圖以及收益.功能特征屬性集是一個由實體-屬性組成的集合.狀態(tài)變遷圖是多個場景的狀態(tài)變遷組織在一起的圖結(jié)構(gòu),每個狀態(tài)變遷從一個狀態(tài)轉(zhuǎn)換到另一個狀態(tài).其中,起始狀態(tài)是狀態(tài)圖的開始點,可以連接一個或多個組合狀態(tài).組合狀態(tài)可以作為前置狀態(tài)或后置狀態(tài),通過狀態(tài)變遷關(guān)聯(lián)起來.組合狀態(tài)中的每個原子狀態(tài)是功能特征屬性集中某個實體-屬性的實例(取某個值).

功能特征節(jié)點之間存在3 種關(guān)系:合作關(guān)系、執(zhí)行依賴關(guān)系和近義關(guān)系.合作關(guān)系表達一組故事通過合作共同達成一個較大規(guī)模的故事.執(zhí)行依賴關(guān)系表明一個故事的執(zhí)行依賴于另一個故事的實現(xiàn).近義關(guān)系表明故事可能具有相似的語義.合作關(guān)系和近義關(guān)系是雙向關(guān)系(互為合作關(guān)系或近義關(guān)系),一個功能特征節(jié)點可以沒有雙向關(guān)系或有多個雙向關(guān)系.執(zhí)行依賴關(guān)系是有向關(guān)系(一個功能特征節(jié)點X是另一個功能特征節(jié)點Y的前驅(qū),Y是X的后繼),一個功能特征節(jié)點可以不作為其他任何功能特征節(jié)點的前驅(qū)(后繼),也可以作為多個功能特征節(jié)點的前驅(qū)(后繼).

設(shè)實體、屬性、值、事件是系統(tǒng)的4 個基本數(shù)據(jù)集,分別表示為Entity、Attribute、Value、Event.實體具有名字及屬性,屬性包括名字及類型,事件描述動作或者某個條件(如系統(tǒng)所處狀態(tài))的發(fā)生.值是滿足屬性類型的數(shù)據(jù).對于圖3 所示概念模型中的元素,分別給出具體定義和形式化表示.

定義1.原子狀態(tài)S是一個三元組(entity,attribute,value),其中,entity∈Entity表示實體,attribute∈Attribute表示實體的屬性,value∈Value表示屬性的取值,也可以表達為entity.attribute=value,多個狀態(tài)形成一個狀態(tài)的集合states.

定義2.組合狀態(tài)S={s|s∈States},是一個原子狀態(tài)的集合.從場景上下文中提取的狀態(tài)稱為前置狀態(tài)(preState),從結(jié)果中提取的狀態(tài)稱為后置狀態(tài)(preState).

例如,表1 中scenario1 分別提取前置狀態(tài)S和后置狀態(tài)S′,S={(賬號.余額=balance),(卡.狀態(tài)=驗證通過),(ATM.現(xiàn)金儲備=enough)}(當描述狀態(tài)的短句中省略了屬性名詞時,則認為是某實體的“狀態(tài)”).S′={(賬號.余額=balance-cash),(卡.狀態(tài)=驗證通過),(ATM.現(xiàn)金儲備=enough)},(ATM.吐幣金額=cash)(系統(tǒng).提示信息=取款成功).

定義3.狀態(tài)變遷t是一個三元組(S,event,S′),其中,S是前置狀態(tài),S′是后置狀態(tài),event∈Event表示事件.表示從組合狀態(tài)S通過事件event變換到組合狀態(tài)S′.多個狀態(tài)變遷組成了一個狀態(tài)變遷的集合,表示為T.

狀態(tài)變遷描述了從一個前置狀態(tài)通過事件發(fā)生變化到后置狀態(tài)的過程.一個變遷的目標組合狀態(tài)可能是另一個狀態(tài)變遷的源組合狀態(tài),形成一個狀態(tài)序列,表示為

定義4.屬性集V={vi|i=1,2,…,K},是由K個實體-屬性v組成的集合,每個v是一個二元組(entity,attribute),表示一個實體的屬性,該屬性在不同的狀態(tài)會取不同的值.記為entity.attribute.

例如,表1 的scenario1,S的屬性集V={賬號.余額,卡.狀態(tài),ATM.現(xiàn)金儲備},S′的屬性集V′={賬號.余額,卡.狀態(tài),ATM.現(xiàn)金儲備,ATM.吐幣金額,系統(tǒng).提示信息}.

定義5.場景屬性集scenarioi.V=V∪V′(其中,V是場景scenarioi的前置狀態(tài)屬性集,V′是場景scenarioi的后置狀態(tài)屬性集).

例如表1 中場景scenario1 的屬性集scenario1.V=V∪V′={賬號.余額,卡.狀態(tài),ATM.現(xiàn)金儲備,ATM.吐幣金額,系統(tǒng).提示信息}.

場景狀態(tài)補齊:對照場景的屬性集,S和S′可能缺少個別屬性的狀態(tài)信息,例如S中沒有描述(ATM.吐幣金額)和(系統(tǒng).提示信息).為了保持一致,向S中添加這兩個屬性,并且賦一個NULL 值,表示對應(yīng)的實體-屬性取值不確定.如S補充屬性和值后變?yōu)镾={(賬號.余額=balance),(卡.狀態(tài)=驗證通過),(ATM.現(xiàn)金儲備=enough),(ATM.吐幣金額=NULL),(系統(tǒng).提示信息=NULL)}.

定義6.功能特征屬性集N表示一個用戶故事中場景的個數(shù).

狀態(tài)變遷圖生成:假設(shè)表1 中每個場景的前置狀態(tài)用Si表示,而后置狀態(tài)用表示,事件用eventi表示,則狀態(tài)序列集可表示為執(zhí)行場景狀態(tài)補齊,6 個組合狀態(tài)如圖4 左側(cè)部分所示.如果場景中的組合狀態(tài)用點表示,狀態(tài)之間的事件作為一條有標記的邊,合并相同狀態(tài),并添加一個起始狀態(tài)S0和空轉(zhuǎn)移的邊ε,連接每個狀態(tài)變遷的初始狀態(tài),這樣,狀態(tài)變遷集表達為一個連通的狀態(tài)變遷圖,如圖4 右側(cè)部分所示.

故事描述、功能特征屬性和狀態(tài)變遷圖是一個功能特征節(jié)點的3 部分.通過關(guān)系連接起來形成一個系統(tǒng)功能場景.

定義7.一個功能特征節(jié)點是一個三元組(U,V,G),U也是一個四元組(title,role,mean,benefit)表示節(jié)點的用戶故事,V表示功能特征屬性集,G表示狀態(tài)變遷圖.

定義8.系統(tǒng)功能場景是一個圖.用二元組(N,E)表示.

·N是節(jié)點的集合,系統(tǒng)功能場景中的節(jié)點n∈N,是一個功能特征節(jié)點.

·E是一個故事關(guān)系集合,系統(tǒng)功能場景的邊edge∈E,是一個三元組(n1,e,n2),表示節(jié)點n1到目標節(jié)點n2存在關(guān)系e.關(guān)系e有3 種類型:合作關(guān)系、執(zhí)行依賴關(guān)系和近義關(guān)系.執(zhí)行依賴關(guān)系有方向,而另外兩種關(guān)系沒有方向,表示兩個故事互相具有此種關(guān)系.

Fig.4 Function-scenario description of the cases in Table 1圖4 表1 案例功能場景表示

2.3 系統(tǒng)功能場景舉例

寫用戶故事一般從復(fù)雜用戶故事開始,即領(lǐng)域客戶先寫一個“大”用戶故事,表達相對宏觀的需求.然后通過分解用戶故事逐步使故事具體化,形成一些小故事[3].例如,ATM 自動取款機辦理業(yè)務(wù)是一個復(fù)雜的故事.表1 的例子講述了作為一個持卡人,在ATM 機上取款的故事.假設(shè)還包括另外兩個故事:持卡人驗證身份,持卡人查詢余額,詳見表3(省略了場景中的細節(jié)).

Table 3 The description of two sub user stories for ATM business表3 ATM 自動取款機業(yè)務(wù)的兩個子故事

持卡人取款、持卡人驗證身份和持卡人查詢余額,這3 個用戶故事具有相同的角色,都涉及賬號、卡狀態(tài)、ATM 機等領(lǐng)域概念,而且在In order to 描述字段中隱含了用戶故事之間的依賴關(guān)系.根據(jù)這些概念之間的聯(lián)系,可以發(fā)現(xiàn)這3 個用戶故事之間的關(guān)系,得到后文圖5 所示的系統(tǒng)功能場景圖.

3 用戶故事場景抽取

用戶故事場景抽取以一個帶場景的用戶故事為輸入,通過故事結(jié)構(gòu)文檔生成、狀態(tài)變遷提取、狀態(tài)變遷圖生成,將用戶故事表達為功能場景表示.本節(jié)介紹用戶故事場景抽取生成功能場景表示的過程.

3.1 故事結(jié)構(gòu)文檔生成

帶場景的用戶故事是一個有標簽的文檔,每個標簽后面的信息表達特定的語義,滿足表4 用戶故事文檔描述規(guī)約.

按照表4 規(guī)約從用戶故事提取字段信息,存放在故事結(jié)構(gòu)文檔.后文圖6 所示為表1 中用戶故事的結(jié)構(gòu)文檔表示.

Fig.5 An example of a feature-scenario圖5 系統(tǒng)功能場景示例

Table 4 The description rule of a user story表4 用戶故事文檔描述規(guī)約

3.2 狀態(tài)抽取與狀態(tài)變遷圖生成

為了生成狀態(tài)變遷圖以及提取功能特征屬性集,狀態(tài)(實體-屬性-值)首先從故事結(jié)構(gòu)文檔中“state”標簽后面的短句中提取.使用自然語言分析工具(HanLP[21]),對狀態(tài)描述語句進行分詞、詞性標注和依存句法分析,然后與句法模板(表2)匹配,根據(jù)匹配句型找出實體、屬性和值.例如,“賬號的余額是balance”與“名+名+是+名”狀態(tài)模式匹配,進而找出狀態(tài){賬號.余額=balance}.

從用戶故事中識別所有狀態(tài),并根據(jù)狀態(tài)表達語句的位置,分別存儲在preState 和postState 這兩個集合中.然后進行場景狀態(tài)補齊,得到統(tǒng)一的實體-屬性集,具體步驟如下.

·Step 1:從preState 和postState 中的每個狀態(tài)中提取實體-屬性,存儲到屬性集V和V′中.

·Step 2:取屬性集V和V′的并集,得到一個關(guān)于這個場景的屬性集scenario.V=V∪V′.

·Step 3:在preState 中補充實體-屬性scenario.V-V,并給scenario.V-V的實體-屬性賦NULL 值.在postState中補充實體-屬性scenario.V-V′,并給scenario.V-V′的實體-屬性賦NULL 值.

通過場景狀態(tài)補齊,preState 和postState 具有相同場景屬性集.提取event 字段信息,組成一個狀態(tài)變遷序列(preState,event,postState).

Fig.6 The json document of a user story in Table 1圖6 表1 故事結(jié)構(gòu)文檔json 文件(部分)

上述過程應(yīng)用于用戶故事的每一個場景,最終得到一個狀態(tài)變遷序列的集合.合并狀態(tài)變遷序列集合中相同的組合狀態(tài)(組合狀態(tài)State 1 和State 2 具有相同狀態(tài)數(shù),State 1 中的所有狀態(tài)在State 2 中都能找到,且State 2中的所有狀態(tài)在State 1 中都能找到),然后添加初始狀態(tài)和轉(zhuǎn)換邊,生成狀態(tài)變遷圖.狀態(tài)變遷圖生成過程如下.

·Step 1:提取每個場景的狀態(tài)變遷序列,得到一個狀態(tài)變遷序列集合T.

·Step 2:對T中所有場景執(zhí)行場景狀態(tài)補齊,得到功能特征屬性集feature.V.

·Step 3:匹配T中不同場景的組合狀態(tài),如果有相同的組合狀態(tài),則持行Step 4,否則,執(zhí)行Step 5.

·Step 4:根據(jù)合并規(guī)則(見表5)合并狀態(tài)變遷序列.如果沒有違反合并規(guī)則,則轉(zhuǎn)Step 5,否則,報告錯誤.

·Step 5:增加一個空的狀態(tài)節(jié)點,作為起始節(jié)點.連接起始節(jié)點與合并后狀態(tài)序列集中所有沒有前驅(qū)的組合狀態(tài)節(jié)點,并在標記事件的邊上添加ε.形成一個狀態(tài)變遷圖.

狀態(tài)變遷圖表達了用戶故事在不同上下文情況下意圖是否達成的狀態(tài)結(jié)構(gòu)化組織方式.狀態(tài)變遷圖是一個有向無環(huán)圖,從起始點出發(fā),可以遍歷所有狀態(tài).使用狀態(tài)變遷圖可以幫助開發(fā)者了解與功能實現(xiàn)相關(guān)的業(yè)務(wù)流,同時也便于開發(fā)和測試.

表5 列舉了狀態(tài)變遷序列合并的6 種情況,其中,(a)表示合并之前兩個狀態(tài)序列的對應(yīng)關(guān)系,(b)表示合并之后的情況.虛線表示兩端的節(jié)點狀態(tài)相同,能夠合并在一起.這6 種情況中,1～3 能夠正常自動合并,4～6 可能存在語義表達沖突,不能進行合并.

Table 5 The rules for merging states sequence表5 狀態(tài)變遷序列合并規(guī)則

3.3 生成功能場景表示

功能場景表示除了包含功能場景屬性集和狀態(tài)變遷圖外,還包括故事描述.故事描述由用戶故事名、角色、意圖及收益4 部分信息組成,分別從故事特征字段文檔的“title”和“narrative”字段中提取.結(jié)合功能屬性特征集提取和狀態(tài)變遷圖生成,生成功能場景表示如算法1 所示.

算法1.功能場景表示生成.

輸入:一個用戶故事的故事結(jié)構(gòu)文檔fileInput.json;

輸出:一個功能場景表示fsNode.

偽代碼:

4 系統(tǒng)功能場景生成與更新

系統(tǒng)功能場景包括一組功能特征節(jié)點和它們之間的關(guān)系,以系統(tǒng)的視角呈現(xiàn)用戶故事需求.本節(jié)介紹用戶故事關(guān)聯(lián)關(guān)系挖掘方法、多個用戶故事之間的沖突檢測以及系統(tǒng)功能場景生成與更新.

4.1 用戶故事關(guān)系挖掘

用戶故事之間可能存在的關(guān)聯(lián)語義體現(xiàn)在圖7 所示的用戶故事概念當中(源自于圖2).圖中虛線框表示在圖2 用戶故事概念的基礎(chǔ)上細化(分解成分),增加功能場景屬性集,灰色底紋部分表示暫時不考慮的概念.

Fig.7 The hierarchical relation of concepts in a user story for constructing relationship圖7 用戶故事關(guān)系概念元素層次關(guān)系

用戶故事u1,u2之間的關(guān)系包括合作關(guān)系、執(zhí)行依賴關(guān)系以及近義關(guān)系.合作關(guān)系表達一組故事通過合作共同完成一個較大規(guī)模的故事.這些故事一般具有相同的角色和客體(功能的操作對象),功能特征屬性集有重疊.執(zhí)行依賴關(guān)系表明一個故事的執(zhí)行依賴于另一個故事的實現(xiàn).這些故事一般在功能描述上有相關(guān)性,如在“收益”中描述功能依賴.近義關(guān)系表明故事具有相似的含義,表現(xiàn)在用戶故事概念模型的各部分都很相似.

1)合作關(guān)系關(guān)聯(lián)強度計算

合作關(guān)系關(guān)聯(lián)強度從角色維度、功能客體(意圖中客體)和功能特征屬性相關(guān)度這3 個方面加以度量.假設(shè)u1,u2分別表示兩個用戶故事,r1,r2分別表示這兩個故事的角色,o1,o2分別表示這兩個故事意圖中的客體,V1,V2分別表示這兩個故事的功能特征屬性,則用戶故事u1,u2的合作關(guān)系強度Sco(u1,u2)等于角色相似度、功能客體相似度與共同功能特征屬性比例的加權(quán)平均,計算公式如下:

本文綜合使用自然語言分析工具中基于詞向量的相似度計算方法[22]和語義相似度[21]的方法計算兩個單詞的相似度.α1+α2+α3=1,Sco(u1,u2)是一個0-1 之間的小數(shù).

2)執(zhí)行依賴關(guān)系關(guān)聯(lián)強度計算

執(zhí)行依賴關(guān)系關(guān)聯(lián)強度與功能特征屬性和“收益”中描述的功能(動作+客體)是否關(guān)聯(lián)到另外一個用戶的功能(“意圖”中動作+客體)相關(guān).假設(shè)f1,f2分別表示故事u1,u2的功能,其中,fi=(actionverb,object)(i∈{0,1}).分別從“意圖”的動作和客體中獲取.cf1,cf2分別表示收益的描述中提到的功能,同樣表達為cfi=(actionverb,object(i∈{0,1})).需要在fi和cfi之間做一個映射,計算它們的關(guān)聯(lián)強度,稱為功能相關(guān)度.舉例如下:如第2.3 節(jié)中“持卡人查詢余額”的用戶故事中“收益”字段描述了“當知道賬號余額,可以取現(xiàn)金”,而“持卡人取現(xiàn)金”的用戶故事中的“意圖”描述了“在ATM 機上取現(xiàn)金”.借助自然語言分析方法(分詞、詞性標注、依存文法分析[23])可以得到cf1=(取,現(xiàn)金),f2=(取,現(xiàn)金),它們的功能相關(guān)度為1.

功能相關(guān)度與動詞及客體相關(guān),假設(shè)fi.a表達動作,fi.o表達客體,u1“意圖”中的功能描述與u2“收益”中的功能描述的功能相關(guān)度sim(f1,cf2)使用如下公式計算:

執(zhí)行依賴關(guān)系關(guān)聯(lián)強度Sde(u1,u2)等于共同功能特征屬性比例與功能相關(guān)度的加權(quán)平均,計算公式如下:

其中,β1+β2=1,Sde(u1,u2)是一個0-1 之間的小數(shù).

3)近義關(guān)系關(guān)聯(lián)強度計算

近義關(guān)系關(guān)聯(lián)強度從4 個維度度量近似關(guān)聯(lián)強度:故事名、角色、功能特征屬性集以及意圖(動作、客體).假設(shè)t1,t2分別表示兩個故事的標題,m1,m2分別表示兩個故事的意圖,計算意圖的相似性參見公式(2).

近義關(guān)系關(guān)聯(lián)強度Ssi(u1,u2)等于上述4 部分概念的加權(quán)平均,計算公式如下:

其中,γ1+γ2+γ3+γ4=1,Ssi(u1,u2)是一個0-1 之間的小數(shù).

4.2 用戶故事沖突檢查

沖突是指用戶故事之間存在語義冗余或不一致,語義冗余是指兩個用戶故事表達了基本相同的語義,需要從故事描述、業(yè)務(wù)功能屬性描述以及場景(狀態(tài)變遷圖)這3 個方面分別檢查.不一致是指兩個用戶故事的場景描述的狀態(tài)變遷存在邏輯問題,如表5 中的情況4～情況6.

對于兩個用戶故事u1=(U1,V1,G1)和u2=(U2,V2,G2),其中,U表示故事描述,V表示功能特征屬性集,G表示狀態(tài)變遷圖.沖突檢查需要分別檢查這3 個部分的匹配情況.具體過程如下.

1)當角色相同且意圖相近時,認為兩個用戶故事的故事描述匹配.角色和意圖是否相近的判別方法見第4.1 節(jié).

2)如果兩個用戶故事的功能特征屬性集相同V1=V2,則兩個用戶故事的功能特征屬性集匹配.

3)匹配狀態(tài)變遷圖的節(jié)點,通過檢查合并規(guī)則發(fā)現(xiàn)沖突.將G1中的每個狀態(tài)與G2中的狀態(tài)進行匹配,如果發(fā)現(xiàn)了匹配的狀態(tài),再查看該狀態(tài)相關(guān)聯(lián)的狀態(tài)變遷是否匹配,然后應(yīng)用表5 中的合并規(guī)則,檢查是否有沖突發(fā)生.

沖突檢查算法如算法2 所示.

算法2.用戶故事間的沖突檢查.

輸出:沖突檢查結(jié)果.

偽代碼:

4.3 系統(tǒng)功能場景生成與更新

系統(tǒng)功能場景生成以一組功能特征表示為輸入,計算機自動推薦關(guān)系,用戶通過關(guān)系確認,最終生成系統(tǒng)功能場景.生成過程主要步驟如下.

·Step 1:輸入一組帶場景的用戶故事,執(zhí)行用戶故事場景抽取,生成一個功能特征節(jié)點集合.

·Step 2:使用用戶故事關(guān)系挖掘方法計算故事之間的合作關(guān)系、執(zhí)行依賴關(guān)系以及近義關(guān)系的關(guān)聯(lián)強度,根據(jù)關(guān)聯(lián)強度的值,將大于閾值(根據(jù)領(lǐng)域問題和用戶故事數(shù)據(jù)集的規(guī)模設(shè)定)的候選用戶故事關(guān)系反饋給領(lǐng)域用戶(關(guān)聯(lián)強度值越高,相關(guān)度越高).

·Step 3:對于存在近義關(guān)系的故事,檢查是否存在沖突.如果有沖突發(fā)生,報告給開發(fā)者.

·Step 4:領(lǐng)域用戶根據(jù)用戶故事關(guān)系挖掘的候選關(guān)系結(jié)果確認用戶故事之間的關(guān)系.

·Step 5:按照確認的用戶故事關(guān)系,在功能特征節(jié)點間建立關(guān)聯(lián)邊,生成系統(tǒng)功能場景.

系統(tǒng)功能場景更新也是一個交互的過程.領(lǐng)域用戶提出刪除、修改和添加新用戶故事的申請.對于刪除和修改的用戶故事,自動化的方法是首先檢索關(guān)聯(lián)故事,反饋給領(lǐng)域用戶確定刪除和修改的故事.如果領(lǐng)域用戶確認刪除故事,則自動化地刪除故事及其關(guān)聯(lián)的邊.對于修改后的用戶故事或新加入的用戶故事,自動化方法首先將用戶故事結(jié)構(gòu)化,然后識別依賴關(guān)系,進行沖突檢查后反饋可能添加的位置信息.領(lǐng)域用戶最終確認添加位置,將新增的用戶故事加入到系統(tǒng)功能場景中.

5 系統(tǒng)功能場景交互式構(gòu)建案例研究

本節(jié)結(jié)合在線購物系統(tǒng)案例,討論系統(tǒng)功能場景構(gòu)建及沖突檢測的可行性.包括案例介紹、實驗結(jié)果展示以及實驗結(jié)果分析與討論這3 個部分.

5.1 案例介紹

我們以“在線購物系統(tǒng)”的帶場景的用戶故事集為案例,開展實驗研究.首先由3 名同學(xué)組成了一個研討小組.分別從客戶、商業(yè)用戶和快遞員3 類用戶的角色,使用本文中描述的帶場景的用戶故事的模板和表2 中的推薦句型,撰寫和提交需求文檔.這3 名同學(xué)共提交了24 個用戶故事,共計57 個場景.業(yè)務(wù)功能操作客體(用戶故事功能操作的對象)包括賬號、商品、訂單、聯(lián)系人信息以及購物車等.表6 為收集到的初始版本用戶故事相關(guān)信息統(tǒng)計表.

Table 6 Characteristics of a set of user stories for a case study表6 案例用戶故事集相關(guān)信息

5.2 實驗結(jié)果展示

為了驗證本文提出的系統(tǒng)功能場景生成方法和表達用戶故事之間關(guān)系的可用性,使用Java 語言開發(fā)原型系統(tǒng).該系統(tǒng)交互式地生成系統(tǒng)功能場景,包括3 個步驟:首先,系統(tǒng)推薦3 種用戶故事關(guān)系(合作關(guān)系、執(zhí)行依賴關(guān)系以及近義關(guān)系),然后,領(lǐng)域用戶從推薦的關(guān)系中選擇他們認為正確的關(guān)系,最后,系統(tǒng)根據(jù)用戶確認的關(guān)系結(jié)果生成系統(tǒng)功能場景圖并反饋給領(lǐng)域用戶.同時,系統(tǒng)檢測并反饋近義關(guān)系中可能存在的沖突.圖8 所示為原型系統(tǒng)推薦用戶故事關(guān)系和領(lǐng)域用戶確認關(guān)系過程的截圖,圖9 所示為原型系統(tǒng)生成的系統(tǒng)功能場景圖及存在近義關(guān)系的用戶故事沖突反饋結(jié)果截圖.

Fig.8 Screenshot of user-interface about recommendation and confirmation of user stories' relationships圖8 用戶故事關(guān)系推薦與確認交互界面截圖

Fig.9 Screenshot of system function-scenario graph and the results of conflict defections圖9 系統(tǒng)功能場景及沖突檢查結(jié)果界面截圖

圖9 所示的“系統(tǒng)功能場景展示”表達了3 種用戶故事關(guān)系,其中,合作關(guān)系(由無向邊連接)將24 個用戶故事連接成9 個連通區(qū)域,分別對應(yīng)表6 中角色執(zhí)行業(yè)務(wù)客體的功能需求.每個連通區(qū)域中的用戶故事共同合作實現(xiàn)具體“角色”針對一個具體“業(yè)務(wù)實體”(功能操作客體)的功能需要.例如,“1 和2”(“注冊賬號”和“登錄賬號”)表示用戶對賬號的功能需要.執(zhí)行依賴關(guān)系(由單向有向邊連接)將24 個用戶故事連接成6 個連通區(qū)域,分別對應(yīng)于賬號、商品、訂單、聯(lián)系人信息以及購物車等業(yè)務(wù)實體的用戶故事(功能)執(zhí)行依賴關(guān)系,表達客戶對購買商品、快遞員配送商品、客戶添加聯(lián)系人信息、客戶修改購物車、客戶管理訂單以及商業(yè)用戶管理商品這6個功能執(zhí)行次序.近義依賴關(guān)系(由雙向有向邊連接)表示用戶故事有可能存在語義冗余,可以考慮對這些語義冗余進行合并.例如,案例中分別對客戶、商業(yè)用戶以及快遞員描述了注冊賬號的用戶故事,它們之間有著較高的冗余語義,可以考慮將3 個故事合并.

5.3 實驗分析與準確性影響

為了檢驗用戶故事之間關(guān)系推薦的準確率和召回率,以及3 種關(guān)系推薦時不同的反饋閾值(實驗參數(shù))的影響,進行了實驗分析.準確率表明推薦關(guān)系的準確性,等于用戶確認的數(shù)量除上系統(tǒng)推薦的數(shù)量.召回率表明推薦關(guān)系的完整性,等于用戶確認的數(shù)量(系統(tǒng)推薦正確的數(shù)量)除上用戶確認的數(shù)量與用戶添加的關(guān)系數(shù)量的和.推薦關(guān)系反饋閾值表示當兩個用戶故事之間的關(guān)聯(lián)程度大于反饋閾值時,該關(guān)系顯示在推薦列表中.

Table 7 Statistic table of precision and recall about user stories' relationships that are recommended by system表7 用戶故事關(guān)系推薦結(jié)果準確率與召回率統(tǒng)計表

表7 表示3 種關(guān)系在不同推薦閾值時準確率和召回率的統(tǒng)計結(jié)果,其中,合作關(guān)系及近義關(guān)系有較好的準確率和召回率.執(zhí)行依賴關(guān)系相對較差,原因是每個用戶故事及其場景在表達上一般相對獨立,很難從有限的信息中挖掘執(zhí)行先后關(guān)系.結(jié)合領(lǐng)域知識可以得到更好的效果[24-26],將在后續(xù)工作中進行嘗試.

推薦關(guān)系和沖突反饋結(jié)果的準確率還受到以下幾個方面的影響.

(1)用戶故事描述語句格式的規(guī)范性:規(guī)范的語句格式便于應(yīng)用標準模板提取用戶故事概念語義,形成正確、完整的功能特征屬性集以及狀態(tài)變遷圖,有助于準確地建立關(guān)聯(lián).

(2)多人合作時領(lǐng)域術(shù)語的統(tǒng)一:領(lǐng)域術(shù)語統(tǒng)一對計算關(guān)系語句同義性起著重要作用.如兩個需求提供者分別用“賬號”和“帳號”表達同樣的指代,但是它們的相似度并不是1.

(3)In order to 字段中執(zhí)行依賴語義的表達:本文描述的執(zhí)行依賴關(guān)系的推薦依據(jù)主要來自于用戶故事中In order to 字段的描述信息.如果領(lǐng)域用戶在寫需求時省略了此項,或者沒有表達相關(guān)語義,本文的方法不能準確地發(fā)現(xiàn)它們之間隱藏的執(zhí)行依賴關(guān)系.只能通過人工添加的方法加入到系統(tǒng)功能場景.

(4)自然語言處理方法的影響:本文使用開源工具HanLP 進行自動化的自然語言分析,包括分詞及依存句法分析.分析結(jié)果對關(guān)系的推薦結(jié)果有一定的影響.另外,計算詞語之間的相似度是推薦挖掘的基礎(chǔ).但目前對詞語中語義(特別是面向領(lǐng)域問題)的相似性計算效果并不理想.原型系統(tǒng)結(jié)合基于詞的語義距離、NGram 和word2Vec 的方法計算詞語之間的相似度,得到較好的效果.

6 相關(guān)工作

敏捷開發(fā)方法由于具有快速應(yīng)對需求變更的能力,被廣大軟件產(chǎn)品開發(fā)團隊使用.團隊成員之間的需求理解以及不同迭代版本的需求管理是有效發(fā)揮敏捷開發(fā)優(yōu)勢的關(guān)鍵.為解決這些關(guān)鍵問題,近年來,研究者們在用戶故事與建模以及需求變更管理方面開展了一系列研究工作.

6.1.1 用戶故事與建模

在80%的敏捷方法中,使用用戶故事表達客戶對系統(tǒng)的需求[16,27,28].好的用戶故事應(yīng)相互獨立,涉及小的功能,且需求可評估可測試[1-3,15,16].多個用戶故事之間存在關(guān)聯(lián),它們組合在一起,形成完整的系統(tǒng)需求.這需要開發(fā)人員能從系統(tǒng)的角度識別出一組用戶故事之間的關(guān)系.很多工作主要提供可視化工具,以便于開發(fā)人員瀏覽和編輯需求[11,12,29].

Wautelet 等人[12]提出建立Use-case 與用戶故事之間的映射關(guān)系,該方法將用戶故事中的角色映射到use case 中的actor,從意圖和收益中分解任務(wù),抽取任務(wù)及目標作為Use-case 中的節(jié)點,并在目標與任務(wù)之間識別包含關(guān)系與擴展關(guān)系映射到use case 中.他們提供了圖形編輯工具[29],支持開發(fā)人員從用戶故事、Use-case 以及類圖3 個角度觀察需求.Mesquita 等人[11]提供了圖形編輯工具US2StarTool,支持將一組用戶故事映射為一個i*模型,幫助開發(fā)人員以系統(tǒng)的視角考察參與者如何達成目標以及目標之間的關(guān)系.Trkman 等人[10]提出從用戶故事中提取本體以構(gòu)建業(yè)務(wù)過程模型(business process model),建立用戶故事之間的順序依賴關(guān)系.Wautelet[30]使用面向目標的方法建立多個用戶故事之間的關(guān)系.Lucassen 等人[9,31]提出,借助自然語言分析的方法從用戶故事中提取概念模型.他們總結(jié)出提取概念和關(guān)系的啟發(fā)式規(guī)則,并根據(jù)規(guī)則抽取概念并建立關(guān)聯(lián)關(guān)系.

這些方法都提供了建立用戶故事與系統(tǒng)模型間的映射關(guān)系的手段,但是由于用戶故事基本上是非結(jié)構(gòu)化的,而且用戶故事描述的信息過于簡化,目前的方法大多通過可視化并結(jié)合人工建立用戶故事關(guān)系.本文提出的方法借助帶場景的用戶故事模型抽取與關(guān)系挖掘,以人機協(xié)同的方式半自動化地建立用戶故事之間的關(guān)聯(lián).最終形成一個系統(tǒng)的視角,幫助開發(fā)者了解用戶故事之間的關(guān)系以及支持迭代的模型增加與修改.

6.1.2 需求變更管理

需求演進由需求變化引起[24,32],需求變化包括增加需求、刪除需求或者修改需求.當需求規(guī)模較大時,分析和評估跨版本的需求變更以及隨之帶來的管理成本和風(fēng)險變得更加困難.

一些研究工作著眼于收集需求數(shù)據(jù),然后分析需求變化,進而發(fā)現(xiàn)新需求.Galvis 等人[33]從一組相關(guān)軟件的需求反饋中自動提取主題,建立主題模型,用于分析變化的需求以及創(chuàng)新的需求.Schneider 等人[34]提出識別軟件版本演化過程中用戶對軟件使用的反饋或建議,通過分類和整理從中獲取新的需求.

為管理需求變化帶來的風(fēng)險,Shi 等人[18]從具有演化特征的多個連續(xù)版本的需求數(shù)據(jù)集中學(xué)習(xí)變化規(guī)律,以預(yù)測后續(xù)版本中需求可能發(fā)生的變化.Anderson 等人[19]以航空電子工業(yè)案例為例開展實證研究,通過對進化趨勢和需求成熟度度量進化信息,以便理解需求演進.

在敏捷開發(fā)過程中,利益相關(guān)者之間的頻繁交互導(dǎo)致迭代的需求過程,使得需求隨著時間的推移變得更加清晰,有利于加強與客戶的關(guān)系,并希望能以較少的時間投入,得到明確的系統(tǒng)需求[35].需求變更管理是其中的一個挑戰(zhàn)性問題.目前需求變更管理大部分是通過維護產(chǎn)品的功能列表和索引卡來跟蹤需求變化[2,36]的,對于一個規(guī)模較大的系統(tǒng),要耗費大量的人力.Ajmeri[20]提出使用需求分析平臺,支持多用戶間的協(xié)同,促成敏捷需求的識別、討論與定義.該方法提出使用領(lǐng)域知識語料(包括核心用戶故事,行業(yè)規(guī)則,use case,數(shù)據(jù)模型,原型等),幫助客戶、領(lǐng)域?qū)＜液推渌治鋈藛T能夠在平臺上修改和增加領(lǐng)域知識以適應(yīng)具體項目的需要,提高敏捷開發(fā)中需求變更的管理能力.目前,也有研究從群體用戶中采集需求,借助群體的智慧增進需求的理解,逐步提出更明確的需求,以支持需求的持續(xù)演化[37-39],如Ali 等人[37]召集一組學(xué)生扮演不同視角的用戶群體,從用戶故事、場景到use case 逐步提供明確的需求.最終得到一個完整的系統(tǒng)需求.

在需求變更管理中,每次需求變更都是一次繁瑣的過程,涉及識別需求變更、變更分析及變更成本分析等步驟.我們的方法以系統(tǒng)模型為基礎(chǔ),提供一種人機協(xié)同的方式,支持需求變更.該方法同時考慮了需求變化可能會產(chǎn)生的沖突,根據(jù)沖突檢查規(guī)則,將發(fā)現(xiàn)的沖突反饋給使用者.最終由使用者決策如何消解這些沖突.

7 結(jié)語和展望

在敏捷開發(fā)過程中,需求并不是事先定義好的,而是通過利益相關(guān)者之間的頻繁交互,隨著迭代開發(fā)過程逐步形成的.開發(fā)者理解領(lǐng)域用戶提交的需求仍然是敏捷開發(fā)的瓶頸之一.一方面,用戶故事所表達的信息有限,開發(fā)者要從功能實現(xiàn)的角度理解用戶故事,需要花費很長的時間與領(lǐng)域用戶討論確認.另一方面,多個用戶故事孤立地表達了領(lǐng)域用戶的期望,缺乏系統(tǒng)的視角,開發(fā)者要理解用戶故事之間的關(guān)系,推斷其優(yōu)先級也存在難度,導(dǎo)致系統(tǒng)模型構(gòu)建上的困難.此外,當用戶修改或提交新的用戶故事時,確定新增用戶故事在當前系統(tǒng)中的位置,以及檢查其與原有用戶故事的沖突,都是繁重的工作.

為了減輕開發(fā)者的負擔(dān),發(fā)揮領(lǐng)域用戶在特定領(lǐng)域上的專家優(yōu)勢,從而實現(xiàn)高質(zhì)、高效的系統(tǒng)需求管理,本文提出并設(shè)計了一種人機協(xié)同的系統(tǒng)故事模型創(chuàng)建及更新方法.面對大量用戶故事數(shù)據(jù),讓計算機自動地進行需求抽取和關(guān)聯(lián)關(guān)系挖掘.領(lǐng)域用戶對挖掘結(jié)果進行確認,人機合作完成系統(tǒng)功能場景圖的構(gòu)建和更新.案例研究表明,本文提出的用戶故事整合方法具有較好的效果,具備一定的可行性.

需求提取與系統(tǒng)需求整合的質(zhì)量與用戶故事表達的質(zhì)量相關(guān).自然語言描述固有的模糊性,領(lǐng)域用戶也不了解如何從獨立的用戶故事中整合出系統(tǒng)的功能需求,是影響需求質(zhì)量的主要原因.從系統(tǒng)視角進行需求質(zhì)量的檢查與評估,以及提供一個支持敏捷團隊需求協(xié)商的可視化平臺,是后續(xù)工作中要解決的問題.

此外,在需求演化過程中,需求變更可能會對原來版本的需求產(chǎn)生沖突,我們目前的做法是根據(jù)沖突發(fā)現(xiàn)規(guī)則生成沖突報告.根據(jù)用戶故事之間的關(guān)系的性質(zhì)和領(lǐng)域知識可以給沖突消解提供參考,將更有效地指導(dǎo)需求工程師解決沖突問題,這是另一個后續(xù)工作中要解決的問題.