“用户故事”在姿轨控软件需求分析中的应用

林荣峰，蔡 洪

(1.国防科技大学航天与材料工程学院，长沙410073;2.上海航天控制工程研究所，上海200233)

“用户故事”在姿轨控软件需求分析中的应用

林荣峰1，2，蔡 洪1

(1.国防科技大学航天与材料工程学院，长沙410073;2.上海航天控制工程研究所，上海200233)

需求分析是软件开发过程中的重要环节.在国内卫星姿轨控软件设计过程中，需求分析阶段描述和定义用户需求的工作多数仍采用传统方法，过于关注软件的设计过程，而忽略了软件需要实现的功能，常常引发需求分析结果与任务方期望不一致的情况，影响开发进度.针对姿轨控软件的特点，在软件需求分析工作中引入敏捷开发所采用的“用户故事”(User Story)方法，可以高效清晰地描述和定义用户所需要的软件功能，提高任务方在需求分析阶段的参与程度，显著提高需求分析的准确性.

姿轨控软件;需求分析;用户故事

在软件开发过程中，需求分析是其中最重要的环节之一，用于明确软件需要完成的具体工作.软件需求规格说明常用的描述方式有3种:形式化方法、非形式化方法和半形式化方法[1].在传统模式下，采用形式化方法对软件需求进行精确地描述和定义被认为是最精确和严谨的.

这些描述需求的方法都存在一个共同点，就是注意力过于集中在软件怎样设计和怎样实现的问题上，而忽略了软件开发真正的主题——软件要实现哪些功能.软件开发的本质是“知道要做什么”，相对而言，“怎么做”倒是次要的事情[2].目前这些常用的需求分析方法都忽略了“要做什么”这个关键点.同时，这些关注软件设计和实现的需求描述方法还带来了一个危险的情况:软件的任务方和用户在需求分析过程中的参与程度非常低，需求分析结果与用户期望常常出现偏差.

在近年来兴起的XP和SCRUM等敏捷开发方法中，普遍采用“用户故事”进行需求描述，将需求分析的注意力重新放到软件需要实现的具体功能上.尤其在SCRUM方法中，用户故事被直接使用在产品功能特性列表(Product Back log)中，用于描述软件需要实现的各项功能[3].实践证实，用户故事有效地提升了需求分析的清晰性和准确性.

国内的卫星姿轨控软件开发过程中，多数采用数据流图对软件的顶层功能进行分解和描述，或者采用自然语言，描述什么条件下，输入什么数据，完成什么处理，输出什么数据[4].在国内文献中尚未查阅到使用用户故事进行卫星姿轨控软件需求分析的研究.

本文将介绍用户故事这一新方法，及其在卫星姿轨控软件需求分析领域的应用.

1 用户故事的编写

用户故事(user story)是指一件用户通过系统完成一个有价值的目标的事.它描述了对用户、系统或软件购买者有价值的功能[5].用户故事以软件功能为出发点，站在软件使用者或购买者的角度描述需求，有利于开发方清晰地认识和理解需求.

在描述需求时，每一项具体需求都应使用一个或几个独立的用户故事进行描述.每个用户故事都应体现出完整的用户价值，并用最简明扼要的语言，清楚明确地描述实际用户要求的，对其有价值的软件功能.

用户故事一般要求包含以下三个要素:

角色:谁使用这个功能，

活动:需要完成什么样的功能，

价值:为什么需要这个功能，这个功能带来什么样的价值.

对于一个需求项，“角色”是这个用户故事的主体，表示需求项服务的目标;“活动”是对需求项的具体描述或介绍;“价值”则是需求项完成后的成果或需求项的意义.

基于这三个要素，用户故事通常的表达格式为下面两种:

例如:“作为测控人员，需要在上注指令数据后，通过遥测观察注数反馈信息，以确定注入指令是否被正确执行.”

在通常情况下，用户故事主要由软件任务方、软件使用方和软件开发方共同编写.这样做一方面可以有利于以软件“要做什么”作为需求分析工作的出发点;另一方面可以增加软件任务方和软件使用方对软件需求分析工作的参与程度.假设软件开发方不具备软件应用领域的专业背景，由软件任务方和软件使用方参与编写或直接编写的用户故事可以使软件开发人员快速了解软件的应用背景和功能需求.

