一種用戶故事需求質量提升方法

王春暉 金 芝 趙海燕 崔牧原

1(高可信軟件技術教育部重點實驗室(北京大學) 北京 100871)2(北京大學信息科學技術學院計算機科學技術系 北京 100871)3(內蒙古師范大學計算機科學技術學院 呼和浩特 010022)

用戶故事用簡潔的自然語言形式表達用戶或客戶對系統的需要,在敏捷開發中被廣泛采用[1-3].用戶故事通常包括故事陳述和故事對話2部分.故事陳述概要表達了用戶對系統的需要，一般包含誰想要這個功能(角色)、想要系統什么樣的功能(意圖)，以及為什么需要系統提供這樣的功能(目的收益)3部分信息；故事對話則通過對故事需求存在疑問的不斷澄清而形成關于故事測試的描述[4-6];故事測試用于判定故事是否符合客戶的期望.一些敏捷開發實踐還進一步用場景表達故事實例化需求[7].

用戶故事一般由客戶或用戶從業務需求的視角編寫[5].由于客戶和用戶常常缺乏經驗，所編寫的用戶故事經常在寫作規范和表述上出現缺陷[8-9].例如,忘記寫角色,使開發者無法確定該故事的功能滿足哪類用戶的需要;將多個意圖寫在一個故事中,造成用戶故事的功能很難確定并難以測試;從不同角色寫具有同樣意圖和或目標的故事,常會引入重復與沖突，等等.這些缺陷影響了需求的質量,導致需求不完整、不一致和不可測等問題.

發現故事中存在的質量問題(缺陷)是保障故事需求質量和敏捷開發順利實施的關鍵[8-9].INVEST準則是目前廣泛采用的故事質量分析準則(1)https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/,它認為故事需求應該是獨立的(independent)、可討論的(negotiable)、有價值的(valuable)、可估算的(estim-able)、小規模的(small)和可測試的(testable).然而,INVEST準則僅對用戶故事表達應該具備的良好性質進行了概括,是一種高層抽象說明,并不能直接用于對實例化故事需求的質量評測[9].

有研究者提出一些更加具體的準則,對故事陳述中角色、意圖、收益等描述信息以及故事之間存在的沖突和重復性等質量問題進行描述和說明[10-11],并結合自然語言處理技術實現部分質量準則的自動化檢測[10].然而,這些細粒度的準則僅關注故事陳述本身,沒有關注同樣重要的故事測試信息以及用戶故事間關系.因此,現有研究在故事間沖突、獨立性、可評估性以及故事功能完整性等自動化檢測方面缺乏適用性.

本文關注故事陳述和故事測試2部分信息,提出采用自然語言分析技術和模型驅動相結合的方法，對用戶故事需求進行全面的質量檢測.從故事缺陷定位的角度構建了一種用戶故事概念模型,根據實際案例，結合故事需求的完整性、一致性和可測試性，總結出11條用戶故事編寫應該遵循的質量準則.提出采用故事結構分析、句法模式分析以及語法分析等技術自動構建帶場景的用戶故事的模型,并根據準則進行故事缺陷檢測.實現用于用戶故事缺陷發現和修改的工具,通過不斷修正用戶故事中存在的缺陷提升用戶故事質量.

本文的主要貢獻包括4個方面:

1) 提出一種針對故事缺陷定位的細粒度用戶故事模型,結合故事質量準則支持用戶故事質量分析與生成缺陷報告;

2) 提出了11條質量準則,用于評估故事中出現的不完整、不一致以及不可測試等不同類型的缺陷;

3) 提出包括故事結構分析、句法模式分析以及語法分析等3個層次的用戶故事分析技術，根據質量準則,發現并報告故事中存在的缺陷;

4) 實現支持用戶故事質量檢測和提升的工具,并在一個含36個用戶故事和84個場景的真實項目數據集上進行了實驗研究,表明了本文提出的需求缺陷檢測方法的有效性.

1 相關工作

近年來,隨著敏捷項目規模變大,項目中的故事數量不斷激增,提升故事需求質量顯得越來越重要.研究者在需求質量準則制定和用戶故事需求建模方面開展了一系列研究工作.通過制定需求準則規范用戶故事需求寫作和實施質量檢查;通過從用戶故事中提取信息構建模型,形成全局的觀察視角分析需求的完整性以及一致性等.在需求質量檢查和從文檔到需求的建模活動中,一些研究借助自然語言分析的技術和方法實現(半)自動化.

① https://standards.ieee.org/standard/830-1998.html

② https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/

③ http://www.isys.ucl.ac.be/descartes/index.php

1.1 需求質量準則

需求質量是軟件需求工程領域關注的主要問題之一[12-13].存在多個用于表征軟件需求質量的準則,以驗證需求是否按照正確的方式編寫.其中,IEEE-830標準①，定義了傳統軟件開發中需求規格說明的質量標準,包括完整、明確、具體、一致等.

針對用戶故事需求,有研究者提出寫好故事應該遵循的準則.Wake②提出一個好的用戶故事遵循INVEST原則.Cohn總結編寫優秀故事的經驗[5],包括明確故事的目標、編寫封閉的故事、使用卡片約束、不過早涉及用戶界面、由客戶和用戶編寫故事等.這些質量準則給寫高質量的故事提供指導和建議.但仍然是一種高層抽象說明,并不能直接用于對實例化故事需求的質量評估.

一些研究者針對用戶故事描述提出敏捷需求質量檢測框架.Heck等人[11,14]引入傳統需求文檔質量評估準則,從完整性、一致性和正確性的視角對故事描述進行質量評估.Lucassen等人[10]基于INVEST原則,根據故事的寫法和故事描述特性,從自然語言分析的視角將質量評估準則劃分為句法(syntactic)、語義(semantic)和語用(pragmatic)三方面.句法層的準則對故事描述的格式和每個特征信息的句法規則進行規范化;語義層的準則對用詞表達和一致性方面進行規范化;語用層對故事描述中的完整性、唯一性等方面進行規范化.但它們對有些準則(如獨立性、可估算等)沒有明確的界定,缺乏自動化檢測質量缺陷的可操作性.

