一种基于角色和协作的软件需求获取方法

郭辉，董瑞志

（常熟理工学院计算机科学与工程学院，江苏常熟 215500）

一种基于角色和协作的软件需求获取方法

郭辉，董瑞志

（常熟理工学院计算机科学与工程学院，江苏常熟 215500）

精确地获取客户的需求是一个必需的任务.本文提出了在网络协作平台上的一个协作方法和过程.该方法有许多角色，每种角色在网络环境下同时执行一些需求编写、复查、评论等任务.不同的角色负责不同的任务.基于协作方式，提出了一些角色关系.为了达到协作工作的目的，平台提供了几种协作服务，以满足一个软件系统的开发需求.所有的用户通过不同的协作模式完成他们的工作.所有的涉众完成各自的需求编写后，一个综合的软件需求文档就会产生.

软件工程；需求工程；面向对象；角色；协作

自软件工程出现后，在软件开发中引入了软件生命周期的概念.软件需求阶段在软件开发中起重要作用.在软件需求分析阶段确定的系统逻辑模型是以后设计和实现目标系统的基础.软件系统的成功极大地依赖软件需求分析的质量[1].软件开发失败多数在于需求的模糊性，软件需求的不充分性发现越晚，软件开发面临风险越大.

进入90年代后，需求工程成为软件工程领域的研究重点之一.需求工程涉及到需求获取、需求分析与协商、系统建模、需求规约、需求验证、以及需求管理[2].一个称作KAOS的方法提出用于开发需求工程，通过目标提炼和目标操作开发软件需求[3-5].Bolchini等通过面向目标的分析导出Web应用需求[6-7].Yu提出了I*framework作为面向Agent需求工程方法[8].软件需求有两类，一类是功能需求，另一类是非功能需求[9].多数研究集中在功能需求上.然而，一些研究者选择忽略非功能需求，因为它比较难.ChungMylopoulos提出用NFR framework去处理非功能需求[10-11].在NFR framework中，把软件目标分解成更详细的软件需求.目标精化的结果用SIGs（softgoal interdependency graphs）图来表示.最近，面向对象的软件开发越来越流行.RUP方法被证明是一个成功的软件方法[12].现代大多数软件开发方法是使用UML[13].为了深入理解需求，I.Jacobson提出用了用例驱动的方法进行需求分析[14].

鉴于软件需求的变化，涉众和系统开发人员的有效交流是非常重要的.但在这个问题上却研究不多.本文提出了一个多角色协作方法和平台.主要目标是加强参与软件项目的人员间的交流.包括不同的涉众、分析员、经理等等.通过加强交流，分析员更深刻地理解客户的需求.另外，客户借助分析员的帮助，表达更合适的需求.由于项目涉及到的人员分布在不同的地方，基于网络环境是必需的.通过使用网络平台，人员可以在任何时候任何地点完成他们自己的工作.因此可以提高效率，节约时间.

本文定义了几种角色和角色之间的关系.通过定义角色之间的关系，可以设计出协作机制，这种机制使得人们在协作平台上更容易满足他们的工作.导出了几种有用的协作模式，实际上，多数在协作平台上的协作工作和任务遵照导出的协作模式，所有的涉众完成了他们的需求编写后，综合的软件需求文档就会生成.

1 角色和角色关系

软件系统开发是一个需要协作的工作，特别是软件需求开发阶段.在软件需求开发中涉及到一些人.因此，需定义几种角色和角色关系.

1.1 角色

在多角色协作平台上把角色分成三类，一类是客户端，一类是系统开发端，一类是中间协调者.多角色协作平台中，共定义7种角色，客户端有客户秘书、涉众、客户经理，系统开发端有开发秘书、分析员、开发经理，还有协调者.不同的角色有不同的特征和任务.

协调者：负责建立顺畅的通信途径.

客户秘书：与开发秘书洽谈决定谁参加软件需求的开发.

涉众：使用系统的主要用户，使用开发平台，不同的涉众写出各自的需求，其他涉众做出评论，涉众可根据评论修改他们的需求.

客户经理：与开发经理和涉众交流，另外，客户经理负责管理监督来自所有涉众的需求.

