張曉?shī)u，鄭麗偉

(北京信息科技大學(xué) 計(jì)算機(jī)學(xué)院，北京 100101)

0 引 言

在開發(fā)大型軟件項(xiàng)目的過程中，軟件需求通常頻繁變更并且該過程通常貫穿整個(gè)軟件開發(fā)周期，開發(fā)者需要經(jīng)過長(zhǎng)時(shí)間的反復(fù)發(fā)現(xiàn)和認(rèn)識(shí)才能逐步明確軟件需求。因此，軟件開發(fā)者也開始逐漸將一部分的注意力從軟件開發(fā)編程階段轉(zhuǎn)移到了軟件需求設(shè)計(jì)階段以減少軟件產(chǎn)品的迭代次數(shù)。軟件需求按照軟件功能性可以分為功能性需求和非功能性需求兩類[1]。相較于功能性需求，軟件的非功能性需求往往具有較大的隱含性和不確定性，難以準(zhǔn)確獲取。

近年來，針對(duì)軟件需求的表示、抽取、挖掘等工作取得顯著成果，但也存在用戶需求數(shù)據(jù)較難獲取，數(shù)據(jù)種類較單一，挖掘結(jié)果易受領(lǐng)域局限等問題。針對(duì)這些問題，我們認(rèn)為通過機(jī)器學(xué)習(xí)方法從GitHub等軟件開發(fā)類社交平臺(tái)的海量數(shù)據(jù)中發(fā)現(xiàn)潛在的軟件非功能需求是一種可行的思路。本文以軟件非功能性需求中較為重要的安全性需求作為切入點(diǎn)，以GitHub中龐大的Issues討論數(shù)據(jù)作為挖掘?qū)ο?，利用自然語(yǔ)言處理中的實(shí)體識(shí)別技術(shù)對(duì)句子中的連接實(shí)體進(jìn)行識(shí)別并在此背景下設(shè)計(jì)出了一種用戶故事生成方法——CreUS用戶故事生成方法，旨在將抽取到的用戶安全需求以用戶故事這種結(jié)構(gòu)化的方法表示出來。所生成的用戶故事集，不僅可用于支持Issues所在項(xiàng)目的開發(fā)迭代，還可以作為領(lǐng)域知識(shí)，在同領(lǐng)域類似項(xiàng)目的需求發(fā)現(xiàn)中起到重要的參考和輔助作用。

1 研究背景

1.1 需求工程

在計(jì)算機(jī)剛剛發(fā)展起來的階段，人們對(duì)于軟件項(xiàng)目的開發(fā)大多關(guān)注在如何更好進(jìn)行代碼編寫上。隨著編程技術(shù)發(fā)展的日趨成熟，人們開始將更多的焦點(diǎn)轉(zhuǎn)移到了需求分析上。一開始，軟件需求分析階段僅僅只是作為軟件開發(fā)生命周期中的第一階段，隨著軟件項(xiàng)目規(guī)模不斷擴(kuò)大，其復(fù)雜性也相應(yīng)增加，需要被滿足的功能愈來愈多。伴隨著諸多問題的產(chǎn)生，人們意識(shí)到如果只是把需求分析階段作為一個(gè)開發(fā)過程中的階段是不夠的，也許在軟件開發(fā)整個(gè)生命周期中都會(huì)伴隨著需求的增加與改進(jìn)。在80年代中期，需求工程(requirement engineering，RE)作為軟件工程的一個(gè)子領(lǐng)域被提出，這也意味著軟件需求工程開始作為一個(gè)獨(dú)立的研究方向出現(xiàn)。

1.2 安全性需求探索