本文認為用戶故事除了包含故事的基本描述信息,還包括故事需求澄清和測試的相關信息.充分分析用戶故事描述和測試場景等信息,有助于發現用戶故事在語句表達以及故事間關系等方面存在的質量問題.本文從完整性、一致性和可測性3個方面重新組織用戶故事質量評估準則,并對每個準則給出了詳盡解釋和說明,進而實現支持故事缺陷發現的工具,提升用戶故事寫作質量.

1.2 用戶故事與建模

每個用戶故事表達一個相對獨立的功能需求.不同利益相關者從自身的角色出發,提出與某個特定功能相關的用戶故事.對用戶故事建模有助于理解用戶故事需求的特性以及多個用戶故事之間的關系.目前,一些研究通過建立用戶故事與某種模型的映射,形成不同的視角觀察和分析用戶故事需求.

Wautelet等人[15]提出從用戶故事到用例(use case)的映射方法.將故事中的角色映射到use case中的角色(actor).從意圖和收益中分解目標和任務,映射為use case中的節點,并在目標與任務之間識別包含關系與擴展關系.該項工作還提供了編輯工具③,支持從用戶故事、use case以及類圖3個視角觀察需求.Mesquita等人[16]提供了一種圖形編輯工具US2StarTool,支持將一組用戶故事映射為一個i*模型,幫助開發人員以系統的視角考察參與者如何達成目標,以及分析目標之間的關系.Trkman等人[17]提出從用戶故事中提取本體以構建業務過程模型(business process model),建立用戶故事之間的順序依賴關系.Lucassen等人[18]從用戶故事中提取概念模型檢測故事需求的完整性.他們總結出提取概念和關系的啟發式規則,并根據規則抽取概念建立關聯關系.

我們在帶場景的用戶故事建模方面開展了初步的研究工作[19],將一組由不同利益相關者提供的用戶故事需求文本通過人機協同的方式半自動化地轉換成用戶故事模型.該模型用于綜合不同視角的模型,形成一個系統模型,并支持系統需求的迭代式演進.與構建系統需求演化模型不同,本文從故事缺陷定位的角度構建了一種用戶故事概念模型,通過自動化的模型構建發現用戶故事需求中存在的完整性、一致性和可測試性方面的缺陷.

1.3 需求工程中的自然語言處理

在需求工程中,自然語言處理技術廣泛應用于模型的(半)自動化構建和需求質量自動化檢測等.

在需求模型構建方面,一些研究借助自然語言分析技術從需求文檔中提取模型中的概念及關系信息,構建實例化模型.例如,Yue等人[20]從RUCM(格式受限的use case需求文檔)中提取模型相關信息,生成活動圖、時序圖以及類圖模型.Kamalrudin等人[21]提出一種自動化的工具從文本需求中提取基本用例(essential use case, EUC)模型,并通過與基準EUC比較來檢測不一致、不完整和不正確的情況.

在需求質量自動化檢測方面,一些研究者借助自然語言分析技術中的詞法分析器或句法分析器檢查需求規格說明文檔中存在的質量問題.SREE工具[22]采用詞法分析器識別需求中存在的模糊性問題，其準確率和召回率分別達到了66%和100%.Yang等人[23]將詞法和句法分析器與機器學習領域的條件隨機場技術相結合,檢測自然語言需求中的不確定性.他們在11個需求規格說明文檔中識別輔助詞、動詞、名詞和連詞的不確定性,檢測結果的F值平均達到62%.

本文采用自然語言分析技術從帶場景的用戶故事文檔中提取用戶故事概念信息,包括從故事陳述中提取故事描述相關的概念,從故事測試中提取故事功能相關的業務實體以及狀態變遷關系信息.在實例化用戶故事模型概念提取的過程中,定義了規范化的帶場景用戶故事表達框架,并制定了從框架中特定的位置提取相應概念的句法模型,定義了識別用戶故事狀態變遷、用戶故事間關系的規則和方法.本文結合自然語言分析技術,在構建模型的過程中發現用戶故事中存在的違背故事需求質量準則的信息,反饋用戶故事中可能存在的缺陷信息.

2 用戶故事質量模型

本節首先介紹一種帶場景的用戶故事表示,接著從故事缺陷定位的角度定義故事概念模型表達.

2.1 帶場景的用戶故事

Wynne等人[24]提出使用Gherkin語言來編寫便于實現自動化驗收測試的故事寫作模板,包括功能(feature)和場景(scenario)兩部分信息,表達用戶故事實例化需求.該模板及主要概念如圖1所示.

Fig. 1 The template of user story description with scenarios and its hierarchy of conceptual element圖1 帶場景的用戶故事描述模板及其概念元素層次關系

其中,“Feature”后面是一個故事陳述,表示一個獨立的功能，即以某個“角色”為視角，提出對使用軟件系統的“意圖或功能需要”以達成某種“目的收益”.其中,“Scenario”后面是特征的實例化描述.即,在某個狀態和條件滿足的情況下,執行某個動作或發生某個事件,系統達成了某種結果狀態.一個功能包括至少一個或多個場景,用來探索一些邊界情況,幫助實現該功能需求的正確性檢驗和測試.其中,所有場景都遵循同樣的模式:將系統置于某種特定的上下文(Given和And描述的部分);戳一下(或者點一下)系統(When描述的部分);系統置于新狀態(Then和And描述的部分).

