【IT168 专稿】

    需求采集对于当今的开发团队而言可以说是最重要的一个任务。根据SearchSoftwareQuality.com所做的2008年度敏捷趋势调查报告，多数企业在进行应用生命周期管理的时候都会因为无法确定用户的需求而遇到很多困难。用户需求采集一直是一项复杂的工作，并且即使随着敏捷过程的发展，这项工作也决不会变得简单。

    调查报告指出，有31%的调查对象认为需求采集工作是应用生命周期管理中最难控制的领域，这远远超过了选择过程改善的12%、软件测试的12%和应用程序性能管理的8%。

    一直以来，需求都是软件开发的拦路石，因此也随之产生了应运而生许多解决办法。敏捷开发的崛起给软件开发带来了一场革命，同时也从很大程度上改变了需求采集过程。敏捷开发使开发团队可以在开发过程中使用并随时修改详细而精炼的需求文档——这比传统的软件开发过程的需求采集精炼得多。

    需求采集技术趋势

    随着敏捷开发方法的发展，需求采集过程也越来越多地依赖于需求描述（user story），它通常被认为是一种较灵活的表达用户需求的方式。

    但是，在调查报告中虽然有高达26%的人认为需求描述确实是一种好用的需求采集技术，但它仍然只是诸多需求采集技术之一。敏捷趋势调查报告的调查对象们倾向于采用多种技术进行需求采集。其中用户需求模型（40%）、焦点群体（focus groups，41%）和普通的电子表格（35%）仍然是2008年度被广泛使用的需求采集工具。

    与统一建模语言（UML）和敏捷预处理过程（比如统一软件开发过程RUP）关系紧密的用例（use cases）也决不会被需求描述完全取代，它在调查对象中的使用率达到了50%。凌驾于所有其它技术之上的则是用户调查（user interview）,占到67%的比率。

    有许多公司喜欢使用支持敏捷方式的需求采集工具。这些公司包括AxoSoft、Blueprint、IBM、iRise、MKS、NetObjectives、Rally Software、Ravenflow、Sparx Systems、Telelogic (最近被IBM兼并)、ThoughtWorks和VersionOne。

    微软的Excel也是一种不容忽视的、以电子公告板和需求卡片的形式被广泛使用的需求采集工具。即使是软件供应商也承认“软技术”是必不可少的：成功的关键在于如何使用需求工具，以及团队如何从企业中的人员身上汲取到准确的需求信息。不管你是否采用需求描述或用例，这条规则都是适用的。

    直面需求采集困难

    但是为什么需求采集这么困难呢？

    “因为这是一种科学的技术。”IBM Rational产品经理Daniel Moul如是说，“它要求在所有的需求定义周期中都要发挥软技能的作用，包括与他人协作、明白他人的观点等。它是从一些模糊的需求表达中提取出精准、可实现的描述。”

    Cutters敏捷产品与项目管理实践部门总管Jim Highsmith认为：“产品负责人应该积极地参与到需求定义工作中。”

    需求描述与用例

    需求描述与用例相比有哪些不同呢？我们可以把用例看作是需求描述的比较古老的一种形式。用例是从使用者或系统用户的角度来描述的一系列的事件。

    用例是一种注释，是UML的一部分，也是其不可或缺的一部分。使用用例的目的是为了取得更好的结果。用例也与RUP有密切的联系，虽然有一小部分开发人员认为RUP有点过于复杂。RUP等过程引发了极限编程（XP），以及与极限编程相比较为低调的敏捷开发。

    而需求描述则是以用户的语言来简洁地定义系统需求。需求描述的这种对简洁的追求迎合了各方面对提高需求采集工作的效率的要求。作为传统过程的一部分，需求采集经常会产生大量的文档，却可能无法生产出满意的系统。而且这些需求在整个项目生命周期中也是不透明的。

    很明显，用例技术可能受到需求描述技术的影响；反之亦然。Ivar Jacobson Consulting公司总经理David West说，如果团队能以全部的精力和合适的准确度描述真正可以实现的部分，那么敏捷开发中的用例实践就能取得成功。

    瑞士世冠汽车公司的诸多开发团队中有一部分IBM RUP用户，他们在新过程中采用了用例技术，并实现了敏捷开发所能带来的好处。世冠汽车的高级项目经理Anna Hard说：“我们用的是跟以前在RUP SE中一样的用例技术，但我们把这些用例贴在墙上，这样所有人在经过的时候都能看到，因此大家对系统就会有一个统一的认识。”

    在2008年IBM Rational开发人员研讨会的技术讨论中，Segerstad分享了她的SOA需求采集经验。她描述了一个SOA）项目，该项目为遗产系统创建了一个新式的管理接口。从中我们可以了解到：在交互的环境下应该使用详细的需求表达。

    多管齐下解决难题

    用例与需求描述之间只有细微的区别。但是正如业务分析国际机构（IIBA）副总裁Kevin Brennan所说，一个简单的例子就可以表现出“用例比需求描述更大并且更复杂”。因此，他认为：“通常来讲，可以认为需求描述是用户想做的一件事。”

    他还说，“你可以把需求描述看作是敏捷开发的界定工具。你可以用它来限定在某一个迭代周期中所需要实现的功能。因此实际的工作就是由开发人员和利益相关人交互完成的。从而，我们就能对产品将如何工作进行详细地描述。而用例则通常要求建立文档，因此，开发人员的交互对象就是文档。”

    Brennan说，这样，用例就可以在一些比较复杂的环境下使用，在需要由许多种类的用户与系统进行交互的环境下使用。

    这些技术都有一个很重要的共同点，即“用例与需求描述都是线性的、可读性强、并且容易理解的。”

    需求采集工具种类繁多，因此各团队几乎都会用到其中的许多。正如Brennan所说：“所有的需求采集技术都有利有弊，没有任何一种技术是完美的、适合所有情况的。因此，业务分析员应该至少学会使用其中的几种技术。”