研究者對(duì)安全性需求的探索從未中斷，甚至在需求工程和安全的交叉領(lǐng)域提出了安全需求工程的概念。安全需求工程旨在通過一系列框架方法來重新解決軟件安全需求相關(guān)問題。例如Guarín等[2]對(duì)容易遭到攻擊的財(cái)產(chǎn)去進(jìn)行危險(xiǎn)分析從而從風(fēng)險(xiǎn)角度來獲取安全需求，把網(wǎng)絡(luò)應(yīng)用程序作為研究目標(biāo)，通過提出一種在敏捷環(huán)境下的安全需求審查辦法來幫助開發(fā)人員更好探測(cè)軟件安全需求缺陷。上述工作在安全需求問題領(lǐng)域做出了不可否認(rèn)的貢獻(xiàn)，但是在需求發(fā)現(xiàn)方面仍然無法避免因系統(tǒng)復(fù)雜性和各類環(huán)境因素帶來的需求頻繁變更等問題。Mavin等[3]針對(duì)安全問題提出了一種框架用于處理安全需求工程問題，通過從安全需求的問題本體領(lǐng)域角度出發(fā)，提出了一種3層的認(rèn)知方法，從而細(xì)化安全需求。Singh等[4]則是針對(duì)安全性需求，將其從根本類別上劃分出來，認(rèn)為其既不屬于功能性需求，也不屬于非功能性需求，為了將其更好地界定出來，利用公開的SecReq數(shù)據(jù)集，對(duì)22種監(jiān)督機(jī)器學(xué)習(xí)分類算法和兩種深度學(xué)習(xí)方法在分類安全需求方面的性能進(jìn)行了實(shí)證，結(jié)果表明，在無監(jiān)督算法中，長(zhǎng)短期記憶(LSTM)網(wǎng)絡(luò)的準(zhǔn)確率最高(84%)，在有監(jiān)督算法中，增強(qiáng)集成(boost Ensemble)的準(zhǔn)確率最高(80%)。Villamizar等[5]將網(wǎng)絡(luò)應(yīng)用程序作為研究目標(biāo)，提出一種在敏捷開發(fā)環(huán)境下的安全需求審查辦法，該方法將用戶故事和安全規(guī)范相結(jié)合，對(duì)安全性需求進(jìn)行審查，結(jié)果表明針對(duì)新手開發(fā)人員具有較好的效果。

1.3 軟件需求挖掘與抽取

從海量的網(wǎng)絡(luò)數(shù)據(jù)中挖掘出有價(jià)值的知識(shí)和信息是進(jìn)行用戶需求抽取的有效途徑，目前已經(jīng)有很多研究人員針對(duì)社交數(shù)據(jù)進(jìn)行了需求挖掘，比如Martns等利用Twitter上的官方賬號(hào)(如Netflix、Spotify)去收集用戶反饋[6]；Hassan等[7]通過對(duì)谷歌用戶商店中開發(fā)者和用戶的對(duì)話追蹤產(chǎn)品信息，查找產(chǎn)品缺陷從而對(duì)用戶提供支持；在需求抽取方面，Raharjana等[8]針對(duì)網(wǎng)絡(luò)新聞提出了一種概念模型提取用戶故事，但是該方法機(jī)制不靈活，存在一定的局限性，作者也提到對(duì)于未來可能會(huì)借助機(jī)器學(xué)習(xí)的方法對(duì)其進(jìn)行完善，提高抽取效果；胡田媛等[9]針對(duì)應(yīng)用商店中的APP評(píng)論進(jìn)行挖掘與抽取，采用基于人工標(biāo)注的少量初始評(píng)論種子持續(xù)構(gòu)建候選評(píng)論模式庫(kù)，通過使用循環(huán)挖掘的方式進(jìn)行匹配,動(dòng)態(tài)擴(kuò)大挖掘體現(xiàn)不同使用反饋類型的 APP 軟件用戶評(píng)論的范圍；Cui等[10]提出基于評(píng)論的需求挖掘方法RERM，通過使用本體和條件隨機(jī)場(chǎng)模型對(duì)相關(guān)特征進(jìn)行提取，對(duì)軟件存在的相關(guān)問題進(jìn)行分類，如改進(jìn)意見和產(chǎn)品缺陷等；Panichella等[11]對(duì)用戶評(píng)論使用一種自然語(yǔ)言解析器進(jìn)行特征抽取，通過對(duì)句子的相關(guān)語(yǔ)法進(jìn)行分析確定用戶反饋或者產(chǎn)品問題。

通過以上的分析研究，我們發(fā)現(xiàn)還很少有人將用戶故事作為需求的表達(dá)載體，同時(shí)大多數(shù)學(xué)者的研究思路都是針對(duì)句子的語(yǔ)法結(jié)構(gòu)對(duì)內(nèi)容進(jìn)行抽取，在此基礎(chǔ)上，我們針對(duì)句子中的連接詞對(duì)用戶需求進(jìn)行抽取，并以用戶故事模板作為需求表達(dá)形式。

2 整體框架

規(guī)范的用戶需求不僅便于項(xiàng)目的迭代演進(jìn)，還能在一定程度上便于領(lǐng)域內(nèi)不同項(xiàng)目間的需求重用。本文主要工作包括以下內(nèi)容：

(1)篩選安全性需求相關(guān)數(shù)據(jù)；所獲取到的Issues原數(shù)據(jù)并不是所有的都可以進(jìn)行需求提取，因此需要從中篩選出符合需要的數(shù)據(jù)；

(2)提出一種通過對(duì)句子中的連接實(shí)體進(jìn)行實(shí)體識(shí)別進(jìn)而對(duì)Issues語(yǔ)句中的需求進(jìn)行抽取的方法，主要針對(duì)3類句內(nèi)連接實(shí)體來完成安全需求的抽??；