場景建立了一個上下文,繼而描述一個動作,最后檢查結果是否符合預期.表1描述了“持卡人在ATM機上取現金”的用戶故事示例.該用戶故事包括3個場景，用于描述意圖是否達成:“成功取款”、“卡余額不足不能取款”和“卡無效無法取款”.取現金業務與賬號余額、卡是否驗證通過(是否是合法用戶)、取款金額以及ATM機余額等業務實體相關.這些業務實體在每個場景中被實例化，即賦予某個具體的值,表示這些業務實體處于某個“上下文”的狀態下(前置狀態).由于某個事件發生,而處于某個“結果”狀態(后置狀態).例如，“成功取款”這一場景中，表達前置狀態的信息是:在賬號的余額是balance，卡被驗證通過且ATM機有足夠的現金.當執行“持卡人取現金cash”事件后,該場景的業務實體的后置狀態描述是:ATM吐出現金,系統提示取款成功,賬號余額會修改.

Table 1 User Story Description of “cardholder withdraw cash”

2.2 用戶故事質量概念模型

根據2.1節描述的帶場景用戶故事信息表達的特性,用戶故事包括故事描述、特征屬性及狀態變遷3個核心概念.其中故事描述包括故事名、角色、意圖和收益;特征屬性由業務實體組成;每個業務實體處于某個特定上下文時對應一個原子狀態.將多個描述業務實體的原子狀態組合在一起,形成組合狀態.狀態變遷是一個由狀態變遷序列組成的集合.其中,狀態變遷序列是由每個場景的上下文、事件、結果形成的狀態遷移關系;其中上下文是該狀態變遷的前置狀態,結果是該狀態變遷的后置狀態.

任意2個故事之間可能存在3種關系:合作關系、依賴關系以及重復關系.1)合作關系是指故事具有相似的特征屬性集,即在描述業務需求時具有較高的相關度,可能共同合作完成一個“史詩”故事;2)依賴關系是指故事的實現存在先后關系,即一個故事的完成依賴于另一個故事的實現;3)重復關系是指2個故事具有相同的文字表達或相同的語義,即相同的故事陳述和故事場景.存在合作關系的用戶故事通常是由一個相對規模較大的故事分解而來,例如:用戶在線掛號的故事分解為創建賬號、填寫掛號信息、編輯掛號信息等3個更具體的用戶故事，而這些具體的用戶故事合作完成用戶在線掛號的故事.重復的用戶故事通常是由于寫故事的人在互相沒有交流的情況下,從相同的角色出發,寫出2個功能相同的用戶故事.例如,有2個用戶都寫了“As a病人I want to創建賬號”的用戶故事,此時這2個用戶故事存在重復關系.

用戶故事質量相關的另外一個關鍵概念是缺陷.本文將用戶故事看成一個由自然語言描述的文檔,每行由一個關鍵詞開頭,如表1所示.用戶故事可能存在不完整、不一致或不可測試等方面的缺陷.其中,缺陷主要包括3部分信息:出錯的位置(通常定位到用戶故事中的某一行語句)、出現質量問題的種類(某種出錯類型)，以及如何修改該缺陷的指導性建議(修改推薦).

綜合上述用戶故事質量相關概念,針對故事缺陷定位的故事質量概念模型包括單個故事、故事之間的關系以及缺陷3個核心概念,如圖2所示.

1) 故事描述

故事描述包括故事名、角色、意圖、收益4個部分.其中故事名是對故事特征的簡短描述,用于區分不同故事.角色表示該需求是為了滿足哪個(些)利益相關者的需要,一般表示一個具體的用戶或客戶的身份.角色通常是一個專有名詞，例如,在線購物系統中的購買者、快遞員、系統管理員等.意圖通常表達功能性的需求.采用的句型為:[狀語]+動詞+[定語]+操作的直接對象.例如:As a 新聞網站訪問者 I want to查看最新的新聞.“查看”是與請求的功能相關的動詞;“新聞”是直接對象.收益中包括一個或多個成份,用于解釋為什么需要這個功能.收益通常與3種信息相關:澄清意圖、表達與其他故事依賴關系和或質量需求.例如,3個故事的收益部分分別表達上述3種信息.“As a 購買者 I want to 修改地址信息 In order to 糾正任何錯誤的地址信息”;“As 持卡人I want to 驗證持卡人身份In order to 可以辦理取款業務”;“As a 購買者 I want to 按照價格排序商品 In order to 能夠容易的查看結果”.

Fig. 2 Conceptual model of quality of user story圖2 用戶故事質量概念模型

2) 狀態變遷

狀態變遷由狀態和事件組成.任一場景可以表達為一個狀態和事件的序列.包括前置狀態、事件、后置狀態、事件、后置狀態…其中,場景描述中GivenThenAnd關鍵詞后面的語句對應于某個狀態(其中Given,Then,And 關鍵詞后面的每個句子表達一個原子狀態).即:實體+屬性+值.通常采用的句型為:名詞+ [“的”+名詞] + “是不是處于不處于”+ 名詞形容詞+ [“狀態”];例如:“賬號的余額是balance”.事件通常表示動作或狀態,對應于場景描述中When關鍵詞后面的語句.表示動作的描述通常采用的句型為:主動者+[狀語]+動詞+ [定語]+對象;例如:“持卡人取現金”.有些情況會省略主動者,此時主動者為角色.

3) 特征屬性

場景是故事的實例,表達了系統在某個特定的上下文狀態下,當某個事件發生時,系統所處的結果狀態.場景的狀態表達了系統業務實體的取值.將業務實體構成的集合稱為故事的特征屬性,用于記錄場景描述中業務相關的信息.例如表 1的特征屬性可以表示為集合:{賬號.余額,卡.狀態,ATM.現金儲備,ATM.吐幣金額,系統.提示信息}.針對具體場景,特征屬性被實例化.例如,場景1中前置狀態為:{賬號.余額=balance,卡.狀態=有效,ATM.現金儲備=足夠,ATM.吐幣金額=NULL,系統.提示信息=NULL};經過事件“賬號持有者取現金cash”，后置狀態為:{賬號.余額=balance-cash,卡.狀態=有效,ATM.現金儲備=足夠,ATM.吐幣金額=cash,系統.提示信息=取款成功};前置狀態、事件、后置狀態形成一個狀態變遷.

