“用戶故事”在姿軌控軟件需求分析中的應(yīng)用

林榮峰，蔡 洪

(1.國防科技大學(xué)航天與材料工程學(xué)院，長沙410073;2.上海航天控制工程研究所，上海200233)

“用戶故事”在姿軌控軟件需求分析中的應(yīng)用

林榮峰1，2，蔡 洪1

(1.國防科技大學(xué)航天與材料工程學(xué)院，長沙410073;2.上海航天控制工程研究所，上海200233)

需求分析是軟件開發(fā)過程中的重要環(huán)節(jié).在國內(nèi)衛(wèi)星姿軌控軟件設(shè)計(jì)過程中，需求分析階段描述和定義用戶需求的工作多數(shù)仍采用傳統(tǒng)方法，過于關(guān)注軟件的設(shè)計(jì)過程，而忽略了軟件需要實(shí)現(xiàn)的功能，常常引發(fā)需求分析結(jié)果與任務(wù)方期望不一致的情況，影響開發(fā)進(jìn)度.針對姿軌控軟件的特點(diǎn)，在軟件需求分析工作中引入敏捷開發(fā)所采用的“用戶故事”(User Story)方法，可以高效清晰地描述和定義用戶所需要的軟件功能，提高任務(wù)方在需求分析階段的參與程度，顯著提高需求分析的準(zhǔn)確性.

姿軌控軟件;需求分析;用戶故事

在軟件開發(fā)過程中，需求分析是其中最重要的環(huán)節(jié)之一，用于明確軟件需要完成的具體工作.軟件需求規(guī)格說明常用的描述方式有3種:形式化方法、非形式化方法和半形式化方法[1].在傳統(tǒng)模式下，采用形式化方法對軟件需求進(jìn)行精確地描述和定義被認(rèn)為是最精確和嚴(yán)謹(jǐn)?shù)?

這些描述需求的方法都存在一個共同點(diǎn)，就是注意力過于集中在軟件怎樣設(shè)計(jì)和怎樣實(shí)現(xiàn)的問題上，而忽略了軟件開發(fā)真正的主題——軟件要實(shí)現(xiàn)哪些功能.軟件開發(fā)的本質(zhì)是“知道要做什么”，相對而言，“怎么做”倒是次要的事情[2].目前這些常用的需求分析方法都忽略了“要做什么”這個關(guān)鍵點(diǎn).同時，這些關(guān)注軟件設(shè)計(jì)和實(shí)現(xiàn)的需求描述方法還帶來了一個危險(xiǎn)的情況:軟件的任務(wù)方和用戶在需求分析過程中的參與程度非常低，需求分析結(jié)果與用戶期望常常出現(xiàn)偏差.

在近年來興起的XP和SCRUM等敏捷開發(fā)方法中，普遍采用“用戶故事”進(jìn)行需求描述，將需求分析的注意力重新放到軟件需要實(shí)現(xiàn)的具體功能上.尤其在SCRUM方法中，用戶故事被直接使用在產(chǎn)品功能特性列表(Product Back log)中，用于描述軟件需要實(shí)現(xiàn)的各項(xiàng)功能[3].實(shí)踐證實(shí)，用戶故事有效地提升了需求分析的清晰性和準(zhǔn)確性.

國內(nèi)的衛(wèi)星姿軌控軟件開發(fā)過程中，多數(shù)采用數(shù)據(jù)流圖對軟件的頂層功能進(jìn)行分解和描述，或者采用自然語言，描述什么條件下，輸入什么數(shù)據(jù)，完成什么處理，輸出什么數(shù)據(jù)[4].在國內(nèi)文獻(xiàn)中尚未查閱到使用用戶故事進(jìn)行衛(wèi)星姿軌控軟件需求分析的研究.

本文將介紹用戶故事這一新方法，及其在衛(wèi)星姿軌控軟件需求分析領(lǐng)域的應(yīng)用.

1 用戶故事的編寫