(3)基于需求抽取給出一種用戶故事生成方法——CreUS。該方法根據(jù)語(yǔ)句中的連接實(shí)體和連接實(shí)體的位置制定生成用戶故事的策略和規(guī)則，進(jìn)而生成用戶故事；

(4)基于針對(duì)特定實(shí)際項(xiàng)目的案例分析，對(duì)所生成的用戶故事實(shí)用價(jià)值進(jìn)行評(píng)價(jià)。

系統(tǒng)整體研究框架如圖1所示。

圖1 CreUS系統(tǒng)整體框架

3 數(shù)據(jù)篩選

3.1 數(shù)據(jù)來源

從廣義角度來看，需求工程是一個(gè)逐步明確目的的過程，通過確定利益相關(guān)者(stakeholders)的需求并將這些需求以一種便于分析、溝通和后續(xù)實(shí)現(xiàn)的形式記錄下來。其中利益相關(guān)者包括很多角色并且范圍較為廣泛，主要包括付費(fèi)客戶、用戶和開發(fā)人員[12]。GitHub作為一個(gè)面向開發(fā)者的技術(shù)社區(qū)，迄今為止已經(jīng)為超過5000萬(wàn)的用戶提供了一個(gè)可供分享，可以共同協(xié)作完成軟件開發(fā)的平臺(tái)。開發(fā)者在上面不僅可以托管開發(fā)項(xiàng)目，提交代碼，進(jìn)行代碼評(píng)審，同時(shí)還可以交流相關(guān)開發(fā)經(jīng)驗(yàn)，以便開發(fā)者們之間互相之間進(jìn)行學(xué)習(xí)。在GitHub的開發(fā)項(xiàng)目的功能板塊中有一個(gè)Issues版塊，該板塊的主要目的是為平臺(tái)上的開發(fā)者提供一個(gè)交流平臺(tái)，開發(fā)者們?cè)谶@上面可以對(duì)相關(guān)代碼功能提出改進(jìn)建議或者對(duì)項(xiàng)目運(yùn)行之后的結(jié)果給予相關(guān)反饋。Issues是GitHub為各類平臺(tái)使用者提供的一種交流工具，通常被用來追蹤各種用戶想法、任務(wù)、bug、完善用戶功能等。

另外，當(dāng)用戶發(fā)布Issues對(duì)軟件功能進(jìn)行反饋的時(shí)候，對(duì)于某些評(píng)論可能會(huì)帶有身份標(biāo)簽；標(biāo)簽主要包含兩種，分別是Author標(biāo)簽和Member標(biāo)簽，其中Author標(biāo)簽代表發(fā)布這條Issues的作者；Member標(biāo)簽代表參與構(gòu)造這個(gè)軟件項(xiàng)目的成員；此外，還有其它參與到此條Issues中的評(píng)論者，此時(shí)，他們的反饋沒有身份標(biāo)簽顯示；3種情況分別如圖2～圖4所示。

圖2 Issues的提出者-Author標(biāo)簽

圖3 項(xiàng)目中的程序開發(fā)成員-Member標(biāo)簽

圖4 其余參與到Issues中的評(píng)論人員-無標(biāo)簽

明確此類標(biāo)簽之后，在數(shù)據(jù)爬取階段可以根據(jù)身份標(biāo)簽篩選相關(guān)數(shù)據(jù)。

3.2 數(shù)據(jù)獲取及篩選

利用GitHub 官方API工具，從217個(gè)項(xiàng)目中一共爬取了25 490條Issues。考慮到主要目的在于挖掘用戶的潛在需求，因此根據(jù)上面提到的GitHub Issues概念中的身份標(biāo)簽，本次數(shù)據(jù)爬取過程中過濾掉了帶有標(biāo)簽的Issues數(shù)據(jù)，只選擇從用戶的角度發(fā)出的評(píng)論或反饋，其相應(yīng)標(biāo)簽對(duì)應(yīng)為標(biāo)簽或者無標(biāo)簽。過濾標(biāo)簽類別之后，在生成用戶故事時(shí)角色為了統(tǒng)一，全部定義為“User”。

將獲取到的Issues數(shù)據(jù)進(jìn)行分類從而得到符合研究要求的數(shù)據(jù)。本次實(shí)驗(yàn)數(shù)據(jù)需要滿足“需求”和“安全”兩個(gè)方面，基于這兩點(diǎn)考慮，決定將這里的工作內(nèi)容分成兩部分：①找出Issues語(yǔ)句中和需求相關(guān)的語(yǔ)句；②建立安全性需求初始特征詞表，從①得到的數(shù)據(jù)結(jié)果中按照安全性特征詞表進(jìn)行篩選，可以大概率認(rèn)為該條語(yǔ)句描述和安全性需求有關(guān)；通過以上兩個(gè)步驟最后得到的數(shù)據(jù)可以認(rèn)為基本滿足所期望的數(shù)據(jù)要求，數(shù)據(jù)分類具體工作內(nèi)容如下：