对于姿轨控软件，描述需求的用户故事同样需要多方共同编写.其中，姿轨控系统设计人员是编写用户故事的主要成员.姿轨控系统设计人员通过用户故事向软件开发人员描述姿轨控软件需要完成的各项功能.此时编写的用户故事突出“要做什么”，而屏蔽了软件实现的技术细节，使得整个姿轨控软件的需求能够清晰明确地被整理出来.

2 用户角色建模

在编写用户故事时，角色建模是重要的一步.包括卫星姿轨控软件在内，绝大多数软件针对的“用户”都不是单一的.要使用用户故事正确并完整地对软件的需求进行描述和定义，首先要进行用户识别和角色建模.

编写用户故事前，首先要识别出软件中所有可能的用户.此时的“用户”是具体而且单一的用户.在这一阶段，所有与软件有关的使用者、操作者和关联系统等任何可能与软件发生关系的角色都需要被列出.

在完成用户识别后，再根据已识别出的用户进行角色建模工作.角色建模包含角色整合和角色提炼两部分.

进行角色整合时，需要针对已经识别出的用户，定义其与软件的关联关系和用户特征，并对相近的关联关系和用户特征进行整合，获得角色的基本特征.角色的基本特征可以是具有相近关联关系的用户所包含的任何有价值的信息.在此之后，通过已获得的用户基本特征对软件相关的角色进行提炼，建立角色模型.此时的角色模型就不再是具体的用户，可以用于编写用户故事.

由于姿轨控软件一般不包含人机操作，因此在对姿轨控软件进行角色建模时，角色一般都是非人物用户角色(non-human user role).对于姿轨控软件，最简单易用的角色建模方法就是直接利用整星设计时的系统划分进行角色建模，包括姿轨控分系统内的结构划分.此时，可以将姿轨控软件中涉及的用户角色定为:星务分系统、载荷分系统、姿轨控系统敏感器和姿轨控系统执行机构等.这种建模方法的最大优势，就是在编写用户故事时能够非常直观地描述姿轨控系统的活动和行为.

在对姿轨控软件进行角色建模时，虽然用户角色多数是非人物用户角色，但仍然会有普通人物角色存在.尤其是编写与地面应用和操作相关的用户故事时，可以将这些需求视为人机操作，使用普通人物角色模型编写用户故事.在上一节给出的用户故事中，“测控人员”就是一类人物角色模型.

3 用户故事的估算

软件需求分析工作的另一项工作就是估计软件开发的工作量，制定开发计划.在使用用户故事方法进行需求分析工作时，通常采用故事点(story point)作为工作量的估算单位.一个用户故事包含故事点的数量，代表开发人员实现这一用户故事中全部软件功能所需要的工作量.

定义si代表第i个用户故事，其包含的故事点数量为pi，如果在进行需求分析时共产生了n个用户故事，那么整个软件需要开发的故事点数量就是:

如果开发人员实现一个故事点的标准工作量为t，定义T为整个软件开发的预期工作量，那么T就是:

其中，t一般以“人·天”为单位，“1人·天”表示1个开发人员工作一天的工作量.

在实际开发工作中，为了便于管理，标准工作量t可以定为1人·天.就是说在划分故事点时，每个故事点需要的开发任务都应该由一个开发人员在一天的工作内完成.由此可以看出，使用用户故事估算软件开发工作量的关键在于合理的划分每个故事包含的故事点.

在划分每个故事应包含的故事点时，可以采用三角测量[5]，就是在估算一个故事时，根据这个故事与其它一个或多个故事的关系来估算.首先独立估算每个用户故事包含的故事点.在完成独立估算后，再将所有故事放在一起关联估算.此时，需要将所有用户故事按故事点数量分组，先进行组内估算，再进行组间横向估算，最终确定每个用户故事应该包含的故事点数量.在此之前，必须事先明确标准工作量t是多少，并得到所有开发人员的认可，否则无法进行估算.

例如，完成独立估算后的故事分组如图1.

图1

那么在组内估算时，所有人员均应认可故事1、6、7和9的开发工作量是相同的.如果认为实现其中某个用户故事的工作量比其它几个故事多，则需要改变其估计的故事点数量，并将其转移到其它的分组中.在完成第一组的组内估算后，以同样的方法依次完成后续的组内估算.