用戶故事(user story)是指一件用戶通過系統(tǒng)完成一個有價(jià)值的目標(biāo)的事.它描述了對用戶、系統(tǒng)或軟件購買者有價(jià)值的功能[5].用戶故事以軟件功能為出發(fā)點(diǎn)，站在軟件使用者或購買者的角度描述需求，有利于開發(fā)方清晰地認(rèn)識和理解需求.

在描述需求時，每一項(xiàng)具體需求都應(yīng)使用一個或幾個獨(dú)立的用戶故事進(jìn)行描述.每個用戶故事都應(yīng)體現(xiàn)出完整的用戶價(jià)值，并用最簡明扼要的語言，清楚明確地描述實(shí)際用戶要求的，對其有價(jià)值的軟件功能.

用戶故事一般要求包含以下三個要素:

角色:誰使用這個功能，

活動:需要完成什么樣的功能，

價(jià)值:為什么需要這個功能，這個功能帶來什么樣的價(jià)值.

對于一個需求項(xiàng)，“角色”是這個用戶故事的主體，表示需求項(xiàng)服務(wù)的目標(biāo);“活動”是對需求項(xiàng)的具體描述或介紹;“價(jià)值”則是需求項(xiàng)完成后的成果或需求項(xiàng)的意義.

基于這三個要素，用戶故事通常的表達(dá)格式為下面兩種:

例如:“作為測控人員，需要在上注指令數(shù)據(jù)后，通過遙測觀察注數(shù)反饋信息，以確定注入指令是否被正確執(zhí)行.”

在通常情況下，用戶故事主要由軟件任務(wù)方、軟件使用方和軟件開發(fā)方共同編寫.這樣做一方面可以有利于以軟件“要做什么”作為需求分析工作的出發(fā)點(diǎn);另一方面可以增加軟件任務(wù)方和軟件使用方對軟件需求分析工作的參與程度.假設(shè)軟件開發(fā)方不具備軟件應(yīng)用領(lǐng)域的專業(yè)背景，由軟件任務(wù)方和軟件使用方參與編寫或直接編寫的用戶故事可以使軟件開發(fā)人員快速了解軟件的應(yīng)用背景和功能需求.

對于姿軌控軟件，描述需求的用戶故事同樣需要多方共同編寫.其中，姿軌控系統(tǒng)設(shè)計(jì)人員是編寫用戶故事的主要成員.姿軌控系統(tǒng)設(shè)計(jì)人員通過用戶故事向軟件開發(fā)人員描述姿軌控軟件需要完成的各項(xiàng)功能.此時編寫的用戶故事突出“要做什么”，而屏蔽了軟件實(shí)現(xiàn)的技術(shù)細(xì)節(jié)，使得整個姿軌控軟件的需求能夠清晰明確地被整理出來.

2 用戶角色建模

在編寫用戶故事時，角色建模是重要的一步.包括衛(wèi)星姿軌控軟件在內(nèi)，絕大多數(shù)軟件針對的“用戶”都不是單一的.要使用用戶故事正確并完整地對軟件的需求進(jìn)行描述和定義，首先要進(jìn)行用戶識別和角色建模.

編寫用戶故事前，首先要識別出軟件中所有可能的用戶.此時的“用戶”是具體而且單一的用戶.在這一階段，所有與軟件有關(guān)的使用者、操作者和關(guān)聯(lián)系統(tǒng)等任何可能與軟件發(fā)生關(guān)系的角色都需要被列出.

在完成用戶識別后，再根據(jù)已識別出的用戶進(jìn)行角色建模工作.角色建模包含角色整合和角色提煉兩部分.

進(jìn)行角色整合時，需要針對已經(jīng)識別出的用戶，定義其與軟件的關(guān)聯(lián)關(guān)系和用戶特征，并對相近的關(guān)聯(lián)關(guān)系和用戶特征進(jìn)行整合，獲得角色的基本特征.角色的基本特征可以是具有相近關(guān)聯(lián)關(guān)系的用戶所包含的任何有價(jià)值的信息.在此之后，通過已獲得的用戶基本特征對軟件相關(guān)的角色進(jìn)行提煉，建立角色模型.此時的角色模型就不再是具體的用戶，可以用于編寫用戶故事.

