应对需求变更的"推后细化"与"激发变更"策略

[[用例图与用例规约的抗变性差异]]揭示了需求变更对用例图和用例简述影响小、对用例规约影响大这个规律，这条规律可以反过来指导实践、更聪明地应付需求变更，核心策略是两条相辅相成的做法。推后用例细化：不是对软件架构起关键作用的用例，可以推迟到真正要实现该用例定义的功能之前才进行细化——过早为这些用例制定用例规约，只会增加”需求变更管理”的开销，因为规约越精确就越容易被后续变更打破，提前投入的细化工作反而放大了变更的影响面。激发需求变更：这一条更为关键——要主动通过不断增加功能、发布小版本、提供给用户试用、接受用户反馈这一系列活动，让用户一步步明确自己真正想要的功能；对前期版本的反馈中往往会涉及比较多的需求变更，但此时大量用例还停留在”用例图+简短描述”这个抗变性强的水平，还没有被细化到用例规约，所以能有效避免需求变更造成的巨大冲击。这两条策略合起来的本质是：与其试图在项目早期就把所有需求”锁定”到最精确的程度去防止变更（这在现实中往往做不到、还会招致巨大返工成本），不如主动承认变更会发生、并通过控制”何时精确化”这个时机，把变更成本天然地压低——”开发原型、征求客户意见、识别需求变更、再原型、再识别需求变更”这个循环之所以能顺利运转，恰恰是因为大部分用例此时还没有被过早细化。