三、管理需求中须注意的问题
Rational公司的两位RUP的开发与管理者Per Kroll和Philippe Kruchten在《实践者指南》一书中，曾提示了一些不能正确应用RUP的问题，这在管理需求工作中也有所体现。由于以用例驱动需求管理所获得的明显益处，容易使 团队成员产生盲目乐观情绪，从而减弱了把握正确应用的思维判断能力，产生过犹不及或轻视麻痹的行为及不良效果，这是在管理需求实践中必须加以注意和避免的。其主要问题有：
一是创建过多的用例。一个常见的现象是根据功能把用例划分得太细，没能做到“有所为有所不为”，这样将产生下列的后果：用户对粒度太小的用例很难了解及难以判断是否满足他们的需求；设计人员对于过细的功能无法全部实现，难以通过设计满足实际用户需求；开发人员对关系太紧密的用例很可能开发重复功能并妨碍其他人工作；测试人员要花很多额外精力合成测试用例，才能创建有意义的测试。要避免发生这种情况，应注重以下列的几条标志来准确量度把握：无法衡量能否给用户产生价值的用例，代表的是不完整的交互过程，应当重建；用例A总是与用例B或用例C相关，应当把它们整合为一个用例；两个或多个用例有着几乎相同的描述，就可以把它们合并在一起；对于用例模型中用例之间的关系，不要进行多于一层的抽象。
二是忽视需求定义的准确与共识。系统的用例模型是由多个系统分析员协同完成的，模型本身也是由多个工件所组成。如果忽略了不同工件之间是否存在矛盾或冲突的地方，就会在模型内部产生不一致性，这种不一致性将会直接影响到需求定义的准确性。同时用例模型最大的优点就在于它应该易于被不同涉众所理解且无二义性，因此用例的粒度、个数以及模型元素之间的关系复杂程度都应该依此原则所决定，从而使准确的需求定义成为团队成员和所有涉众达成共识的基础。
三是在初始阶段过于细化需求。根据RUP对生命周期的阶段、目的和里程碑的划分，初始阶段的目的是定义系统的边界并理解最重要的用户需求，这个阶段最重要的任务是尽快建立可执行的架构，以化解重大 风险，因此不必在初始阶段花费太多时间细化需求。这一阶段只要得到一个合理并完整的参与者和用例的清单，广泛而扼要地描述需求，细化基本的或关键的用例，就可结束任务，尔后尽早转入到细化阶段，从而为后续的细化需求工作留出充裕的时间。
四是不善于设置需求的优先级。由于 资源或技术条件的限制，不可能把所有需求都一次性完成，这样就必须进行精心设置，按优先级排序，分批予以实现。为需求设置优先级时应当思考：某个用例是否必须在另一个用例之前实现？是否必须实现整个用例？哪些用例或用例的哪些部分是最重要的？哪一些提供了最多的价值？应把每个需求按对效益的贡献打分，然后将优先级高的先实现，低的到下一个版本，对不断进来的新需求也应照此办理。还要注意的一点是，最合理的需求不一定是要最先考虑的，“经济为本”应始终是指导优先排序的最高原则。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