由于姿軌控軟件一般不包含人機(jī)操作，因此在對姿軌控軟件進(jìn)行角色建模時，角色一般都是非人物用戶角色(non-human user role).對于姿軌控軟件，最簡單易用的角色建模方法就是直接利用整星設(shè)計(jì)時的系統(tǒng)劃分進(jìn)行角色建模，包括姿軌控分系統(tǒng)內(nèi)的結(jié)構(gòu)劃分.此時，可以將姿軌控軟件中涉及的用戶角色定為:星務(wù)分系統(tǒng)、載荷分系統(tǒng)、姿軌控系統(tǒng)敏感器和姿軌控系統(tǒng)執(zhí)行機(jī)構(gòu)等.這種建模方法的最大優(yōu)勢，就是在編寫用戶故事時能夠非常直觀地描述姿軌控系統(tǒng)的活動和行為.

在對姿軌控軟件進(jìn)行角色建模時，雖然用戶角色多數(shù)是非人物用戶角色，但仍然會有普通人物角色存在.尤其是編寫與地面應(yīng)用和操作相關(guān)的用戶故事時，可以將這些需求視為人機(jī)操作，使用普通人物角色模型編寫用戶故事.在上一節(jié)給出的用戶故事中，“測控人員”就是一類人物角色模型.

3 用戶故事的估算

軟件需求分析工作的另一項(xiàng)工作就是估計(jì)軟件開發(fā)的工作量，制定開發(fā)計(jì)劃.在使用用戶故事方法進(jìn)行需求分析工作時，通常采用故事點(diǎn)(story point)作為工作量的估算單位.一個用戶故事包含故事點(diǎn)的數(shù)量，代表開發(fā)人員實(shí)現(xiàn)這一用戶故事中全部軟件功能所需要的工作量.

定義si代表第i個用戶故事，其包含的故事點(diǎn)數(shù)量為pi，如果在進(jìn)行需求分析時共產(chǎn)生了n個用戶故事，那么整個軟件需要開發(fā)的故事點(diǎn)數(shù)量就是:

如果開發(fā)人員實(shí)現(xiàn)一個故事點(diǎn)的標(biāo)準(zhǔn)工作量為t，定義T為整個軟件開發(fā)的預(yù)期工作量，那么T就是:

其中，t一般以“人·天”為單位，“1人·天”表示1個開發(fā)人員工作一天的工作量.

在實(shí)際開發(fā)工作中，為了便于管理，標(biāo)準(zhǔn)工作量t可以定為1人·天.就是說在劃分故事點(diǎn)時，每個故事點(diǎn)需要的開發(fā)任務(wù)都應(yīng)該由一個開發(fā)人員在一天的工作內(nèi)完成.由此可以看出，使用用戶故事估算軟件開發(fā)工作量的關(guān)鍵在于合理的劃分每個故事包含的故事點(diǎn).

在劃分每個故事應(yīng)包含的故事點(diǎn)時，可以采用三角測量[5]，就是在估算一個故事時，根據(jù)這個故事與其它一個或多個故事的關(guān)系來估算.首先獨(dú)立估算每個用戶故事包含的故事點(diǎn).在完成獨(dú)立估算后，再將所有故事放在一起關(guān)聯(lián)估算.此時，需要將所有用戶故事按故事點(diǎn)數(shù)量分組，先進(jìn)行組內(nèi)估算，再進(jìn)行組間橫向估算，最終確定每個用戶故事應(yīng)該包含的故事點(diǎn)數(shù)量.在此之前，必須事先明確標(biāo)準(zhǔn)工作量t是多少，并得到所有開發(fā)人員的認(rèn)可，否則無法進(jìn)行估算.