在组内估算完成后，则进行横向估算.以图1为例，在确定故事1包含1个故事点后，只有确认实现故事2的工作量是故事1的两倍，才能确定故事2的故事点为2.如果认为实现故事2的工作量多于故事1的两倍，但没有达到故事1的四倍，则将故事2的故事点数调整为3.以此类推，完成横向估算工作，就可以获得最终的估算结果.开发初期估算出的预期工作量还需要在开发过程中根据实际情况进行进一步的调整.

故事点估算工作具有一定的经验性，需要根据开发人员之前的开发经验进行估计，估算的准确性与开发人员的经验、技术能力和对软件应用背景的熟悉程度密切相关.对于姿轨控软件而言，开发人员大多熟悉卫星姿轨控系统的应用背景，能够较为准确地估计每个用户故事的故事点数量.但对于标准工作量t，则需要适当进行调整.根据笔者的开发经验，在进行首发星的开发时，t可以取2人·天或1.5人·天，因为此时开发人员对于全新型号需要一个熟悉阶段，实现一个故事点需要花费的时间较多.当进行后续星的软件开发时，则可以把t降低到1人·天，因为此时的开发人员已经对型号有了较全面的了解，实现一个故事点需要花费的时间会比首发星少.

4 隐 喻

在使用用户故事描述需求时，每个用户故事都应该包含一个独立的、有价值的系统目标.但在实际的编写过程中，一个用户故事除了表面描述的需求之外，还很可能隐含着其它的信息.这一类信息就称为隐喻.

在编写用户故事时，不提倡刻意包含隐喻，因为这样会让故事本身不独立，人为制造多个故事之间的关联.更重要的是，刻意加入的隐喻无法让开发人员清晰地读出故事中的软件功能，容易引发需求分析的歧义或软件功能丢失.

对于用户故事中的隐喻，如果属于“显性”隐喻，即一些“不言自明”的信息，是可以接受的.比如下面这个姿轨控软件的用户故事:

“系统在重新建立卫星姿态时，判断地球敏感器输出的地球出现信号，用以确定是否完成捕获地球的过程.”

在这个故事中，字面描述的是姿轨控软件判断捕获地球过程完成的条件，但其中包含着一条隐喻:“在重新建立卫星姿态时，地球敏感器应该处于开机工作状态”.对于这样一条“显性”的隐喻，因为开发人员比较容易了解，因此可以不单独为其编写一个用户故事，继续让其隐含在上一个故事中.

但对于包含信息量过多或者隐含信息难以被发现的“隐性”隐喻，则必须从原有故事中剥离，形成独立的故事.例如之前出现过的一个故事:

“作为测控人员，需要在上注指令数据后，通过遥测观察注数反馈信息，以确定注入指令是否被正确执行.”

在这个故事中，包含着一个很难发现的隐喻:“注数反馈信息应当在当前测控弧段内通过遥测下传”.如果在软件开发过程中没有实现这一隐喻，测控人员就很可能无法及时观察到注数的遥测反馈信息.此时，原有用户故事描述的功能不能被完全实现.对于这一类“隐性”隐喻，开发人员很难了解，必须另外编写一个独立的用户故事对其进行描述.

5 结 论

用户故事以软件需要实现的功能为出发点，是一种清晰简单的需求描述方法.本文通过对用户故事这一方法进行阐述，探讨了用户故事在卫星姿轨控软件需求分析工作中应用的可行性，并详细介绍了实施方法，为改善当前卫星姿轨控软件的需求分析工作提供了新的思路.

[1] 陈策.军用装备软件需求层次分解及其规格描述[J].火力与指挥控制，2010，35(1):117-121

[2] 樊翀.浅谈软件工程中软件设计的表现力和实现力[A].2009通信理论与技术新发展——第十四届全国青年通信学术会议论文集[C].北京:电子工业出版社，2009:71-74

[3] Mike C.Scrum敏捷软件开发[M].廖靖斌译，北京:清华大学出版社，2010，256-270

[4] 杨海成.航天型号软件工程[M].北京:中国宇航出版社，2011，33-46

[5] M ike Cohn用户故事与敏捷方法[M].石永超译，北京:清华大学出版社，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—)，男，山东人，工程师，研究方向为航天器软件设计(e-mail:lkwhisky@163.com).