Feature的两种用法与推荐用法

Feature（特性）作为[[愿景公式与高层需求三剑客]]之一，在实践中存在两种大相径庭的用法，混淆这两种用法会直接影响需求分析的粒度和效果。第一种用法把Feature看作从业务目标向具体需求过渡的手段——数量比具体用户需求少一个数量级，内容是”高度概括的功能组+少数重要功能项+少数功能实现特色+少数技术特点”，例如办公软件的”公文交换”是列举功能组（粒度大），”支持公文下发、上报和水平发送等多种方式”是列举功能项（粒度中），”在Word中编辑的公文可直接在Word中发起上报”是说明某功能项的具体卖点（粒度小），”和微软Office无缝整合”是强调技术特色。第二种用法把特性当作比”功能”更小的需求单位（如特性驱动开发FDD方法的观点），此时Feature数量会大大多于功能项数量。本书明确推荐第一种用法，因为它作为从业务目标向具体需求过渡的手段，能启发”未来系统应在大方向上具有哪些方面的特性”、后续再把每个特性落实到一个或一组功能中，以一种实实在在的方式加强需求分析师的系统化思维——如果误用第二种用法，Feature会退化成”功能”的另一个别称，失去它作为”业务目标到需求范围之间过渡层”的独特价值。这条区分的实用意义在于：架构师在梳理高层需求时，应该先用Feature这个中间粒度层去连接抽象的业务目标和具体的用例/功能项，而不是跳过这一步直接从业务目标一步扎进具体功能列表。