看透需求的三个维度

[[架构设计的三个节奏原则]]中的”看透需求”不是”把需求文档读一遍”这么简单，而是要做到”理解了、能说出所以然来”，具体拆成三个维度。需求要全：功能需求、质量需求、约束需求三类都必须定义清楚，只重视功能忽视质量是危险的，只重视某一类质量（如安全性）忽视另一类应有的质量（如互操作性）同样危险，忘了来自甲方乙方第三方的约束也是危险的——一旦发现需求遗漏，就要尽快补齐。矛盾关系：需求项之间天然存在冲突，安全性和互操作性有矛盾，可扩展性和性能有矛盾，功能强大和预算有限有矛盾；识别出矛盾还不够，必须给出明确对策（比如”性能最重要、可扩展性做折衷”或反过来”优先照顾可扩展性”），必要时甚至要重新评审需求本身的合理性。追溯关系：任何一层需求都要能向上追溯到更高层的系统目标，”需求范围”是否合理、”用例图”或”功能项定义”是否覆盖了更高层的需求范围，这是判断需求是否合理的依据——下层需求没有覆盖上层需求，说明必有需求遗漏；下层需求超出了上层需求，则可能是”需求镀金”（做了超出真实需要的过度设计）。这三个维度共同揭示了一个关键认识：需求本身是分层次的——客户高层眼中的需求是业务目标，最终用户眼中的需求是日常工作所需的能力，开发者眼中还有更多用户未必觉察到的需求要实现，看透需求就是要在这些层次之间建立清晰、可追溯的映射关系，而不是把需求当成一份扁平的清单来处理。