需求分析三套实践论：小、中、大方法

“用例足矣”和”流程建模和用例建模缺一不可”这两种针锋相对的观点，其实都只对了一半——是实践决定方法，不是方法一刀切实践，不同系统的规模、业务复杂度、技术复杂度差异巨大，需要”大、中、小”三套可根据系统特点选择的需求分析实践方式，而不是强行用同一套流程套用所有项目。小型方法适用于业务不算复杂的系统，例如主要风险在于”技术高难”或”控制规则复杂”的嵌入式控制系统——这类系统业务流程本身不复杂，用例建模（甚至只是用例图+用例简述）就已经足够，不必强行套用面向业务系统设计的重型需求流程。中型方法的关键在于明确增加”高层需求=范围+Feature+上下文图”、必须提交比较正规的《愿景文档》，来促使需求分析工作真正紧扣业务目标进行——上一章PM Suite贯穿案例采用的正是这套中型方法。大型方法的核心思想是：用例建模虽好，但对大型方案本身是不够的，需要业务流程建模来补充——这套方法和企业架构（EA）的一些建议相吻合，同时又比EA本身更落地，避免了”EA太飘”这个常见问题；对于大型方案，绝不推荐”一上来就画用例图、画完了事”，因为这么做经常会遗漏需求，而需求遗漏虽然不等于需求变更，但几乎必然会引起需求变更。三套方法的核心区别不在于”哪套更先进”，而在于它们各自针对的失败风险不同——小型方法针对的是”过度设计需求流程、拖慢技术复杂系统”的风险，中型方法针对的是”需求分析脱离业务目标”的风险，大型方法针对的是”用例建模覆盖不全、遗漏隐藏需求”的风险，选用哪套方法应该由系统实际面临的风险类型决定。