开发秘书：与客户秘书洽谈决定参加软件需求开发的人员.

系统分析员：负责系统分析，另外也通过协作机制帮助涉众编写他们的需求.

开发经理：与系统分析员和客户经理洽谈，另外，开发经理负责协作软件需求的产生.

1.2 角色关系

1.2.1 （客户经理/客户秘书/涉众/开发秘书/开发经理/分析员）——协调者

这种关系涉及到所有角色，协调者在其它角色之间建立良好的沟通方式.

1.2.2 秘书-秘书洽谈角色关系

一般地，可以把协作软件开发过程分为五个主要阶段：建立顺畅的通信途径、角色分配、涉众编写、分析评论、协作软件需求产生.在角色分配阶段，至少有一个客户秘书和开发秘书一起讨论洽谈，决定不同的关系和分配不同人员执行合适的角色.

1.2.3 涉众-分析员协作角色关系

不同的涉众使用协作平台在分析员的帮助下书写他们的需求，涉众书写各自的需求后，分析员可以通过对不完整的需求作出评论以帮助他们完成完整的需求.然后，涉众可以按照分析员的评论修改或改进他们的需求.可表示为：涉众----------分析员.

1.2.4 （客户经理/涉众）—开发经理角色关系

这个角色关系可表示为：涉众-------------客户经理----------开发经理.

由三种角色构成.主要的交流是客户经理和开发经理之间，另外，开发经理、客户经理也可与涉众交流，这时，客户经理可被看作是涉众和开发经理间的桥梁.

1.2.5 客户经理—（开发经理/分析员）角色关系

这种角色关系表示为：客户经理----------开发经理--------分析员.与（客户经理/涉众）——开发经理角色关系相似，主要的区别在于开发经理是分析员和客户经理之间的桥梁.

1.2.6 （客户经理／涉众）－（开发经理／分析员）的角色关系

这个角色关系为：涉众----------客户经理----------开发经理---------分析员.

涉及到四种角色.这种关系主要集中在客户经理和开发经理之间，另外，客户经理也需要涉众的支持和帮助.相似地，分析员可以帮助开发经理使得交流更加有效.

1.2.7 客户经理－开发经理角色关系

这种关系为：客户经理----------开发经理.

不同的涉众分别完成各自的需求后，协作的软件需求就会产生.然后，执行协作软件需求的验证.客户经理和开发经理共同完成验证.

2 协作机制

协作平台为软件需求开发提供了一些协作服务，提供的协作服务形成了一些共同的协作模式，这些协作模式是协作平台的基础，用户之间交互遵循协作平台上的协作模式，这些协作模式支持主要的协作机制.

2.1 协作服务

本文提出在协作平台上支持协作软件需求开发的四种协作服务.协作编写服务：提供用户编写、查看、评论需求.

支持工作服务：为用户完成他们的工作提供一些支持.

综合的规格说明产生服务：编写完需求后，这种服务提供产生软件需求规格说明的机制.

协作验证服务：提供需求验证的方法和环境.客户经理和开发经理互动协作验证需求规格说明.

2.2 协作模式

考虑到软件需求的发展，需要提高软件项目人员之间的交流，因此特别强调在基于网络环境下的人员间的合作.下面介绍在协作平台上的几种普遍协作模式.

2.2.1 单一对等协作

一个人与另一个人交互，涉及到的角色有涉众、分析员、客户经理、开发经理，如图1（a）所示，这种模式的特征是交互仅发生在两个人之间.单一对等协作是最基本的协作模式，作为一个基本的交互模式可以独立工作.另外，这种模式可以混合其他模式以形成另外一种协作模式，这个协作模式包含两种角色这种协作模式下有几种类型的角色组合：涉众与涉众，涉众与分析员，客户经理与开发经理，开发经理与分析员.

2.2.2 多对协作

同一种类的角色间交互涉及到的角色有涉众，如图1（b）所示，这种协作模式的特征是所有人都是同一角色.实际上，这种协作模式主要涉及到涉众，涉众编写他们的需求，其他涉众可以审查这些需求.

2.2.3 单一中心协作