(1)篩選出Issues中的需求描述語(yǔ)句

參考文獻(xiàn)[13]中作者提出的一種界定需求(dema-rcating requirements)問題的新方法，基于該方法，本文對(duì)對(duì)篩選出的Issues語(yǔ)句中包含的需求描述加以識(shí)別。數(shù)據(jù)特征化完成后，本文分別選用邏輯回歸(logistic regression，LR)方法、支持向量機(jī)方法(support vector machine，SVM)、和決策樹(decision tree，DT)方法進(jìn)行訓(xùn)練分類模型并進(jìn)行效果比較。3種方法的評(píng)估采用準(zhǔn)確率A(Accuracy)、精確率P(Precision)和召回率R(Recall)。選用五折交叉驗(yàn)證的方式對(duì)實(shí)驗(yàn)結(jié)果取平均值，得到的結(jié)果見表1，SVM的方法要優(yōu)于其余兩種方法，因?yàn)樵诒締栴}上傳統(tǒng)機(jī)器學(xué)習(xí)方法均表現(xiàn)較好，所以未對(duì)深度學(xué)習(xí)等新興方法進(jìn)行比較。

表1 3種模型分類結(jié)果比較

(2)進(jìn)行安全性需求篩選

在步驟(1)篩選出需求相關(guān)數(shù)據(jù)見表2，然后通過建立安全性關(guān)鍵詞屬性篩選出安全相關(guān)需求，經(jīng)過這兩個(gè)步驟之后，可以認(rèn)為最后得到的數(shù)據(jù)為基本滿足需要的目標(biāo)數(shù)據(jù)，即與安全需求相關(guān)的Issues語(yǔ)句，其結(jié)果見表3。

表2 需求數(shù)據(jù)分類結(jié)果

表3 安全需求數(shù)據(jù)分類結(jié)果

所建立的關(guān)鍵詞表用來表示安全性需求分類的初始特征詞，表中描述詞匯主要整理、提取來自相關(guān)文獻(xiàn)[1]，其結(jié)果見表4。

表4 安全性需求相關(guān)詞匯描述

3.3 數(shù)據(jù)預(yù)處理

對(duì)于上述步驟操作得到的數(shù)據(jù)需要對(duì)數(shù)據(jù)內(nèi)容進(jìn)行預(yù)處理操作，使用正則表達(dá)式去除句子中無用的鏈接和代碼?？紤]到Issues的語(yǔ)言表達(dá)形式為英文形式，其中可能包含一些詞形變換，因此需要對(duì)一些詞語(yǔ)進(jìn)行詞形還原，這樣才能保證不會(huì)影響后續(xù)操作。例如，短語(yǔ)詞組“would like to”在有些句子中用戶可能會(huì)將其口語(yǔ)化表達(dá)為“I’d like to”，這種情況不利于研究后續(xù)對(duì)數(shù)據(jù)進(jìn)行標(biāo)注，因此需要將其還原為“I would like to”。

4 句內(nèi)連接實(shí)體識(shí)別

在敏捷環(huán)境下，用戶故事作為表達(dá)用戶需求的重要方法，對(duì)于軟件項(xiàng)目的開發(fā)有著巨大的影響。用戶故事作為敏捷開發(fā)中一種有效的需求表示形式在實(shí)際開發(fā)中廣泛應(yīng)用。生成的用戶故事集，不僅可用于支持Issues所在項(xiàng)目的開發(fā)迭代，還可以作為領(lǐng)域知識(shí)，在同領(lǐng)域類似項(xiàng)目的需求發(fā)現(xiàn)中起到重要的參考和輔助作用。Issues數(shù)據(jù)往往較為雜亂，如果能夠?qū)⑵湟?guī)范化，將會(huì)大大提高它的可用性。因此，需要按照用戶故事模板對(duì)用戶故事進(jìn)行提取。提取格式按照用戶故事英文模板格式： As a ,I want to ,so that .具體見表5。

表5 用戶故事模板

用戶發(fā)表的Issues通常具有不同的表達(dá)形式，為了保證抽取工作的準(zhǔn)確性，需要根據(jù)不用的句子特征對(duì)用戶故事進(jìn)行提取。提取用戶故事只需要關(guān)注3個(gè)方面，分別是角色、行為和收益(原因)，鑒于在爬取過程中已經(jīng)對(duì)角色標(biāo)簽進(jìn)行了篩選，所以用戶故事角色可全部統(tǒng)一為“User”，接下來的任務(wù)就是如何對(duì)用戶行為和行為原因進(jìn)行抽取。

