在一个由1000人开发的系统中，要保持系统概念上的完整性，不仅仅需要在管理层和系统设计师之间充分传达和理解概念，还需要将这些概念清晰地传递给所有的实现人员。因为如果不理解业务背景，开发者也很难写出优秀的代码。假设一个项目经理已经拥有一支行事规范的结构师团队和众多编程实现人员，那么他需要确保每个人都能够听从、理解并实现结构师的决策。
当然这些方法在如今可能某些已经过时了，但是通过种种方式保证软件开发的进度不偏离最初的概念和目标，是实现项目成功的重要保障。
文档化的规格说明——手册
尽管思路可能源自十位成员的集体智慧，但为了确保文字与产品之间的一致性，将这些想法整合成一份明确的书面规格说明的工作则最好由一到两个人来完成。这份规格说明，即手册，作为产品的外部规格说明，不仅要详尽描述用户所能见到的每一个细节，同时也是结构师工作的核心产出。手册不仅涵盖了所有用户界面的相关描述，还明确了哪些是用户不可见的内容，但其作用不应延伸至支配具体实现过程，因为这样会限制实现人员的设计自由与创造力。正如《System360 Principles of Operation》中的附录所示，它精确地规定了System/360的兼容性边界，定义了兼容性的标准，描述了预期目标，并列举了由于不同模型间的差异而导致的变化点以及不变项，甚至包括了因工程变更而引起的细微差别。这正是规格说明作者应当追求的精确度——既要明确定义规定的内容，也要清晰界定那些未被规定之处。
形式化定义
一句古老的格言警告说：“决不要携带两个时钟出海，带一个或三个。”应当明确区分形式化定义与叙述性描述，并选择其中一个作为标准，另一个作为辅助。
在定义系统功能时，形式化定义与叙述性描述扮演着至关重要的角色。形式化定义通常采用严格的技术语言和符号系统来表述，如巴科斯范式等，旨在提供精确无误的技术规范，适用于需要高度准确性和可验证性的场合，如编程语言的语法定义。与此相对，叙述性描述则更多地依赖于自然语言，以易于理解的文字形式来传达信息，适合于向非专家介绍复杂的概念和技术细节，例如在用户手册或教程中常见。两者之间的选择取决于目标受众及其所需的信息层次。
然而，尽管二者都能有效地传达系统功能，但在实践中，它们各自也有局限性。形式化定义虽然能够确保一致性与精确性，但可能过于复杂而不利于普通用户的理解；叙述性描述虽易于理解，却可能因解释的不同而引入歧义。因此，在实际应用中，通常建议结合使用这两种方式，确立一种为主导标准，另一种作为辅助手段，以此来平衡准确性和可读性，确保文档既能满足技术严谨性的要求，也能服务于更广泛的读者群体。同时，重要的是要认识到，无论选择哪种方式作为主导标准，都需要保持其稳定性和权威性，避免因频繁改动实现而导致定义的混乱。
直接整合
直接定义实现方式，类比接口规范：通过设计传递参数和共享内存的声明，并利用编程实现中的编译时操作（如 PL/I 中的宏或 %INCLUDE）来包含这些声明；这样一来，当需要修改接口时，只需增删符号名称或重新编译相关程序，而无需更改程序的实际内容，从而简化了接口更新的过程。
会议和大会
敏捷开发中每天的站会，恰是此种场景的最新发展与应用。
会议对于项目的推进至关重要，特别是对于大型项目来说，高效的会议能够促进团队间的沟通与协作。为此，我们设置了两种类型的会议：周例会与年度大会。周例会是由首席系统架构师主持的半天会议，参与者包括所有架构师以及硬件、软件代表和市场规划人员，旨在通过提前分发书面建议来促进创新讨论，并对变更建议进行深入研究，最终由首席架构师作出决策。年度大会则是在手册定稿前举行的为期两周的会议，涵盖了所有关键人员，旨在审查并解决长期积累的问题，通过每日更新的手册来反映会议成果，确保每个人都参与到决策过程中，从而加深对决策背后复杂考量的理解。
这种双层会议机制的有效性在于：固定小组定期交流，保持对项目的深入了解；关键决策者直接参与，确保问题得到及时解决；书面建议提高了决策质量；明确授权加速了决策流程；年度大会则清除了长期积累的小问题，增强了决策的接受度与执行力。
多重实现
System/360 的架构师享有两大优势：充裕的工作时间和与实现人员相当的策略影响力，这两点源于新技术开发的时间表和多重实现的同时进行。为了保证不同实现之间的严格兼容性，规格说明变得尤为重要，成为不可或缺的一部分。在多数计算机项目中，机器与文档可能会逐渐出现不一致的情况，此时通常会选择调整文档以匹配机器状态，因为这样做相对容易且成本较低。但在多重实现的情境下，情况相反，调整机器以符合文档描述反而更为经济高效。
这一理念同样适用于编程语言的定义过程中。若从一开始就有至少两种不同的实现方案，则语言的定义将会更加清晰和标准化，从而在未来多种编译器或解释器涌现时，能够更好地满足多样化的应用需求。多重实现不仅促进了规格的一致性，还提高了语言定义的质量及其后续实现的可靠性。
电话日志
邮件和视频会议是作者描述方法的更现代的实现手段。
在实现过程中，即便规格说明已经尽可能详尽，仍会不断出现结构理解和解释方面的问题。为了解决这些疑惑，应当鼓励实现人员直接通过电话向结构师咨询，而非凭个人猜测继续工作。作为辅助措施，结构师应保持电话日志，记录每次咨询的问题及答案，并每周汇总、整理后发布给相关人员。这种方法虽非正式，但却能迅速有效地传达权威信息。
产品测试
项目经理的“最佳拍档”其实是独立的产品测试小组，他们依据规格说明，对产品进行全面检查，扮演着挑刺者的角色，旨在找出所有潜在的缺陷和矛盾之处。这个独立于开发团队的监督部门，是确保产品质量公正评价的关键。最终，用户将成为最严格的检验者，在实际使用环境中，任何细小的瑕疵都将无所遁形。因此，产品测试小组作为顾客利益的代表，致力于在早期阶段发现未被执行的设计决策或不准确的实现。正因为如此，建立测试小组不仅是确保设计决策落实的必要步骤，也是与设计同步进行的重要一环。
)
