上线以后的软件产品总是不可避免会出现一些超出预期的错误或异常，而软件产品的使用者大多数是普通用户，这部分人并不了解软件的内部逻辑，我们不可能要求他们提交一份详细的错误文档来帮助我们解决问题，多数情况只能依靠软件自动收集的错误信息去进行问题定位和解决，所以我们需要知道哪些数据是软件应该在出错时收集的，这些信息越精确，对我们排查错误就越有帮助：

1.产品的具体版本;
2.操作系统和Internet Explorer的版本（Windows的许多功能其实都是由Internet Explorer及其相关组件提供的，所以它的版本信息对调试图形界面程序很重要，其它系统中也如此，尽量记录系统底层中应用比较广泛的组件信息）;
3.发生崩溃的代码所处的文件名和行号;
4.字符串格式的错误信息;
5.错误类型的独特编号;
6.用户对当时所做事情的描述;
7.用户的电子邮件地址.

总结自《软件随想录》：
免责声明：出于自我保护的目的，因为规格书不可能非常完美;
作者：为规划书负责的人，如果规格书有问题，就必须要有一个人去更正其中的问题;
使用场景：设计产品时，我们需要对产品的真实使用场景进行设想，从我们的产品使用人群中选取一些有代表性的目标用户群，为每一类人群设想一个虚构的但非常典型的用户，设想的场景越是逼真生动，设计出的产品就越适合用户使用;
非目标：在一个团队做产品时，或许每个人对产品的功能的理解都不一样，如果每个人都将自己的想法做出来，必将导致时间和金钱的浪费，而且最终的产品的功能不一定就是用户都需要的，因此我们需要将那些不需要的功能列出来，以免引起争议;
概述：可以是简单的流程图，也可以是对基本架构的详细文字描述，人们在对产品的大致轮廓了解以后会更容易理解产品的细节
细节：这是规格书中最重要的部分，需要将产品需要注意的细节详细的描述出来，例如那些可能出现的情形以及对应的解决方法，还有那些需要做出设计决定的地方也必须详细的写出来;
待解决的问题：产品设计之初必然会有很多不如人意的地方，也会有一些暂时解决不了或是没有解决的问题，我们需要将这些问题标注出来，方便以后讨论解决方案;
多角度的注释：阅读规格书的人有很多的类型，每类人的理解方向和关注点都不一样，我们需要对一些有专业倾向的地方做出多种角度的注释，好方便不同的人去理解;
规格书需要与时俱进：随着产品的开发和不断的做出新的设计决定，我们的规格书也必须及时更新，规格书总是反映着一个团队对于产品开发和使用的最佳共识;