有一个经理作为管理员，经理起到桥的作用.涉及到的角色有涉众、客户经理、分析员、开发经理.如图1（c）所示.这种模式的特征是有个人作为管理员.按照经理的角色有两种协作模式，客户经理起到管理员的作用，其他角色是涉众，开发经理起到管理员的角色，其他角色是分析员.

2.2.4 多中心协作

在这种模式中，协作图中包含两类经理.涉及到的角色有涉众、客户经理、分析员、开发经理，如图1（d）所示.这种模式的特征是这种模式发生在后期.这种模式集中在客户经理与开发经理的交流，另外客户经理也许与涉众交互，开发经理与分析员交互.

图1 协作图

3 协作软件需求产生

软件需求开发的最终制品是软件需求规格说明.IEEEstd-830推荐规格说明书的章节组织和在规格说明书里应该包含什么.大多数需求分析采用SRS模板作为软件需求规格说明的章节结构.它包含几个部分：引言、功能需求、非功能需求和词汇表.

所有的涉众分别写他们自己的需求，一旦所有的涉众完成他们的需求书写，协作软件需求将会按照简化的SRS格式被生成.涉众使用需求编辑服务在协作平台上书写他们自己的需求.通常，需求被分成两类，包括功能需求和非功能需求.决定需求的种类有三种情况，首先，因为这种需求非常明显地属于功能需求还是非功能需求，涉众在没有分析员的帮助下可以决定需求的种类.第二，需求不是很明显能判断属于哪类需求，既使这样，涉众仍能决定需求的种类.然后，分析员给出涉众所写的需求种类的建议.最后，涉众很难判断需求的种类，涉众仅写下需求不决定需求的种类.决定需求的种类的任务由分析员完成.

考虑到非功能需求有两类.一类是全局性的，限制适用整个系统.对于局部性的非功能需求，限制只是作用在系统一些部分.功能需求和非功能需求的排列是基于局部和全局的属性上的.对于软件需求开发进展的监控，可以使用一个简单的方法.即在涉众参与的基础上，完成需求编写的涉众的比例.因此，按照这个比例，可以意识到目前在协作平台上的软件需求开发进度.实际上，如有必要，可以调整每个人的责任.

4 协作软件需求开发过程

需求工程和过程涉及到捕获客户的需求.本文提出了在协作环境下的开发软件需求的协作软件需求开发过程.协作过程由六个活动组成，包括建立顺畅的通信途径、角色分配、角色分配验证、涉众编写、分析员评论和SRS产生.另外，活动也许产生一些制品，包括初始需求或精化需求、评论、最终的协作需求规格说明.

完整的协作软件需求开发过程如图2所示.活动的详细说明如下：

（1）建立通信途径活动.需求获得成功，先要建立需求获取所必需的通信途径，即在其它角色之间建立良好的沟通方式.

（2）角色分配活动.这个活动的主要任务是为将要进行的协作软件需求开发做准备.客户和开发秘书互相讨论洽谈.然后决定在需求开发的过程中涉及到的角色.

（3）角色分配验证活动.如果角色分配是足够的，这个活动停止.如果有冲突或不合适，有必要返回到前一步.如果不是，这个活动完成，进入下一活动涉众编写.

（4）涉众编写活动.第一次进入这个活动，涉众写出他们自己的需求，这次不但产生了初始的需求，而且进入下一活动-----分析员评论.如果这个活动第一次没完成，将会需要请求和评论作为输入.

（5）分析员评论活动.这个活动需要涉众书写的需求作为输入.如果需求足够完整，分析员会给涉众有用的评论.如果需求没有完成，会返回到上一活动涉众编写.否则，将进入下一活动，协作软件需求产生.

（6）SRS产生活动.这个活动需要精炼的需求作为输入，将会产生最终的协作需求说明书制品.然后，进入下一阶段作需求验证.

图2 协作软件需求开发过程

5 结论和未来工作

