过去是怎么做的：
我从来没有在开发项目之前写过产品规格手册；开会、电话日志和产品测试等等，都令我眼前一新，我从未接触过这种形式。
为什么这样不好：
产品测试和一些其他的东西，是必要做的，并且需要同步开发项目过程完成。
解决办法：
可以尝试本书中提到的一些项目开发流程和方式，但是这些方式大多是给项目经理和架构师的，所以也可为今后工作前途作考量。
具体读后感：
贯彻执行：
假设一个项目经理已经拥有行事规范的结构师和许多编程实现人员，那么他如何确保每个人听从、理解并实现结构师的决策？
对于一个由 1000 人开发的系统，一个 10 个结构师的小组如何保持系统概念上的完整性？
文档化的规格说明——手册：
手册是产品的外部规格说明，它描述和规定了用户所见的每一个细节。
随着用户和实现人员反馈的增加，规格说明中难以使用和难以构建实现的地方不断被指出，规格说明也不断地被重复准备和修改。
然而对实现人员而言，修改的阶段化是很重要的——在进度表上应该有带日期的版本信息。
手册不但要描述包括所有界面在内的用户可见的一切，它同时还要避免描述用户看不见的事物。
规格说明的风格必须清晰、完整和准确。
必须在仔细定义规定什么的同时，定义未规定什么。
形式化定义：
精确度是我们需要的东西，这也正是形式化标记方法存在的理由和原因。
形式化定义的优点和缺点：
如文中所示，形式化定义是精确的，它们倾向于更加完整；差异得更加明显，可以更快地完成。但是形式化定义的缺点是不易理解。记叙性文字则可以显示结构性的原则，描述阶段上或层次上的结构，以及提供例子。
它可以很容易地表达异常和强调对比的关系，最重要的是，它可以解释原因。
在表达的精确和简明性上，目前所提出的形式化定义，具有了令人惊异的效果，增强了我们进行准确表达的信心。
但是，它还需要记叙性文字的辅助，才能使内容易于领会和讲授。
出于这些原因，我想将来的规格说明同时包括形式化和记叙性定义两种方式。
直接整合：
这项技术是设计被传递参数和共享存储器的声明，并要求编程实现在编译时的一些操作（PL/I 的宏或%INCLUDE）来包含这些声明。
会议和大会：
会议中，任何人可以提出问题和修改意见，但是建议书通常是以书面形式，在会议之前分发。
新问题通常会被讨论一些时间。重点是创新，而不仅仅是结论。
该小组试图发现解决问题的新方法，然后少数解决方案会被传递给一个和几个结构师，详细地记录到书面的变更建议说明书中。
多重实现：
在大多数计算机项目中，机器和手册之间往往会在某一天出现不一致，人们通常会忽略手册。因为与机器相比，手册更容易改动，并且成本更低。然而，当存在多重实现时，情况就不是这样。这时，如实地遵从手册更新机器所造成的延迟和成本的消耗，比根据机器调整手册要低。
电话日志：
一种有用的机制是由结构师保存电话日志。日志中，他记录了每一个问题和相应的回答。每周，对若干结构师的日志进行合并，重新整理，并发布给用户和实现人员。这种机制很不正式，但非常快捷和易于理解。
产品测试：
设立测试小组是使设计决策得以贯彻执行的必要手段，同样也是需要尽早着手，与设计同时实施的重要环节。