需求描述与用例

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

    用例是一种注释，是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所说：“所有的需求采集技术都有利有弊，没有任何一种技术是完美的、适合所有情况的。因此，业务分析员应该至少学会使用其中的几种技术。”