4) 關系

在一組故事集合中,任意2個故事可能存在3種關系:合作關系、依賴關系和重復關系.存在合作關系的故事可能共同合作完成一個“史詩”故事.例如,“持卡人驗證身份”“持卡人查詢余額”“持卡人取款”合作完成“在ATM機上取現金”這個“大”故事.存在依賴關系的故事在實現上存在先后關系,即一個故事的完成依賴于另一個故事的實現.例如,故事“持卡人驗證身份”發生在“持卡人取款”之前,即只有具有合法身份的持卡者才能取款.存在重復關系的故事通常是由于不同人在沒有相互協商的情況下,從同樣的角色和功能出發,寫出了在表達和語義上相同的用戶故事.例如,有2個寫故事的人都想要系統提供登錄功能.他們都提交了故事:“As a 用戶 I want to 使用用戶名和密碼登錄系統”.此時,將產生2個重復的故事.

5) 缺陷

缺陷記錄了故事中不滿足質量評估準則(見第3節)的信息,包括缺陷的種類、出錯位置及修改這些質量問題的建議(推薦信息).本文定義了11種質量評估準則,并對故事描述逐行進行分析,從中提取出用戶故事質量模型中的概念,并進行用戶故事建模.在建模過程中分析是否存在缺陷(即是否該行違背了準則),如果違背了準則,則反饋該故事行的信息、出錯的類型和修改該種類錯誤的建議.

3 故事質量評估準則

從需求質量評估的角度,用戶故事表達應該滿足完整性、一致性和可測試性.完整性體現在2個方面：一方面單個故事應該在表達上描述完整的需求信息,以便于其他人充分理解.具體表現在故事至少應該具有角色、功能點描述(意圖)等關鍵字段信息,場景要包含上下文、事件和結果;另一方面所有故事應該覆蓋一個完整的系統功能,即不缺失步驟功能要素.一致性同樣體現在2個方面:1)每個用戶故事應該使用統一的模板表達需求,以便于討論者和分析者較容易地從中獲取相應成份的信息(如角色、功能需求、場景等)；2)不同故事在表達習慣(描述句式和句型等)和術語表達上具有一致性,且不存在沖突和重復的故事.除了完整性和一致性這2個因素外，每個用戶故事應該滿足可評估、不模糊、最小化和原子性,同時與其他故事具有盡量少的依賴(獨立性),上述準則體現了故事的可測試性.本節根據實際案例，結合故事需求的完整性、一致性和可測試性,參考已有工作中針對用戶故事描述的質量評估準則,對帶場景的用戶故事質量評估準則進行細化.表2展示了故事質量相關的因素及這些因素其對應的11條準則.

Table 2 Quality Criteria of User Story Requirements

1) 故事的關鍵字段完整

一個用戶故事通常包括故事描述和故事場景2個部分.故事描述中至少要包括2種成份,即角色和意圖.缺少這2種成份的故事描述是不完整的.例如,附錄A中用戶故事US1“I want to 當文件不能打開時,可以看到出錯提醒”缺少角色說明.可以修改為：“As a合法成員 I want to當文件不能打開時,可以看到出錯提醒”.此外,故事中的每個場景都包含上下文、事件和結果信息.缺失了上述任何一種信息的場景都是不完整的.關于缺失不同關鍵字段信息的示例,參見附錄A.

2) 故事的語法成份完整

一個用戶故事中包含角色、意圖、收益、狀態和事件等概念.一個清晰的故事描述中應該具有完整的語言成份,以表征故事的每個概念.例如,在故事描述中意圖(I want to后面描述的信息)捕捉一個具體的功能特征,至少包括一個動作和動作操作的對象.用戶故事“As a 用戶I want to 打開共享地圖 In order to 知道我和朋友之間的距離”,意圖是“打開共享地圖”,由動作“打開”和對象“共享地圖”構成.附錄A中故事US2“As a 用戶I want to 界面一致 In order to 不會產生混淆”中,意圖缺少必要的動詞,使得含義不明確.可以寫成“As a 用戶I want to 在使用撥號盤時看到界面一致 In order to 不會產生混淆”.

3) 功能完整

4) 故事模板統一

故事集中的每個故事采用團隊認可的用戶故事模板格式和關鍵詞書寫故事.為了實現故事模板統一,需要事先定義一種大多數人習慣使用的格式,并取得整個團隊成員的認可.團隊成員在寫用戶故事時都應該遵循事先定義的格式.例如,團隊認可的用戶故事描述模板是“As a 角色 I want to 意圖 In order to收益目的”,如下用戶故事不符合模板統一準則:US4“As a 管理員,When 一個用戶已經注冊,可以收到郵件”.

5) 故事間無重復

故事集中任意2個故事描述不相同,即表達不同的含義.當2個寫故事的人都從同一個角色出發，有可能寫出重復的故事描述.例如,有2個成員都寫了 “As a 新聞網站訪問者 I want to查看最新的新聞 In order to 知道當前最新的新聞”.為了盡量避免重復,寫故事的人應該寫更為具體的需求.例如上述故事可以分別表達為“As a 新聞網站訪問者I want to 查看最新的時政新聞”和“As a 新聞網站訪問者I want to查看最新的體育新聞”.

任一故事中的任意2個場景或2個故事中的任意2個場景也不應該重復.例如,附錄A中2個場景S1_1,S1_2存在重復.在一個故事中出現了2個相同的場景通常是由于書寫上的疏忽.而不同故事中出現了重復的場景時,通常這2個故事具有較高的相似性,而場景可能存在省略狀態的情況.

6) 故事間無沖突

故事集中任意2個故事不沖突.本文認為故事沖突主要包括2類:故事陳述中的沖突,包括角色、意圖和目標之間存在描述邏輯問題;故事場景之間的沖突,包括狀態變遷的邏輯關系存在矛盾.

