引言

软件需求,即客户对于软件产品的要求,是软件项目开展的基础。软件需求通常分为功能性需求、非功能需求和限制条件。通常,功能性需求比较容易获得(通过与客户的沟通或者对业务流程的分析),而很多非功能需求和限制条件则常常是隐含的。

这是因为,在大多数情况下,对于此种需求,客户本身也并不十分清楚或客户认为需求和限制条件过于明显以至于并不将它们作为需求专门向软件开发团队提出。与此同时,软件产品的规模越来越大,实现的业务越来越复杂,因而促使人们采用一些工程化方法对软件产品需求进行研究,以便能获得准确、清晰和全面的需求,促进软件项目顺利进行。通过对软件需求的工程化方法的实践和研究,逐渐形成了软件工程的一个子领域———需求工程(Re-quirement Engineering)。

并且,人们逐渐认识到对软件需求的分析活动不仅限于软件产品开发初期,而是贯穿在整个软件生命周期中。软件需求工程主要包括以下几个活动:

①需求获取(Elicitation);

②需求分析(A-nalysis);

③需求规约(Specification);

④需求验证(Vali-dation/verification);

⑤需求管理(Management)。

通常在需求工程过程中,需求的获取、分析、规约和验证活动统称为需求开发部分。需求的管理活动,又分为需求确认、需求变更、需求评审和需求跟踪几个子活动。

需求开发的过程是一个渐进循环的过程。需求工程方法论是通过对获取原始客户需求并进行建模分析,最终产生规范化的需求规约,经过验证后的需求规　　约即成为软件产品需求基线。需求随着软件产品的开发,在整个软件生命周期不断地被跟踪和更新。

然而,传统的软件需求工程的方法论大多是研究不开放源代码的商业软件项目而总结出来的。随着开源社区的努力和开放源代码项目取得巨大成功,软件开发和发布的方式正在发生变化,越来越多的商业软件公司也加入到开源软件的行列中,开始开发开放源代码的商业软件版本(即开源商业软件)。

对于这些软件项目,一方面,项目由商业公司主导开发、发布的软件产品;另一方面,软件产品部分或者全部将开放源代码,采用开源社区的开发者资源,并集成大量的开源的软件代码和工具。由于传统商业软件项目和开源软件项目应用截然不同的软件生命周期模型、开发流程和工具,
不可避免地,在开源商业软件项目管理过程中,两种项目管理理念、方法会产生冲突的同时也会逐步融合。同理,对软件需求的管理过程也将发现不断的冲突和融合。

1 问题提出

在软件项目生命周期的前期,进行软件需求开发和管理的过程中显得尤为突出:

一方面,如果在软件需求开发、管理中过分强调考虑商业项目、复杂的管理流程和突出商业公司在需求管理中的主导地位,毫无疑问会对于开源社区的开发人员参与该项目的热情起到抑制作用,从而对于项目在开源社区的开展,如项目开发、测试以及推广等将起到消极作用;另一方面,如果在软件需求管理中采用开源社区的方式,即如其他的开源项目一样,完全由开源社区进行主导,则很可能使软件项目逐渐脱离商业目标从而导致商业利益受到损失。

具体的,根据软件需求工程理论,分别提出了针对商业开源软件项目在需求工程活动中碰到的问题:

①开源商业软件项目如何有效地收集来自商业客户、开源社区以及项目内部的需求? (需求获取);

②开源商业软件项目如何平衡软件需求以适应商业需要和开源社区的需要? (需求分析);

③开源商业软件项目如何形成和发布需求规约?如何验证? (需求规约和验证);

④开源商业软件项目中需求管理的流程是怎样的?如何定义需求基线?如何跟踪和变更需求? (需求管理)

本文接下来将结合实际项目实践来讨论开源商业软件项目是如何进行需求开发和需求管理的各项活动。

2 需求开发

2·1 需求引导

快速需求收集和需求演进在开源商业软件项目中,可以将需求的获取过程明确地分为三个阶段:需求引导,快速需求收集和需求演进。其中需求引导和快速需求收集是在项目刚开始的阶段获取初步的软件需求,通常是由项目内部人员引导和总结客户和公司内部对软件项目的原始需求,并不包括开源社区的任何意见和工作。

这样做的原因有二:

一是在项目之初,收集需求的重点是获得项目相关的商业客户对软件的要求,并将这些要求列入需求列表;

二是项目初始阶段,软件需求的获得是一个从无到有的过程,而开源社区对一个空白的项目并不感兴趣。在开源社区中,开发者通常只会关注已经具备一定原型的项目。