例如，完成獨(dú)立估算后的故事分組如圖1.

圖1

那么在組內(nèi)估算時，所有人員均應(yīng)認(rèn)可故事1、6、7和9的開發(fā)工作量是相同的.如果認(rèn)為實(shí)現(xiàn)其中某個用戶故事的工作量比其它幾個故事多，則需要改變其估計(jì)的故事點(diǎn)數(shù)量，并將其轉(zhuǎn)移到其它的分組中.在完成第一組的組內(nèi)估算后，以同樣的方法依次完成后續(xù)的組內(nèi)估算.

在組內(nèi)估算完成后，則進(jìn)行橫向估算.以圖1為例，在確定故事1包含1個故事點(diǎn)后，只有確認(rèn)實(shí)現(xiàn)故事2的工作量是故事1的兩倍，才能確定故事2的故事點(diǎn)為2.如果認(rèn)為實(shí)現(xiàn)故事2的工作量多于故事1的兩倍，但沒有達(dá)到故事1的四倍，則將故事2的故事點(diǎn)數(shù)調(diào)整為3.以此類推，完成橫向估算工作，就可以獲得最終的估算結(jié)果.開發(fā)初期估算出的預(yù)期工作量還需要在開發(fā)過程中根據(jù)實(shí)際情況進(jìn)行進(jìn)一步的調(diào)整.

故事點(diǎn)估算工作具有一定的經(jīng)驗(yàn)性，需要根據(jù)開發(fā)人員之前的開發(fā)經(jīng)驗(yàn)進(jìn)行估計(jì)，估算的準(zhǔn)確性與開發(fā)人員的經(jīng)驗(yàn)、技術(shù)能力和對軟件應(yīng)用背景的熟悉程度密切相關(guān).對于姿軌控軟件而言，開發(fā)人員大多熟悉衛(wèi)星姿軌控系統(tǒng)的應(yīng)用背景，能夠較為準(zhǔn)確地估計(jì)每個用戶故事的故事點(diǎn)數(shù)量.但對于標(biāo)準(zhǔn)工作量t，則需要適當(dāng)進(jìn)行調(diào)整.根據(jù)筆者的開發(fā)經(jīng)驗(yàn)，在進(jìn)行首發(fā)星的開發(fā)時，t可以取2人·天或1.5人·天，因?yàn)榇藭r開發(fā)人員對于全新型號需要一個熟悉階段，實(shí)現(xiàn)一個故事點(diǎn)需要花費(fèi)的時間較多.當(dāng)進(jìn)行后續(xù)星的軟件開發(fā)時，則可以把t降低到1人·天，因?yàn)榇藭r的開發(fā)人員已經(jīng)對型號有了較全面的了解，實(shí)現(xiàn)一個故事點(diǎn)需要花費(fèi)的時間會比首發(fā)星少.

4 隱 喻

在使用用戶故事描述需求時，每個用戶故事都應(yīng)該包含一個獨(dú)立的、有價(jià)值的系統(tǒng)目標(biāo).但在實(shí)際的編寫過程中，一個用戶故事除了表面描述的需求之外，還很可能隱含著其它的信息.這一類信息就稱為隱喻.

在編寫用戶故事時，不提倡刻意包含隱喻，因?yàn)檫@樣會讓故事本身不獨(dú)立，人為制造多個故事之間的關(guān)聯(lián).更重要的是，刻意加入的隱喻無法讓開發(fā)人員清晰地讀出故事中的軟件功能，容易引發(fā)需求分析的歧義或軟件功能丟失.

對于用戶故事中的隱喻，如果屬于“顯性”隱喻，即一些“不言自明”的信息，是可以接受的.比如下面這個姿軌控軟件的用戶故事:

“系統(tǒng)在重新建立衛(wèi)星姿態(tài)時，判斷地球敏感器輸出的地球出現(xiàn)信號，用以確定是否完成捕獲地球的過程.”