故事陳述中的沖突主要存在2種情況：

① 相同“意圖”達到不同“目標”.2個或多個用戶故事有相同的意圖，但達成不同目標.例如，附錄A故事US6_1“As a 購買者I want to搜索圖書In order to找到我想買的書”和故事US6_2“As a 購買者I want to搜索圖書In order to查看是否存在該圖書”存在不一致.為了消解這個不一致,這2個用戶故事需要增加或細化信息,以明確需求.例如，故事US6_1可以改寫為：“As a 購買者I want to輸入想購買圖書的關鍵字In order to看到相關圖書的列表”.

② 不同“角色”相同意圖和目標.2個或多個用戶故事具有不同的角色但有相同的意圖和目標，通常這些用戶故事需要考慮合并.例如，附錄A中的故事US7_1“As a 購買者I want to 輸入注冊信息In order to成為合法用戶”和US7_2“As a 快遞員 I want to輸入注冊信息In order to成為合法用戶”可以合并為“As a 系統用戶 I want to輸入注冊信息In order to成為合法用戶”.在合并后的故事中,可以考慮增加場景對不同種類的角色進行測試.

對于2個狀態變遷S1=〈s1,e1,t1〉,S2=〈s2,e2,t2〉,其中s1,s2表示前置狀態,e1,e2表示事件,t1,t2表示后置狀態.狀態變遷沖突主要包括2種情況：

① 不同前置狀態,相同事件和后置狀態,即s1≠s2∧e1=e2∧t1=t2.通常這些場景上下文中有冗余的狀態或結果中有狀態描述不全.例如,附錄A中場景S2_1“Given 賬號的余額是充足的When 輸入取款金額 Then 顯示成功取款”和S2_2“Given 卡驗證通過When 輸入取款金額 Then 顯示成功取款”可以合并為“Given 賬號的余額是充足的 And卡驗證通過When 輸入取款金額 Then 顯示成功取款”.

② 2個狀態變遷的方向相反,即s1=t2∧e1=e2∧s2=t1.例如,附錄A中場景S3_1“Given 提示信息是“請輸入密碼”When 選擇進入鍵 Then 系統顯示主界面”和S3_2“Given 系統顯示主界面When選擇進入鍵 Then 提示信息是“請輸入密碼”存在矛盾.

7) 故事原子性

一個故事中僅包含與某個業務功能需求相關的必要的信息,不能包含多個意圖.同樣,一個場景中表達狀態信息的字段中僅包含一種業務實體及其狀態的信息,不能包含多個業務實體 (如果想表達當前上下文包含多個業務實體的狀態信息,則不同業務實體對應的狀態信息之間用And進行分隔).例如,如下故事表達了多個意圖:附錄A的US8“As a 用戶 I want to單擊地圖上的一個位置，并執行與該位置關聯地標的搜索 In order to 反饋到關聯地標的路線”.這個故事包含2個意圖,應該拆分成2個故事:“As a 用戶 I want to 單擊地圖上的一個位置In order to 選中該位置”和“As a 用戶 I want to搜索與地圖選中位置相關聯的地標In order to反饋到關聯地標的路線”.附錄A中場景S4的Then字段中包含了2個狀態信息:“Then 進入在線視頻界面，顯示視頻詳細信息”中包含2個狀態,可以改寫成“Then 進入在線視頻界面 And 顯示視頻詳細信息”.

8) 故事最小化

一個故事中除了角色、意圖、目的、場景等關鍵信息,不包含其他無關的信息.例如，附錄A故事US9“As a醫生 I want to查看本周的預約時間(分為手術和出診)”.盡量去掉括號里的補充信息,表達成明確的需求.該故事可以改寫成2個故事：“As a醫生 I want to查看本周手術預約時間”;“As a醫生 I want to查看本周出診的預約時間”.

9) 故事不模糊

故事中應不使用模糊詞匯,且盡量使用統一和規范的術語,表達明確的信息.例如，故事US10“As a 注冊用戶I want to查看醫生詳細信息 In order to 選擇合適合的醫生”,其中“醫生詳細信息”不夠明確,可以寫成“醫生的職稱、科室、專長等信息”.模糊詞匯還包括一些不確定的修飾詞,例如：快速、短時間、幾個、少量等.

10) 故事可估算

Fig. 3 User story quality analysis process based on natural language processing and model expression圖3 基于自然語言處理與模型表達的用戶故事質量分析過程

故事不能粒度太大,這樣不便于估算其工作量和評估優先級.例如，附錄A中故事US11“As a 求職者I want to 發布自己的簡歷 In order to招聘方可以看到”這個故事粒度太大了,可以分解成一些小故事:求職者可以創建簡歷(US11_1)、求職者可以修改簡歷(US11_2)、求職者可以刪除簡歷(US11_3)等.

11) 故事彼此獨立

故事在概念上應該不重疊,并且按任何順序安排和實施故事的開發順序.例如,附錄A中故事US12_1“As a 采編網用戶 I want to 編輯稿件”依賴于故事US12_2“As a 管理員 I want to增加一個用戶 In order to增加的用戶可以使用采編系統”.這2個故事不是獨立的.

然而,在實際敏捷開發過程中,用戶故事需求之間可能存在相互的依賴關系.例如,一個用戶故事的實現依賴于另一個用戶故事的完成.從需求管理的視角,建議通過發現依賴關系使故事之間的關系可見.一種常見的方法是在故事卡片上增加一段注釋,以鏈接的方式或者自然語言描述的方式說明故事之間的依賴關系.例如,上面2個故事可以在故事“As a 采編網用戶 I want to 編輯稿件”的卡片上加如下注釋:“采編網用戶由管理員添加，詳見故事US12_2”.