想要準(zhǔn)確的分離一句話中的用戶行為和行為原因，必須抓住其中起關(guān)鍵作用的句內(nèi)連接實(shí)體然后對(duì)其進(jìn)行分割?？紤]到之前已經(jīng)在此方向上對(duì)軟件需求實(shí)體方面進(jìn)行研究，并且取得了較好的效果,為了提高對(duì)于句內(nèi)連接實(shí)體的識(shí)別效率，考慮使用了自然語(yǔ)言處理領(lǐng)域中對(duì)于實(shí)體識(shí)別的研究方法，在之前的基礎(chǔ)上將其遷移到本次句內(nèi)連接實(shí)體識(shí)別。

在本課題組前期相關(guān)工作中，使用Bi-LSTM+CRF實(shí)體識(shí)別方法對(duì)面向軟件開發(fā)社交網(wǎng)絡(luò)的軟件功能需求實(shí)體進(jìn)行識(shí)別。本文實(shí)驗(yàn)中直接采用上述方法對(duì)句內(nèi)連接實(shí)體進(jìn)行識(shí)別，該方法的性能比較以及實(shí)驗(yàn)數(shù)據(jù)分析參見文獻(xiàn)[14]。

為了方便，在這里定義了一個(gè)新的概念——句內(nèi)連接實(shí)體。句內(nèi)連接實(shí)體是指通常句子內(nèi)部會(huì)存在一些典型的連接詞或短語(yǔ)。該類詞語(yǔ)或者短語(yǔ)的上下文前后會(huì)對(duì)用戶行為和行為原因進(jìn)行描述，并將這些連接詞或短語(yǔ)稱作句內(nèi)連接實(shí)體。值得注意的是，本文提到的句內(nèi)連接實(shí)體的概念不同于英語(yǔ)語(yǔ)法中的連詞的概念，連接實(shí)體還會(huì)包括一些連接短語(yǔ)表達(dá)。例如在下面的Issues語(yǔ)句中：

Itwould be nice tohave a short security summary in each crate documentation which would include known insecurities,applicability,etc.

其中，“would be nice to”不屬于英語(yǔ)語(yǔ)法中的連詞范疇，但是通過對(duì)“would be nice to”這類短語(yǔ)的識(shí)別可以切分該短語(yǔ)后面的句子作為用戶行為，完成用戶故事提取。因此該短語(yǔ)是句內(nèi)連接實(shí)體；

句內(nèi)連接實(shí)體包含的短語(yǔ)或者連接詞的種類眾多，在此，針對(duì)軟件需求領(lǐng)域，定義句內(nèi)連接實(shí)體的范圍主要包括以下3種：表因果關(guān)系的連接實(shí)體；表意愿關(guān)系的連接實(shí)體；表建議關(guān)系的連接實(shí)體。主要集中在這3類連接實(shí)體的原因在于，根據(jù)用戶故事模板，可以推測(cè)出這3類連接實(shí)體的句子中包含其三要素中的一個(gè)或幾個(gè)，因此可以作為出發(fā)點(diǎn)來進(jìn)行用戶故事生成。

5 CreUS用戶故事生成方法

用戶故事是在軟件開發(fā)過程中的一種需求描述形式，多用于在敏捷開發(fā)環(huán)境下。用戶故事的詳細(xì)定義請(qǐng)參見文獻(xiàn)[15]。

用戶故事通常按表5所示模板描述。例如：“作為一名[學(xué)生]，我想要[輕松地完成密碼修改任務(wù)]，以便于[我可以及時(shí)保證我的個(gè)人隱私]?！?/p>

本文針對(duì)不同Issues安全性需求語(yǔ)句特點(diǎn)制定相應(yīng)的用戶故事元素提取規(guī)則；同時(shí)在用戶故事表示中使用“下劃線”來表示用戶行為，例如用戶行為；使用雙下劃線來表示行為收益，例如行為收益。

針對(duì)用戶故事的抽取本文提出了CreUS算法，該算法主要是面向蘊(yùn)含潛在的用戶需求的Issues語(yǔ)句，通過上一小節(jié)的步驟對(duì)語(yǔ)句中的連接實(shí)體進(jìn)行識(shí)別之后，還要根據(jù)不同語(yǔ)句類別和實(shí)體類型制定相應(yīng)的規(guī)則進(jìn)行抽取。該算法主要是從兩個(gè)方面進(jìn)行考慮，分別是句子類型和連接實(shí)體兩個(gè)層面，基于這兩個(gè)角度，制定了如下規(guī)則：

(1)如果句子中含有句內(nèi)連接實(shí)體，則：

