让需求可以重用

原文：Making Requirements Reusable
人们为了提高软件的生产力，总是在追求可重用性。代码重用是人们考虑的最多的，但其他软件项目元素也具有可重用性。重用需求可以提高生产率，改进质量，还能在相关的系统中保持更好的一致性。

但是，重用不是免费的。它有它自身的风险，不管是重用已经存在的需求还是为了重用创建新需求。创建高质量的可重用的需求比单纯为当前项目写需求要花更多的时间和努力。在这篇文章中，我们讲述了一些组织为了重用需求所用的方法。

已经存在的需求并不代表它当前的形式就是可重用的。它可能只是针对特定项目的，也可能因为BA当时比较确定研发团队具备某些特定的知识或者面对面沟通过，写的时候（译者：抽象）层次太高（并没有那么具体）。有的需求可能缺少异常情况应该如何处理的信息。因此，为了提升需求将来对其他BA的价值，还必须原始需求做一些调整。

写得好的需求自然是可以重用的。让需求可重用所采取的措施对原始需求所在的项目也有好处。重用的人需要知道需求的依赖因素和被其它需求依赖的因素，这些相互关联的需求合在一起形成一个需求包。

可以重用的需求必须有正确的抽象层次和边界（scope）。特定领域的需求抽象层次会更低（译者：更具体）一些，多半是因为他们只适用于原来的领域。通用需求在不同种类的系统中的应用范围更逛。但是，如果为了达到这个目标，并不会省多少力气。因为BA仍然要敲定其中的细节。让重用既简单又值得是很难平衡的，简单意味着更多的抽象或者更通用，值得意味着更多或者更具体的细节。

图一就是一个例子，某个应用里可能包含了一个支持用户用信用卡支付的需求。这个需求可以扩展成一个功能集合和一堆与信用卡支付相关的非功能需求。其它应用可能也要支持用信用卡支付，这就是个具有可重用性潜力的需求集合。
Figure 1

假如，你想支持更多的支付方式，比如信用卡、借记卡、礼品卡、eCheck、电子转账，因此想把这个需求变得更通用，将来就更有可能在更多项目中重用这个需求。某个项目可能只需要处理信用卡，其它项目需要处理其它支付方式。概括初始的用户需求对当前项目也非常有价值，就像从“支持信用卡支付”概括为“支持支付”。即使客户只要求了信用卡支付，用户可能非常想要其它支付方式，不管是现在还是将来。

选择正确的抽象层次对（项目）构建也很值得。 在有明确的多种支付方式需求的项目里，对每种情况生成清晰的需求和（业务）规则既能暴露出区别也能发现共性。而不考虑将来重用的可能性的话，高层抽象则能产生简单的设计和构建。

以上是好的方面。坏的方面是把原来已经存在的需求变得更通用需要花点功夫。这是你希望收到重用回报投的资（That’s the investment you make in reusability, anticipating that you will recoup the investment—and more—through multiple, future reuse instances. ）。是要把今天的需求共享出来供将来重用，还是现在就为将来的项目提升需求的可重用性，决定权全在你自己。

有同事曾经分享过一个有警示作用的故事，怎样用大量的细节需求减少重用的可能性的。有个团队被分去给一个新项目写需求，但他们太痴迷于重用了。BA们认为如果能分别记录下每个需求的所有细节，就能重用这些需求了。最后他们写了一万四千条需求。整个需求库（repository）里有好多条目都可以只写成一条，但是被组织成了树状结构，一条需求有好多条子需求用来描述上级需求的某个特定细节。需求被细化成这样就只能绑定在一个应用上面了。

如此大量的需求也让循环测试更难了，测试人员每天都在抱怨，因为要过这么多的需求，他们花了比预想的多得多的时间去写测试用例，他们为了追踪需求的覆盖情况还要给测试用例加上需求ID，但仍然很难管理。这还不够，需求还经历了巨大的变化，从来都没有完全稳定下来。所有这些因素导致这个项目完了一年才实施，也没有产生预想的可重用的需求集合。

理想情况是，BA永远都能写出能在多个相关项目中重用的需求，因此能为所在的组织节省大量的时间和金钱。现实却是，你得先去寻找那些有重用潜质的特定需求，再打磨他们，提高他们能让其他BA觉得有用的可能性。

转载于:https://blog.51cto.com/13093181/2358040