故事間除了具有上述基于實現先后順序的依賴關系(例如，故事US12_1與故事US12是一種依賴關系),還可能具有合作關系和重復關系.合作關系是一組可組合關系,即存在合作關系的小故事組合形成一個規模更大的用戶故事.例如：表2中故事US11和US11_1，US11_2，US11_3之間是一種合作關系.重復關系是指不同人提供的故事在語言表面含義上存在重復(詳見質量準則5).

4 故事需求缺陷識別方法

本節介紹發現故事中違背質量準則的自動化方法.圖3展示了從一組用戶故事中發現其可能存在的缺陷并反饋錯誤報告的框架.該框架主要包括3個關鍵模塊:結構分析、句法模式分析以及語義分析.結構分析以格式受限的故事文檔為輸入,識別故事的字段信息,并發現違背關鍵字段完整和模板統一準則的故事;句法模式分析采用自然語言分析技術分析每個字段的句型和語句成份,識別出場景對應的狀態變遷序列和特征屬性信息,同時發現違背語言成份完整、原子性及最小化準則的故事;語義分析先對輸入的一組故事進行相似度計算,發現重復的故事和相似度高的故事.然后對每個故事和每對相似度高的故事中的狀態變遷序列進行規則檢查,發現沖突.借助同義詞庫、模糊詞庫識別故事中是否存在模糊性和用詞上的不一致.此外,本文還通過故事之間的關聯關系挖掘的方法識別故事之間可能存在的合作關系和依賴關系.將關系反饋給寫需求的群體,幫助他們分析如何提升故事獨立性和功能完整性的質量.

① https://hanlp.hankcs.com

4.1 結構分析

給定一個采用圖1所示模板編寫的用戶故事,結構分析以故事文檔中的關鍵詞(Feature,As a,I want to等)為特征詞,識別字段:故事名(name)、角色(role)、意圖(mean)、收益(benefit)、場景名(scenario)、狀態描述序列(state)、事件描述序列(event).在解析故事文檔結構過程中,結構分析過程發現每個故事是否違背了關鍵字段完整性和模板統一性的準則.

對于任一用戶故事ui∈U,設其角色和意圖分別表示為ri和mi,關鍵字段完整性檢測的規則是：

conComplete(ui)?ri≠?∧mi≠?.

對于任一用戶故事ui∈U,其模板統一性的檢測規則是:檢查是否包含事先設定的特征詞 (As a,I want to,…),如果沒有完全覆蓋這些特征詞,則查看是否在“常用特征詞表”中存在,如果存在則認為違反了模板統一性準則.

4.2 句法模式分析

在結構分析過程中故事的關鍵字段被存放在故事結構化文檔(.json)文件中.句法模式分析則將每個關鍵字段看成句子,采用自然語言分析技術識別出每個句子的成份,然后根據規則提取圖 2故事質量概念模型中的概念并檢查相應字段成份完整性.具體而言,對于任一句子S,本文借助自然語言處理工具HanLP①先對句子進行分詞和依存文法分析,識別出句子的成份.例如:“賬戶的余額是balance”這個短句中，“賬戶的余額”是主語,與動詞“是”之間形成主語和謂語(主謂)關系,其中“賬戶”和“余額”是一種定語和中心詞(定中)關系,而“是”和“balance”是動詞和賓語(動賓)關系.(HanLP工具針對該句子的句法分析結果如圖4所示).根據分詞和文法分析結果,可以發現句子的成份.針對場景中Given,And和Then關鍵字段,同樣可以識別出實體、屬性、和值等概念,并生成狀態信息.

Fig. 4 An example of dependent grammar analysis in HanLP圖4 HanLP依存文法分析示例

句法模式分析過程可以發現用戶故事是否違背了成份完整、原子性及最小化的準則.語言成份完整的判斷依據是檢查句子中是否包含了完整表達該字段應該具備的語言成份.例如,When關鍵詞后面的字段信息應該表示一個動作或狀態,當從這個字段信息提取不出關于動作和狀態信息時,將生成該字段語言成份不完整的缺陷信息.本文針對每個字段的關鍵信息定義了推薦的句法模式(詳見附錄B),認為沒有采用句法模式的表達可能存在成份不完整的缺陷.

1) 句子中含有連接詞“和、或者、并且”等;

最小化主要檢查“意圖”字段中是否包含括號等備注信息.本文在對意圖字段進行句法分析時,分析括號“(),[],{},〈〉”中間的語句,如果該語句包含選擇性信息(如：并、或、且、和等),則認為違背了最小化準則.

4.3 語義分析

語義分析過程主要包括4個部分:相似度度量,故事陳述和場景的沖突檢查,基于同義詞庫、模糊詞庫、術語表等知識庫的質量檢查,以及基于關系挖掘的故事間關系識別.

1) 相似度度量

其中s:String×String→[0..1]是一個詞到詞相似度計算函數.即給定2個詞x,y,s(x,y)返回一個0～1之間的小數.本文綜合自然語言分析工具中基于詞向量的相似度[25]和基于語義相似度的計算方法(采用HanLP計算中文詞語義相似度計算方法①)分別計算2個詞的相似度,并通過加權平均得到這2個詞的相似度.這種綜合詞向量和語義相似度的計算方法綜合考慮了詞在字符表達和同義詞之間的差異.

① https://github.com/hankcs/HanLP

② http://www.hankcs.com/nlp/hanlp.html

③ http://mlwiki.org/index.php/TF-IDF

④ https://insulation.org/io/articles/k-value-u-value-r-value-c-value/

系數α1+α2+α3+α4=1,2個用戶故事的相似度sim(u1,u2)是一個0～1之間的小數.sv(x1,x2)表示2個意圖或2個收益之間的相似性,計算為

sv(m1e1,m2e2)=

當2個故事的描述信息完全相同時,這2個故事的相似度為1.當2個故事對應字段描述越相似,相似度值越接近1.當2個故事對應字段的描述信息完全不相似,相似度接近為0.

2) 沖突檢查