如上所述,需求引导和快速需求搜集过程非常类似于缩减版的需求开发过程:涵盖了需求获取,分析以及生成规约的过程。但相比整个需求开发过程而言,它们的实施过程非常短(通常2~3周),分析不充分(仅通过简单的分析和反馈),仅获得初级需求规约(简单的需求清单)并省略了需求的验证过程。需求引导和快速需求搜集的目的是快速获得一个初步的需求清单,并在这个清单的基础上进行需求演进,从而尽早获得开源社区对该项目需求的反馈。

通常,这些反馈是判断项目是否可以作为项目在开源社区获得认可和支持的重要指标。在实际项目中,需求引导主要由市场部门通过访问客户和市场调查获得的商业要求,同时结合主要的软件开发测试人员、软件架构师与技术管理层,通过头脑风暴法得到初步的需求列表。以初步的需求列表为基础,快速收集来自客户、整个项目团队以及市场部门的反馈,从而形成一份完整的原始需求清单。由于开源社区只对具备一定原型的项目感兴趣,因此在向开源社区收集需求之前,有必要快速实现一些原型,利于获取开源社区对项目的评论和参与,进行需求演进过程,即结合开源社区反馈和需求细化需求清单的过程。原型不需要实现整个需求清单。在实际项目中,通常会选择在商业目标上最重要的需求或者风险最大的需求来首先实现原型,因为越重要的或者风险越大的需求往往需要越充分的讨论和验证。

需求演进的过程需要注意,开源社区的开发者很容易快速进入技术细节和软件实现,对于来自开源社区的需求信息,往往需要具有资深的软件架构和需求管理经验的人员进行分析、组织和筛选。另外,需求演进过程是否结束,也需要综合软件商业目标和获得需求的程度进行分析。

这时可以参考对需求质量的一些评价标准,如正确性、完整性、理解性等。在完成需求引导、快速需求搜集以及需求演进过程后,应当可以获得一份相对较完整的来自客户、项目成员以及开源社区的软件需求清单。该需求清单同时包含了项目的商业目标和开源社区关注的需求。

2·2需求分类

对获得的需求清单,在最终形成需求规约前还需要进一步分类以确定不同的优先级,为之后的项目开发阶段分配开发资源提供参考依据。需求分类可以从两个方面着手:软件需求实现的技术角度和软件需求实现的商业目标。

从软件需求实现的技术角度来说,需求可分为功能性需求和非功能性需求。功能性需求通常就是软件需要具有的功能,而非功能性需求通常表现为一些系统性约束性条件,如整体性能等。从软件需求实现的商业目标来说,要针对内部项目人员)的重点。需求分类的难点在于,优先级的分配需要平衡商业目标和开源社区的要求。很多时候,商业目标和开源社区对技术创新性的要求会产生矛盾,这就需要提供一种机制,允许开源社区与内部项目人员进行充分交流,在满足技术创新性的同时也能满足项目商业目标。这种机制将在需求管理中详细讨论。在实际项目实践中,根据软件产品对应的软件体系架构,将软件需求分解为操作系统内核需求、应用层需求、核心应用需求、图形用户界面需求和功能性需求等。

同时对各一需求条目分配3种优先级:重要(P1),普通(P2),不重要(P3)。通常意义下,重要和普通优先级的软件需求,期望在预定的软件发布版本中完全实现,因而会优先满足实现这些需求的资源;而对于不重要的需求,则不保证在开发过程中能够分配到足够的资源。

2·3需求规约、发布和验证

软件需求列表经过需求分类就形成了需求规约。在开源商业软件项目中,使用开源社区的软件开发方式,无法也无须将需求规约发送到每个开发测试人员手中。因此需求规约需要以一定方式在开源社区中发布,以便于对该项目需求理解和进行后续的需求管理工作。

在开源软件项目中,通常会把较大的项目划分为多个较小的项目便于管理和开发人员的沟通。因此在实际项目里,对于需求规约,也按照需求分类中类型分别发布于相应的开源项目中。各部分需求规约采用固定格式发布,包括需求ID、需求详细描述和优先级。

值得注意的是,在需求规约的实际使用和管理中,人们发现仅在开源项目中发布和维护软件需求规约是不够的。由于是开源商业软件项目,一方面在商业客户在开源社区审查和更新需求会造成不便;另一方面某些内部的软件需求信息也属于商业机密,无法发布在开源社区。

因此,项目实践中实际上在项目组内部维护了一份软件需求规约文档,包括所有的发布在开源社区的需求规约和内部需求规约。文档内容需要包括需求ID,需求详细描述,需求优先级和需求发布策略(内部使用与否)。这种方式无疑增加了需求管理的复杂程度和需求变更等过程的工作量,但通过维护完整的内部需求规约,有效地隔离了商业客户和开源社区对需求规约的访问,保证了在整个项目生命周期需求规约的可追溯性,从而在客户满意度和整个项目需求管理的一致性方面达到了更好的效果。

