- 系统目标和需求之间的主要区别是什么？
- 如何在实践中明确区分它们？
- 在设计系统时，理解这种区别会带来什么好处？
- 最后：正式地向有抱负的架构师教授这些概念是否重要，或者随着时间的推移直观地掌握它们是否足够？
回答：
- 系统目标是高层次的、抽象的意图。它们表达了系统存在的原因;沿着可靠性、可伸缩性或用户授权的路线思考。它们往往是定性的。
- 系统需求是具体的、可操作的和可测试的。它们定义了系统必须做什么，例如，“系统必须处理10，000个并发用户，延迟为500毫秒。”
例子：
- 目标：我有一个梦想，把一个人送上月球。
- 要求：我想要一艘100米高的火箭飞船，侧面有一条红色的条纹，有一个火箭发动机，能产生1,000牛顿的推力。
把它们分开：
- 如果它可以通过测试或验收标准进行验证，那么它可能是一个需求。
- 如果它更具抱负或方向性，它可能是一个目标。
- 目标塑造了架构原则和权衡。
- 需求定义了成功的约束和测试。
这种区别在工业界是否普遍存在？
理论上？是的
在实践中？前后不一致。
高绩效团队（特别是在航空航天、金融科技、医疗保健等受监管或高风险的环境中）确实围绕这一区别进行培训。它通常以需求工程、目标建模（例如KAOS）或体系结构决策记录（ADR）的形式出现，这些记录跟踪目标到系统选择。
然而，在许多快速发展的产品团队中，这种区别通常是直觉或部落知识。通常情况下，它是通过回顾、中断或技术债务恐怖故事来学习的。除非您所在的组织优先考虑架构成熟度，否则这些概念可能不会像SOLID或DI那样明确地教授。
如何刻意训练自己？
- 从Rozanski Woods的《软件系统架构》开始，这是少数几本将质量属性（通常反映目标）与功能需求分开的书之一。
- 看看“面向目标的需求工程（戈尔）”（特别是KAOS），他们深入研究了目标/需求建模和映射。
- 查看IEEE 830或ISO/IEC/IEEE 29148，了解需求与目标的正式处理。
- 使用体系结构决策记录（ADR）来练习阐明目标如何证明系统约束的合理性。
最后，建立这种技能的一种有效方法是对现有系统进行逆向工程：
选择一个技术堆栈或产品，列出它可能的目标（“低延迟”，“易于上手”，“成本效益”），然后将这些目标与其可观察到的需求或设计选择进行比较。这是一个有趣的（和谦卑的）练习。