對于任意2個相似度較高的故事(例如,相似度大于80%)需要進一步檢查故事是否存在沖突.設故事u1=〈r1,m1,e1,F1,S1〉,u2=〈r2,m2,e2,F2,S2〉具有較高的相似度.滿足2個條件的故事描述存在沖突:

① 相同“意圖”達到不同“目標”

Conflict1(u1,u2)?m1=m2∧e1≠e2;

② 不同“角色”相同意圖和目標

Conflict2(u1,u2)?r1≠r2∧m1=m2∧e1=e2.

設S1=〈s1,e1,t1〉,S2=〈s2,e2,t2〉是2個狀態變遷.滿足2個條件的狀態變遷存在沖突:

① 不同前置狀態,相同事件和后置狀態

Conflict3(S1,S2)?s1≠s2∧e1=e2∧t1=t2;

② 2個狀態變遷的方向相反

Conflict4(S1,S2)?s1=t2∧e1=e2∧s2=t1.

3) 基于知識庫的質量檢查

本文通過創建相關的知識庫輔助不模糊、不重復以及功能完整性的質量檢查.

在編寫故事時,不同人在表達相同的概念時可能使用不同的術語,影響了團隊成員對需求的理解和相似性計算.為了減少這些影響,本文針對特定領域的故事需求質量檢查問題,創建了同義詞庫.在同義詞庫中包含同義詞和該同義詞的使用頻度.當某個故事中出現了同義詞詞匯并使用頻度低,則認為存在用詞上的不一致,并反饋相關的缺陷信息.此外,本文還創建了模糊詞庫,包括一些經常出現的模糊詞,例如大概、很多、很快、快速、幾秒等.當某個故事中出現模糊詞時,反饋存在違背不模糊質量準則信息.

為了實現基于知識庫的質量檢查,提高漢語言分詞準確率,本文采用基于統計分析與規則學習的領域術語詞抽取的方法半自動化地構建領域術語庫.具體包括4個步驟:

① 對一組用戶故事文檔進行分詞與詞性標注.

② 進行候選詞提取.采用基于互信息和左右信息熵的短語提取方法(HanLP命句實體識別②)從用戶故事需求文檔集中獲取候選短語列表.

③ 候選詞過濾.對候選短語列表中的短語分別計算TF-IDF③和C-Value④值,并按短句的TF-IDF值和C-Value值加權值進行排序,選取排名靠前的短語作為候選領域術語詞.

④ 人工確認領域術語詞.人工從過濾后的候選詞中選擇并確定領域術語詞.

4) 故事間關系識別

simdep=max(sr(m1,e2),sr(m2,e1)),

其中,sr(m,e)表示2個故事意圖(m)和收益(e)之間的相似度,該相似性計算為

其中,v為意圖收益中的動詞,o為意圖收益中動詞操作的直接對象,d為意圖收益中動詞操作的間接對象.

合作關系的相似度采用比較特征屬性集F1,F2之間共有元素的占比:

另外,對于可估算這一質量檢測標準,本文認為那些具有場景描述的故事是可估算的.即用戶故事ui滿足的規則為

ConEvalated(ui)?Fi≠?∧Si≠?.

5 實驗與結果

基于本文提出的用戶故事缺陷檢測方法,我們實現了一種支持帶場景用戶故事質量提升工具USQI(user story quality improvement).本節先介紹該質量提升工具,然后以一組面向智能手機需求的用戶故事集為案例，驗證本文提出的用戶故事缺陷檢測方法的效果.

5.1 工具介紹

USQI工具主要包括2方面的功能:報告用戶故事文檔中存在的缺陷和交互式地提取用戶故事文檔中的領域術語詞.圖5展示了該工具在執行一個用戶故事的檢測后反饋的結果,包括用戶故事文檔(詳細信息)、用戶故事結構、用戶故事出錯信息和領域術語候選詞.用戶故事文檔是由寫故事的人編寫的用戶故事文件,每一行均以一個特征詞開頭;用戶故事結構按照用戶故事模型中的特征詞組織用戶故事視圖,幫助用戶查看用戶故事描述的關鍵字段信息;用戶故事出錯信息主要包括錯誤發生的位置(行數)出錯的信息(是哪一種類的錯誤以及如何修改的建議),并按照出錯程度分為錯誤(缺少必要成份的情況)和異常(其他情況);領域術語候選詞是系統從該用戶故事文檔中提取并反饋的候選領域術語,供領域專家從中確認并選擇.確認后的領域術語詞被加入領域術語庫,用于系統的分詞,促進用戶故事模型構建.

Fig. 5 A screenshot of the workspace of the USQI tool圖5 USQI工具用戶故事質量檢測工作界面

USQI工具采用基于Java的編程語言,遵循MVC(model-view-controller)的設計思想,其組成構件如圖6所示.USQI主要包括4個子系統:用戶故事建模(user story modeling)、缺陷檢測(detecting defects)、領域知識庫構建(knowledge base generator)以及數據存儲(data storage).用戶故事建模從用戶故事中抽取關鍵概念信息并對這些關鍵概念進行缺陷檢測,進而生成用戶故事質量模型(user story model,USM).缺陷檢測主要包括結構分析、句法模式分析以及語義分析3個構件,分別用于發現用戶故事中存在的違背11條質量準則的用戶故事缺陷.領域知識庫的構件識別用戶故事文檔中的領域知識(領域術語、同義詞、模糊詞等).數據的存儲包括用戶故事質量模型(USM)的存儲、缺陷信息的存儲以及知識庫信息的存儲,為不同構建提供數據支持.

5.2 度量標準

檢測工具反饋故事中可能存在的缺陷信息.本文采用準確率和召回率度量缺陷反饋結果的效果.準確率表示在工具反饋的結果中正確反饋的占比.召回率指在故事集的所有缺陷中正確反饋的占比.設Def表示工具反饋的缺陷數量；FP表示工具反饋結果中誤報的缺陷數量；FN表示工具反饋結果中漏報的缺陷數量.準確率prec和召回率rec分別計算為