需求开发的最后阶段,是软件需求规约的验证。通常来讲,对于开源商业软件项目,需求规约的验证过程可以被略过。一方面,由于需求的获取是建立在原　型的需求演进过程之上,对需求规约中实现了快速原型的需求已完成验证过程;另一方面,由于开源软件项目开发采用SCRUM模式进行开发,其核心思想就是在一次“sprint”内(典型为一个月)完成一次轻量级的开发周期,所有与这次开发周期相关的软件需求也会完成一次需求验证,因此也可以略过其他需求验证过程。总的来说,在开源商业软件项目的实践中,需求验证并不作为单独的过程存在,而是随着多个轻量级开发周期不断进行的过程。

3 需求管理

完成需求开发过程而得到的静态需求规约,还不足以应用于整个软件项目周期。因为对软件产品的需求会随软件生命周期而发生变化,而软件需求规约也会因为在项目的不断进行中获得更深刻的认识而发生变化,所以需求管理是必然的。

根据开源商业软件需求规约的特点,软件需求规约是一个集中控制的规约文档,具有可追溯性,可以方便地采用版本管理工具进行需求的版本管理。但是需求规约分散发布在不同的子项目中,需求规约的使用和需求的更新也是分散的。同时,开源社区的开发团体也是松散的分布式的组织架构。

因此,为了便于需求规约的使用,每个子项目为相应的需求(参见需求分类)定义和管理自己的需求基线,这将导致需求的更新发布和不同部分的需求基线制定过程也是分散的。这种情形下,某一需求基线的版本更新将会要求整个需求规约版本的更新,而未更新的需求基线将与需求规约版本在一段时间内产生不一致。

特别是在需求更新比较频繁的时候,这种不一致将被放大。另外,通过需求开发过程的讨论可知,实际项目中,开源商业软件的需求规约中有一部分是不被发布到开源社区的。在这些内部需求的更新也会造成需求规约版本与需求基线版本不一致的扩大。

因此,要做好开源商业软件项目的需求管理,主要是解决众多的分散需求更新的可追溯性以及需求基线与集中管理的需求规约版本之间的一

致性问题。在实际项目的需求管理实践中,为了避免流程复杂,采用了一种简单的方法来解决版本的一致性问题。

首先,采用WiKi系统发布各需求基线(包括内部需求规约版本与需求基线版本不一致使用软件需求的需求基线)。WiKi是一种基于Web的多人协作式写作超文本系统,使用WiKi可以很容易对需求进行管理,包括需求提交、更新、跟踪以及版本控制等。

其次,定义一个两级检查的版本控制和需求跟踪流程。第一级检查发生在WiKi系统中,为某需求基线指定一位基线发布管理员。基线发布管理员负责Wi-Ki上所有需求的更新和发布。当有需求变更的请求发生时,基线发布管理员对请求进行评审,确认接受还是拒绝变更,并将接受的变更请求更新在WiKi上,以确保所有工作在这类需求基线的开发测试人员都可以观察到需求的变化。基线发布管理员还负责对所有变更的纪录进行追踪,以便在需求规约版本升级过程中提供准确的信息。第二级检查发生在需求规约版本控制系统,同样会指定需求规约管理员进行需求规约的管理。

需求规约的管理主要是将各需求基线接受的需求变更集成进需求规约中并完成版本升级。需求规约管理员会定期将需求规约进行升级。需求规约升级期间,要求所有的基线发布管理员在版本升级期间停止需求变更批准和新版本基线的发布。同时需求规约管理员与基线发布管理员对批准的需求变更进行审查,检查需求的更新是否会与其他需求产生冲突。最后将更新的需求在需求规约中更新并升级版本,将产生冲突的需求由基线发布管理员进行回溯,更新和回溯需求发布在WiKi上以通知相关的开发测试人员,所有子项目需求基线版本更新为与需求规约版本相同。
该流程并不能彻底解决需求规约版本与子项目需　求基线版本不一致的问题。但是在实践中如果根据需求更新的频繁程度、项目规模、子项目需求基线的数量等进行优化和调整需求规约版本升级的间隔(在软件生命周期初期,典型的版本更新时间间隔大约在3~5周),可以达到一定的效率和效果的平衡。

4 结语

本文结合开源商业软件的特点,分析了传统的软件需求工程的不足,提出了开源商业软件项目需求工程的问题,并根据项目需求管理实践,讨论了适合开源软件开发模式和商业软件特点的需求开发和需求管理过程。

相信随着越来越多的商业软件项目采用开放源代码策略并在开源社区发布,新的需求管理和需求开发方法会得到更多的应用、实践和完善。基于开源的商业软件项目的需求开发和需求管理的方法需要更深入地理解开源社区开发模式和开源软件的软件生命周期模型,细化软件生命周期各个阶段中对软件需求的管理,并通过更多项目实践进行优化。