在這個故事中，字面描述的是姿軌控軟件判斷捕獲地球過程完成的條件，但其中包含著一條隱喻:“在重新建立衛(wèi)星姿態(tài)時，地球敏感器應(yīng)該處于開機(jī)工作狀態(tài)”.對于這樣一條“顯性”的隱喻，因?yàn)殚_發(fā)人員比較容易了解，因此可以不單獨(dú)為其編寫一個用戶故事，繼續(xù)讓其隱含在上一個故事中.

但對于包含信息量過多或者隱含信息難以被發(fā)現(xiàn)的“隱性”隱喻，則必須從原有故事中剝離，形成獨(dú)立的故事.例如之前出現(xiàn)過的一個故事:

“作為測控人員，需要在上注指令數(shù)據(jù)后，通過遙測觀察注數(shù)反饋信息，以確定注入指令是否被正確執(zhí)行.”

在這個故事中，包含著一個很難發(fā)現(xiàn)的隱喻:“注數(shù)反饋信息應(yīng)當(dāng)在當(dāng)前測控弧段內(nèi)通過遙測下傳”.如果在軟件開發(fā)過程中沒有實(shí)現(xiàn)這一隱喻，測控人員就很可能無法及時觀察到注數(shù)的遙測反饋信息.此時，原有用戶故事描述的功能不能被完全實(shí)現(xiàn).對于這一類“隱性”隱喻，開發(fā)人員很難了解，必須另外編寫一個獨(dú)立的用戶故事對其進(jìn)行描述.

5 結(jié) 論

用戶故事以軟件需要實(shí)現(xiàn)的功能為出發(fā)點(diǎn)，是一種清晰簡單的需求描述方法.本文通過對用戶故事這一方法進(jìn)行闡述，探討了用戶故事在衛(wèi)星姿軌控軟件需求分析工作中應(yīng)用的可行性，并詳細(xì)介紹了實(shí)施方法，為改善當(dāng)前衛(wèi)星姿軌控軟件的需求分析工作提供了新的思路.

[1] 陳策.軍用裝備軟件需求層次分解及其規(guī)格描述[J].火力與指揮控制，2010，35(1):117-121

[2] 樊翀.淺談軟件工程中軟件設(shè)計(jì)的表現(xiàn)力和實(shí)現(xiàn)力[A].2009通信理論與技術(shù)新發(fā)展——第十四屆全國青年通信學(xué)術(shù)會議論文集[C].北京:電子工業(yè)出版社，2009:71-74

[3] Mike C.Scrum敏捷軟件開發(fā)[M].廖靖斌譯，北京:清華大學(xué)出版社，2010，256-270

[4] 楊海成.航天型號軟件工程[M].北京:中國宇航出版社，2011，33-46

[5] M ike Cohn用戶故事與敏捷方法[M].石永超譯，北京:清華大學(xué)出版社，2010，15-69

Software Requirem ents Analysis for A ttitude and O rbit Control System w ith User Story

LIN Rongfeng1，2，CAIHong1
(1.College of Aerospace and Material Engineering，National University of Defense Technology，Changsha 410073，China;2.Shanghai Aerospace Control Engineering Institute，Shanghai 200233，China)

Requirements analysis is an important part of software development.In the field of Chinese aerospace，the requirement analysis for attitude and orbit control software is always based on traditional methods.In these methods，we pay too muchattation to software design.The result of requirement analysis is inconsistent with user expectations.In requirement analysis for attitude and orbit control software，user story will be helpful to describe the needs clearly and effectively.Using user story will effectively improve the accuracy of requirement analysis for attitude and orbit control software，and help users more involve in requirement analysis.

attitude and orbit control software;requirements analysis;user story

V448

A

1674-1579(2011)05-0052-03

10.3969/j.issn.1674-1579.2011.05.011

2011-05-28

林榮峰(1979—)，男，山東人，工程師，研究方向?yàn)楹教炱鬈浖O(shè)計(jì)(e-mail:lkwhisky@163.com).