5.3 用戶故事集

本文針對來自某企業的關于智能手機的一組用戶故事數據集開展實驗研究.該組數據集共有36個用戶故事,包含84個場景,所有用戶故事均采用圖1所示的推薦格式編寫.為了對這些數據進行有效分析,首先征集6名來自需求分析研究小組的研究生組成了評估小組,分別對這些用戶故事進行缺陷標注、分類以及對自動化工具反饋結果進行正確與否的確認工作.經過人工分類和整理,將這些用戶故事按照聯系人、郵件、短信、備忘錄、在線市場等分為5類關注點.自動化檢測工具反饋了173個缺陷.表3展示了故事數量(#Fn)、場景的數量(#Sn)以及缺陷數量(Def).

表4統計了工具反饋的173個缺陷的類型:針對聯系人、郵件、短信、備忘錄、在線市場為關注點的故事集分別統計違背了表2所示準則(本實驗沒有考慮功能完整性和獨立性)的缺陷數、誤報數和漏報數.

Table 4 Number of Defects,False Positives and False Negatives for Each Quality Criterion in the Experimental Data Set

表5展示了所有反饋結果中不同準則的缺陷數、誤報數、漏報數以及準確率和召回率的統計結果.結果表明針對智能手機的這組實驗數據集,平均準確率為88.79%和95.06%.

Table 5 The Number of Defects,False Positives, False Negatives, Precision and Recall for Each

表6展示了當閾值為0.7,0.8和0.9時智能手機用戶故事實驗數據集中故事之間合作關系與依賴關系的識別結果.包括對聯系人、郵件等用戶故事集合中合作關系與依賴關系的數量(Rel)、誤報的數量(FP)、漏報的數量(FN).采用5.1節中準確率和召回率的計算方法(其中Def替換為Rel).從統計結果可以看出,合作關系和依賴關系的反饋結果在閾值為0.8時取得較好的結果:平均準確率分別為83.33%和72.73%,平均召回率分別為80.35%和80%.

Table 6 Statistics Table of User Story Relationships When the Thresholds of Cooperation and

5.4 結果與分析

從表5的統計結果可以看出,出現缺陷最多的類型是語言成份問題和原子性問題,其數量在總缺陷數的占比分別為31%和41%;缺陷反饋結果的準確率分別是70.37%和78.87%;召回率分別是90.48%和91.8%.我們對產生缺陷的故事描述進行分析,發現出現“語言成份”問題的主要原因是省略了一些必要的語法成份,使得自然語言分析工具不能識別出完整的句子成份.例如:“Then 無法點擊”(省略了主語);“I want to本地文檔名稱及文檔內容”(省略了動詞).還有一些描述增加了一些不必要的信息,例如,“用戶輸入關鍵字搜索”(輸入和搜索都是動詞).存在原子性問題的缺陷的描述通常也是由于寫故事的人在表達句式方面存在問題,例如,有的描述經常會省略一些表示定語關系或狀態的助詞(的,地， 在…上,當…時等),使得自然語言分析工具認為一個短句有2個動詞,如“全局搜索在線電子書中信息”，“When 進入全屏模式查看圖片”.也有一些描述包含了過多的信息,應該拆分.例如，“跳轉到Email正文詳情界面顯示Email全部信息”實際上是2部分信息.

針對檢測結果中誤報的情況,分析表明不準確的分詞是產生誤報的主要問題.例如,一些術語詞匯沒有被包含到術語庫中,使得自然語言分析方法不能準確地分析句子的成份.例如，“進入在線生活服務”,“啟動商品購買界面”中“在線生活服務”和“商品購買界面”是術語詞,而自然語言分析工具將其分割為多個詞.本文將領域術語抽取方法加入到需求質量提升框架中,通過不斷地更新領域術語詞庫,提高分詞的有效性,經過人工核查,一些由于分詞原因造成的誤報有所降低.

在自動化缺陷檢測結果中,關鍵概念不缺失、可估算、不重復方面的缺陷反饋結果的準確率和召回率都達到了100%.主要原因在于認定違背上述準則的規則較為簡單:關鍵概念的判斷通過分析角色和意圖是否非空;可估算是判斷一個故事是否有場景描述;關于不重復的判斷問題,本文主要根據文本表達是否完全相同.

從表6的統計結果可以看出：基于關系挖掘的方法從一組用戶故事中發現存在合作關系及依賴關系的故事對,具有較高的準確率(83.33%和72.73%)和召回率(80.35%和80%).人工檢查誤報和漏報的關系發現:對于合作關系的故事,通常由于角色和意圖中操作對象不同時,會產生漏報;當一些故事省略了一些狀態信息時,會產生誤報.對于依賴關系,漏報主要發生在一些目標中沒有描述與其他故事之間的關系;誤報主要發生在有些動詞和對象具有較高的相似性(但在語義上并不相似).

6 總 結

本文提出了一種基于自然語言和模型驅動相結合的故事需求質量提升方法,以檢測一組給定的用戶故事是否存在不完整、不一致和不可測方面的缺陷.該方法主要包括3個關鍵部分:故事質量準則的制定、故事質量模型的構建和基于故事質量準則的缺陷檢測.本文根據實際案例總結出11條用戶故事編寫應該遵循的質量準則.與現有故事質量準則相比,本文提出的故事質量準則一方面在完整性和一致性方面對故事的質量進行評估,另一方面考慮了故事測試及故事間關系相關的質量問題.提出采用故事結構分析、句法模式分析以及語法分析等技術自動構建帶場景的用戶故事的模型,并根據準則進行故事缺陷檢測.最后,本文針對包含36個用戶故事和84個場景的數據集開展實驗研究,結果表明本文提出的需求質量缺陷檢測方法的有效性.本文提出的方法將有助于迭代式的用戶故事需求建模和用戶故事質量的不斷提升.