这两周一直在做需求文档的评审。如果一直关注我的博客就了解，我们公司的开发流程不算规范，但正在努力正规化。
这周看了3个项目的文档，简称为A、B、C项目吧，逐一说明。
A项目。这个项目其实已经做过了，但是上面领导的意思是要产品化，就是根据客户的需要，可以嵌入到不同的项目中去，相当于把现有功能进行插件化处理。项目经理P是原先做过这个功能的人，但是具体做这个插件化的活儿的程序员是W，写需求文档的却是L，所以我检查需求文档后，P、W都不在，L什么都不知道。一直到P回来，才解决了文档中的疑问。A的功能不算复杂，就是扫描或拍照文件，存储到数据库中，但是实际我审查的时候，还是出现了很多的问题。比如登录，上面写有登录过程，结果我问的时候，说是用附属系统的登录用户，本身插件没有做登录、角色等处理，这样实际会有安全性问题的，知道请求就可以直接进入使用此功能了；还有一个复用档案的功能，什么叫做复用，听他们的解释，其实就是正常使用，只是一个档案可以挂接多个人而已；一个功能说的是传递格式使用xml，我这里就不清楚了，是文件可以导出xml后传递，还是用xml格式传递消息请求，最后确认是xml消息请求，我觉得使用xml消息应该是设计，而不是需求功能。总之，写文档的人其实并没有了解业务，很多内容写的都不清楚，并没有达到目的。29页的文档，21个疑问。
B项目。项目经理的态度很认真，功能写的很清楚，还画了uml用例图、流程图等等。B是一个软硬件结合的项目，公司做3、4次了，每次都有些这样那样的问题，那就重新做。关键问题是硬件部分是我们另外一个子公司的产品，硬件工程师很难交流，鸡同鸭讲的感觉吧。主要功能就是软件作为中心端去操作硬件，文档中就有一个内容没有说明白，其实除了软件操作外，硬件自身仍然有一个小系统可以操作自己；还有一个流程图也都画错了；特别是数据库设计，使用的上一个版本的数据库，但是在我看来就是设计的不合理，比如说是库存表，但是实际是变动表，库存用变动数据进行计算，这是鬼的库存表。为了数据库，我和开发经理说了很久。其实我觉得数据库设计可以放到设计阶段，需求规格说明书没有必须写的太细。27页31个疑问。
C项目。C项目其实已经做过一个用户了，现在移植到另外一个用户而已，所以内容不需要太多的变动。需求写了很多，但是都是功能名称和数据表设计，里面做什么的几乎没有说，所以我也挑不出什么问题来。31页2个疑问。
另外，还有一个统一的问题。需求规格说明书，都是大家来回copy的，功能不说了，都是自己写，但是非功能性需求，比如性能、可靠性、移植性等等，都是一样的，而且里面都是虚话套话，对于测试没有任何的意义。
其实我觉得测试对于需求规格，主要关注为什么有这个功能，这个功能具体是做什么的，而且功能之间没有矛盾的地方就够了。比如具体功能你可以不写，但是具体功能写了，至少增删改查的循环至少都要说明吧，不能只说明一个。设计内容可以在设计阶段写，但是写了，就要保证确实用心思考到了。非功能需求不要乱写，至少要有可以测试的数据标准，不要讲套话，否则测试没有依据，你说给你测还是不给你测。
总之，需求规格只要写，就要说清除具体的业务功能，不需要的内容不要乱写，我觉得从我这里就可以认可这份需求。