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

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

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

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

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

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

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

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

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

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

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

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

1 整體框架

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

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

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

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

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

圖1 給出的方法整體框架,蘊(yùn)含著以下3 個(gè)方面的問題.

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

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

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

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

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

2.1 帶場景的用戶故事

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3 用戶故事場景抽取

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

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

帶場景的用戶故事是一個(gè)有標(biāo)簽的文檔,每個(gè)標(biāo)簽后面的信息表達(dá)特定的語義,滿足表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)(實(shí)體-屬性-值)首先從故事結(jié)構(gòu)文檔中“state”標(biāo)簽后面的短句中提取.使用自然語言分析工具(HanLP[21]),對(duì)狀態(tài)描述語句進(jìn)行分詞、詞性標(biāo)注和依存句法分析,然后與句法模板(表2)匹配,根據(jù)匹配句型找出實(shí)體、屬性和值.例如,“賬號(hào)的余額是balance”與“名+名+是+名”狀態(tài)模式匹配,進(jìn)而找出狀態(tài){賬號(hào).余額=balance}.

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

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

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

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

通過場景狀態(tài)補(bǔ)齊,preState 和postState 具有相同場景屬性集.提取event 字段信息,組成一個(gè)狀態(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)用于用戶故事的每一個(gè)場景,最終得到一個(gè)狀態(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:提取每個(gè)場景的狀態(tài)變遷序列,得到一個(gè)狀態(tài)變遷序列集合T.

·Step 2:對(duì)T中所有場景執(zhí)行場景狀態(tài)補(bǔ)齊,得到功能特征屬性集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,否則,報(bào)告錯(cuò)誤.

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

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

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

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

3.3 生成功能場景表示

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

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

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

輸出:一個(gè)功能場景表示fsNode.

偽代碼:

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

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

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

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

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)系表達(dá)一組故事通過合作共同完成一個(gè)較大規(guī)模的故事.這些故事一般具有相同的角色和客體(功能的操作對(duì)象),功能特征屬性集有重疊.執(zhí)行依賴關(guān)系表明一個(gè)故事的執(zhí)行依賴于另一個(gè)故事的實(shí)現(xiàn).這些故事一般在功能描述上有相關(guān)性,如在“收益”中描述功能依賴.近義關(guān)系表明故事具有相似的含義,表現(xiàn)在用戶故事概念模型的各部分都很相似.

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

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

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

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

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

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

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

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

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

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

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

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

4.2 用戶故事沖突檢查

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

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

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

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

3)匹配狀態(tài)變遷圖的節(jié)點(diǎn),通過檢查合并規(guī)則發(fā)現(xiàn)沖突.將G1中的每個(gè)狀態(tài)與G2中的狀態(tài)進(jìn)行匹配,如果發(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)功能場景生成以一組功能特征表示為輸入,計(jì)算機(jī)自動(dòng)推薦關(guān)系,用戶通過關(guān)系確認(rèn),最終生成系統(tǒng)功能場景.生成過程主要步驟如下.

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

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

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

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

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

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

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

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

5.1 案例介紹

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

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

5.2 實(shí)驗(yàn)結(jié)果展示

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

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

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

5.3 實(shí)驗(yàn)分析與準(zhǔn)確性影響

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

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

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

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

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

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

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

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

6 相關(guān)工作

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

6.1.1 用戶故事與建模

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

Wautelet 等人[12]提出建立Use-case 與用戶故事之間的映射關(guān)系,該方法將用戶故事中的角色映射到use case 中的actor,從意圖和收益中分解任務(wù),抽取任務(wù)及目標(biāo)作為Use-case 中的節(jié)點(diǎn),并在目標(biāo)與任務(wù)之間識(shí)別包含關(guān)系與擴(kuò)展關(guān)系映射到use case 中.他們提供了圖形編輯工具[29],支持開發(fā)人員從用戶故事、Use-case 以及類圖3 個(gè)角度觀察需求.Mesquita 等人[11]提供了圖形編輯工具US2StarTool,支持將一組用戶故事映射為一個(gè)i*模型,幫助開發(fā)人員以系統(tǒng)的視角考察參與者如何達(dá)成目標(biāo)以及目標(biāo)之間的關(guān)系.Trkman 等人[10]提出從用戶故事中提取本體以構(gòu)建業(yè)務(wù)過程模型(business process model),建立用戶故事之間的順序依賴關(guān)系.Wautelet[30]使用面向目標(biāo)的方法建立多個(gè)用戶故事之間的關(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)系挖掘,以人機(jī)協(xié)同的方式半自動(dòng)化地建立用戶故事之間的關(guān)聯(lián).最終形成一個(gè)系統(tǒng)的視角,幫助開發(fā)者了解用戶故事之間的關(guān)系以及支持迭代的模型增加與修改.

6.1.2 需求變更管理

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

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

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

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

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

7 結(jié)語和展望

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

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

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

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