規(guī)則1：對(duì)表因果關(guān)系的句內(nèi)連接實(shí)體，將連接實(shí)體的前綴作為用戶行為，后綴作為行為原因，例如so that，because，in order that等；

規(guī)則2：對(duì)表意愿關(guān)系的句內(nèi)連接實(shí)體，將句內(nèi)連接實(shí)體的前綴作為行為原因，后綴作為用戶行為，例如would like to，want to，hope to等。

規(guī)則3：對(duì)表建議關(guān)系的句內(nèi)連接實(shí)體，將句內(nèi)連接實(shí)體前綴作為行為原因，后綴作為用戶行為，例如would be great to，be nice to，suggest that等。

(2)經(jīng)過了上一步對(duì)于句內(nèi)連接實(shí)體的判斷，還要針對(duì)Issues需求語(yǔ)句不同的表達(dá)形式，將二者結(jié)合起來并給出如下規(guī)則：

規(guī)則1：句中無標(biāo)點(diǎn)符號(hào)，單獨(dú)短語(yǔ)成句,帶有祈使的語(yǔ)氣，在這種情況下，可將全部文本內(nèi)容作為用戶行為原因，并且在用戶行為上使用“Action”進(jìn)行補(bǔ)全，舉例如下：

原Issues語(yǔ)句：

insecure firebase architecture.

提取用戶故事：

As a user,I want Action, so that insecure firebase architecture.

規(guī)則2：對(duì)于含有句內(nèi)連接實(shí)體的簡(jiǎn)單句，首先識(shí)別句子中的連接實(shí)體并確定其所屬種類，然后按照(1)中對(duì)應(yīng)的規(guī)則進(jìn)行抽取，舉例如下：

原Issues語(yǔ)句：

finish session and login work so that the session is in the db and that the login is secure.

提取用戶故事：

As a user,I want to finish session and login work, so that the session is in the db and that the login is secure.

規(guī)則3：往往用戶的反饋不僅僅是一句，而是由多個(gè)語(yǔ)句構(gòu)成的集合。對(duì)于含有多個(gè)語(yǔ)句的段落，如果其中只有一個(gè)句內(nèi)連接實(shí)體的話根據(jù)該句內(nèi)連接實(shí)體所處的位置和所在的句子進(jìn)行分割，同樣在對(duì)句子進(jìn)行分割的時(shí)候遵循(1)中的規(guī)則。例如：

原Issues語(yǔ)句：

the current 20 character limit on passwords is too short for secure passphrases. would be great to support lon-ger passwords eg: 128+ characters especially considering unicode chars take up more than one character in the pass-word manager.

對(duì)于該句，其中只包含一個(gè)句內(nèi)連接實(shí)體。找到句內(nèi)連接實(shí)體would be great to所在的位置，對(duì)前后文進(jìn)行劃分；按照句內(nèi)連接實(shí)體屬性規(guī)則，生成的用戶故事如下：

提取用戶故事：

As a user, I want to support longer passwords eg: 128+ characters especially considering unicode chars take up more than one character in the password manager so that the current 20 character limit on passwords is too short for se-cure passphrases.

規(guī)則4：在同一段落文本中，句內(nèi)連接實(shí)體可能不止出現(xiàn)了一次，一段文本中可能含有兩個(gè)或者兩個(gè)以上句內(nèi)連接實(shí)體，對(duì)于這種情況，按照句內(nèi)連接實(shí)體的位置將句子分割，之后重復(fù)規(guī)則3。對(duì)于一段文本中含有多個(gè)句內(nèi)連接實(shí)體的句子就表明用戶可能有多個(gè)需求，因此這樣的話就需要找出句中所有句內(nèi)連接實(shí)體并對(duì)潛在的用戶需求進(jìn)行拆解，從而保證需求提取的完整性，示例如下：

原Issues語(yǔ)句：

句子1:hashed key is the password hash from user specified plaintext password using crypto_pwhash. it is a hash value but used as a key, so it must be protected by safebox as same as other keys.(第一個(gè)連詞結(jié)尾處對(duì)段落進(jìn)行分割)句子2:although the current password hash has drop to clear it, but it is allocated on stack which is weaker than the secured heap and potential to be persistent. so it should be u-sing same safebox as a normal key to enhance security.

重復(fù)步驟規(guī)則3，對(duì)已獲得到的句子進(jìn)行用戶故事提取，如下：

提取用戶故事：

As a user, I want protected by safebox as same as other keys, so that hashed key is the password hash from us-er specified plaintext password using crypto_pwhash. it is a hash value but used as a key.

As a user,I want to use same safebox as a normal key to enhance security, so that although the current pass-word hash has drop to clear it, but it is allocated on stack which is weaker than the secured heap and potential to be persistent.

基于Issues安全性需求描述文本的用戶故事生成算法如下：