从涉众正确、高效获取需求一直是重要而且困难的任务.除了技术方面，也应考虑领域知识方面，由有许多不同背景的人员参加软件项目，这些人之间的高效交流非常重要.过去，访谈、观察用户操作流程、组成联合小组、用例、原型是获取客户需求的常用方法.但花费时间太多.由于高速网络的出现，可以通过网络与其他人交流.相似的，可以在网络环境下诱导出客户的需求.本文提出基于网络的环境中使用协作方法开发软件需求，在协作平台上定义了七种角色：客户秘书、涉众、客户经理、开发代表、分析员、开发经理、协调者.这些不同的角色在网络环境下同时执行需求编写、审查、评论等任务.不同的角色有不同的任务.基于协作方法，在协作平台上有几种角色关系.为了到达协作工作目的，平台提供了几种协作服务以满足协作工作的需要.所有的涉众完成了他们的需求编写后，综合的软件需求文档将会产生.

交流和合作在软件开发需求阶段是最重要的因素.把协作机制放入软件需求开发.通过协作机制，人们互相协作开发软件需求.除了软件需求开发，把协作机制应用到软件开发的其它工作也是有可能的.例如，把协作机制应用于项目管理和监督及系统分析和设计，最终的目标是为方便软件需求开发，系统分析、系统设计、验证、项目管理等开发基于网络的平台.本文进一步的工作是开发协作项目管理监督机制.

[1]程勇.从面向对象到面向目标的需求分析[J].计算机科学，2001，28（12）：113.

[2]钱乐秋，赵文耘，牛军钰.软件工程[M].北京：清华大学出版社，2007：47-48.

[9]陈晓桦.需求分析与获取的方法学和技术[J].计算机应用，1995，15（2）：20.

[3]Darimont R,va Lamsweerde A.Formal refinement patterns for goal-driven requirements elaboration[C].In Proceedings of Fourth ACM SIGSOFT Symposiumon the Foundations of Software Engineering,1996:179-190.

[4]Van H I,va Lamsweerde A.Goal-oriented requirements animation[C].In Proceedings of 12th IEEE International Requirements Engineering Conference,2004:203-213.

[5]van Lamsweerde A.Goal-oriented requirements engineering:A guided tour[C].In Proceedings of the 5th IEEE International Symposium on Requirements Engineering,2001:249-262.

[6]Bolchini D,Paolini P.Capturing web application requirements through goal-oriented analysis[C].In Proceedings of the 5th Workshop on Requirements Engineering,2002:16-28.

[7]Bolchini D,Paolini P,Randazzo G.Adding hypermedia requirements to goal-driven analysis[C].In Proceedings of the 11th IEEE International Requirements Engineering Conference,2003:127-137.

[8]Towards modelin,E Yu.support for early-phase requirements engineering[C].In Proceedings of the 3rd IEEE International Symposium on Requirements Engineering,1997:226-235.

[10]Chung L,Nixon B.Non-Functional Requirements in Software Engineering[M].Dordrecht:Kluwer Publishing,2000.

[11]Mylopoulos J,Chung L,Nixo B.Representing and using non-functional requirements:A process-oriented approach[J].IEEE Transactions on Software Engineering,1992,18(6):483-497.

[12]Kruchten P.The Rational Unified Process:An Introduction[M].New Jersey:Addison-Wesley,2000.

[13]Fowle.M.UML Distilled[M].New Jersey:Addison-Wesley,2004.

[14]Jacobson I.Object-Oriented Software Engineering:A Use Case Driven Approach[M].New Jersey:ACM Press,Addison-Wesley, 1992.

A Method Based on Role and Collaboration for Capturing Software Requirements

GUO Hui，DONG Rui-zhi
(School of Computer Science and Engineering,Changshu Institute of Technology,Changshu 215500,China)

Capturing customer’s desired requirements precisely is a necessary task.Many efforts are made in requirement engineering.The broadly used approaches are goal-oriented approach,object-oriented approach, team-oriented approach,etc.A collaborative method and process to develop software requirements are presented in this paper.Many roles are defined and each of the roles performs a number of tasks of requirements writing, reviewing and commenting at the same time.Different roles are responsible for different tasks.A number of role relationships are proposed.The platform provides several collaborative services to satisfy the needs of developing requirements of a software system.After all stakeholders finish their authoring of requirements,the integrated software requirements document will be generated.

software engineering;requirement engineering;object-oriented;role;collaboration

TP311.5

A

1008-2794（2012）04-0115-05

2011-12-10

郭辉（1969—），男，江苏徐州人，讲师，研究方向：软件工程.