算法1：CreUS用戶故事生成算法

Input： 處理后的Issues語(yǔ)句

Output： Issues語(yǔ)句對(duì)應(yīng)的用戶故事

Variable： SenEntityNum /*Issues語(yǔ)句中所含連接實(shí)體的數(shù)目*/

JustSinglePhrase /*句中無標(biāo)點(diǎn)符號(hào)，單獨(dú)短語(yǔ)成句*/

SenNum /*輸入Issues語(yǔ)句中完整句子數(shù)目*/

SenIsSimple /*輸入Issues語(yǔ)句為簡(jiǎn)單句*/

BeforeJoinEntity /*連接實(shí)體前文內(nèi)容*/

AfterJoinEntity /*連接實(shí)體后文內(nèi)容*/

RolePart /*用戶故事模板中用戶角色，統(tǒng)一為：User*/

ActionPart /*用戶故事模板中用戶行為部分*/

ReasonPart /*用戶故事模板中行為原因部分*/

Function：/*所用到的函數(shù)*/

Check() /*如果連接實(shí)體前后文為空則進(jìn)行關(guān)鍵詞補(bǔ)全處理*/

(1) If(BeforeJoinEntity.content == null)

(2) Then “Action”→UserStory.ActionPart

(3) Return

(4) If(AfterJoinEntity.content == null)

(5) Then “Reason”→UserStory.reasonPart

(6) Return

MakeUserStory()/*創(chuàng)建用戶故事函數(shù)*/

JudgeEntityType()： /*判斷連接實(shí)體類型*/

(1)If(JudgeEntityType==1)/*如果是表示因果關(guān)系的實(shí)體*/

(2)ThenIssues. BeforeJoinEntity → UserStory.Action-Part；

(3) Issues. AfterJoinEntity →UserStory.Reason-Part

(4)MakeUserStory(RolePart+ActionPart+ReasonPart)

(5)ElseIf(JudgeEntityType==2‖JudgeEntityType==3)

/*如果實(shí)體是表示意愿關(guān)系或者表示建議關(guān)系的連接實(shí)體*/

(6)ThenIssues. AfterJoinEntity → UserStory.Action-Part；

(7) Issues. BeforeJoinEntity →UserStory.Reason-Part

(8)MakeUserStory(RolePart+ActionPart+ReasonPart)

CutSenByEntity() /*根據(jù)連接實(shí)體位置分割句子*/

Main()/*主函數(shù)*/

Begin:

(1)If(Issues.JustSinglePhrase == True)

(2)ThenIssues.WholeContent →UserStory.Reason-Part

(3) “Action”→UserStory.ActionPart

(4)MakeUserStory(RolePart+ActionPart+ReasonPart)

(5)ElseIf(Issues.SenEntityNum == 1 && SenNum ==1)

(6)Check();

(7)JudgeEntityType(Issues.entity)

(8)ElseIf(Issues.SenEntityNum == 1 && SenNum >1)

(9)Check()

(10)JudgeEntityType(Issues.entity)

(11)ElseIf(Issues.SenEntityNum >1 && SenNum >1)

(12)CutSenByEntity()/*通過實(shí)體對(duì)段落句子進(jìn)行分割*/

(13)Repeat(Step(5)～Step(10))

(14)ElseCatchException()

(15)Return

End

本算法時(shí)間復(fù)雜度為O(n)。復(fù)雜度較低的原因主要是前期數(shù)據(jù)篩選和實(shí)體識(shí)別承擔(dān)了較大工作量。

6 案例分析

本文從GitHub抓取的Issues數(shù)據(jù)中篩選出425條安全相關(guān)Issues，通過上文提供的算法，從這些Issues語(yǔ)句中抽取到157條用戶故事。其中，不含語(yǔ)義錯(cuò)誤的用戶故事共有52條。在GitHub中選取若干真實(shí)項(xiàng)目案例，通過計(jì)算用戶故事覆蓋率分析抽取到的用戶故事在實(shí)際項(xiàng)目中的實(shí)用性。

為了進(jìn)行用戶故事實(shí)用價(jià)值判定，使用人工的方式對(duì)52條用戶故事進(jìn)行分類，所采用的分類標(biāo)準(zhǔn)是文獻(xiàn)[16]里面Donald Firesmith所提出的12種安全性需求，即：①鑒別需求；②驗(yàn)證需求；③授權(quán)需求；④免疫性需求；⑤完整性需求；⑥入侵檢測(cè)需求；⑦不可否認(rèn)需求；⑧秘密需求；⑨安全審計(jì)需求；⑩可存活性需求；物理保護(hù)需求；系統(tǒng)維修安全性需求。按照這12類標(biāo)簽對(duì)用戶故事進(jìn)行分類，分類情況見表6。

表6 用戶故事按照安全需求標(biāo)準(zhǔn)進(jìn)行分類

在GitHub上選取15個(gè)實(shí)際開發(fā)項(xiàng)目，其項(xiàng)目列表見表7；所選取的項(xiàng)目均為比較完整且權(quán)威的項(xiàng)目，每個(gè)項(xiàng)目都有比較完善的功能說明，根據(jù)這些功能說明可以列出原項(xiàng)目安全需求列表，形成具體功能點(diǎn)；依據(jù)功能點(diǎn)在所生成的用戶故事集中篩選出可能相關(guān)的用戶故事。進(jìn)一步與原項(xiàng)目的安全需求進(jìn)行比對(duì)，如果某個(gè)用戶故事覆蓋了項(xiàng)目中的有效功能點(diǎn)，則說明該用戶故事有效。通過人工統(tǒng)計(jì)的方法，計(jì)算用戶故事覆蓋率p，如式(1)所示；其中n(s)表示覆蓋實(shí)際項(xiàng)目用戶故事的條數(shù)，n(c)表示原項(xiàng)目中實(shí)際的安全需求用戶故事條數(shù)，在這里選用實(shí)際項(xiàng)目的目的是希望通過實(shí)際項(xiàng)目的角度出發(fā)來測(cè)試用戶故事的價(jià)值，這樣也會(huì)更加有說服力

(1)

生成用戶故事的主要目的主要有兩個(gè)，一個(gè)是以規(guī)范的形式幫助利益相關(guān)者完善某些需求，即覆蓋已有功能；另一個(gè)是幫助利益相關(guān)者發(fā)現(xiàn)新的需求并對(duì)其形成輔助作用，即增加新的功能。

上述步驟以表8中的項(xiàng)目paascloud-master為例簡(jiǎn)要說明如下：

(1)根據(jù)項(xiàng)目介紹預(yù)測(cè)用戶故事

根據(jù)主頁(yè)信息中的簡(jiǎn)短介紹從用戶故事列表中推薦相關(guān)的用戶故事，最終人工推薦用戶故事32條，并且按照Donald Firesmith在文獻(xiàn)[16]中所提到的分類辦法進(jìn)行分類，具體序號(hào)見表8；考慮到抽取到的安全需求用戶故事條數(shù)較多，因此在本文里不詳細(xì)列出，作者已將用戶故事進(jìn)行整理并且上傳到GitHub[17]。

(2)收集實(shí)際項(xiàng)目安全需求用戶故事并分類

人工方法進(jìn)行安全需求用戶故事收集，具體需求見表8，在實(shí)際項(xiàng)目中，一共生成13條用戶故事，并對(duì)其進(jìn)行分類，這樣便于更好推薦用戶故事。

表8 項(xiàng)目列表

(3)進(jìn)行用戶故事價(jià)值比對(duì)并計(jì)算覆蓋率

最后得到實(shí)際用戶故事覆蓋條數(shù)為11條，用戶故事覆蓋率84.6%。

類似的對(duì)15個(gè)項(xiàng)目的用戶故事實(shí)用價(jià)值進(jìn)行分析，結(jié)果詳見表8；可以看出，采用該方法所得到的平均用戶故事覆蓋率為85.71%，說明本次生成的用戶故事具有一定的實(shí)用價(jià)值，對(duì)實(shí)際項(xiàng)目開發(fā)能夠起到一定的輔助作用。

7 結(jié)束語(yǔ)

在敏捷開發(fā)環(huán)境下，相對(duì)于被集中撰寫的功能性需求,軟件的非功能需求描述通常較為分散和隱含。我們認(rèn)為開發(fā)類社交媒體上針對(duì)特定軟件項(xiàng)目的討論中往往蘊(yùn)含著許多潛在的系統(tǒng)功能需求和非功能需求。因此本文針對(duì)GitHub中的Issues模塊數(shù)據(jù)嘗試進(jìn)行安全性需求挖掘，從而獲得有價(jià)值的信息為開發(fā)人員提供輔助工作。本文主要貢獻(xiàn)包括：①給出一種以3類連接實(shí)體識(shí)別為基礎(chǔ)從句子中抽取出用戶行為和行為原因的方法；②給出一種CreUS用戶故事生成算法，針對(duì)不同類型的Issues語(yǔ)句和句內(nèi)連接實(shí)體類型設(shè)計(jì)規(guī)則進(jìn)行用戶故事生成。生成的用戶故事集不僅可用于輔助Issues所在項(xiàng)目的開發(fā)迭代，還可以作為領(lǐng)域知識(shí)，在同領(lǐng)域類似項(xiàng)目的需求發(fā)現(xiàn)中起到重要的參考和輔助作用。