在第一个版本就把这些标准全部实现，而是有步骤有重点地实现，逐步成为一个好软件。因此《需求变更文档》是不必可少的，同样作个Excel表格，量化解决。包括下列几项：客户名称、需求提出人、提出日期、需求关闭时间，功能模块名，客户现在版本号，需求描述，需求分类（需求、Bug）等。每次发布新版本都把从上一版本发布之日关闭的需求列表都单独摘成一个文件，附带到这次新发布的版本之后。
此举有两个好处，其一，能够清楚的列出客户以往所提的需求，因为有一些客户提出的改动总是反反复复，一个问题一会要改成A,然后觉得不好要改成B，之后觉得还不如A好，便又要求改回去，这样给公司的进度和安排带来很大的不便，如果因为这个耽误了其他的工作，便可以有此根据和客户进行沟通，防止客户赖账；其二，可以评判技术支持和相关程序员的工作量。此文档为EXCEL格式，但最好还有一个word类型的文档，每次客户提出修改意见时，将此文档打印出来交由客户签字，作为凭证，此方法实际中并不是次次可行，一些强权客户或不敢承担责任的就不签字，那也没辙。
《测试结果》和《需求变更文档》要定期（可一周或一个月）给老板一份。这表明了你的工作量，让他看看你确实一直很辛苦地在工作，另外，也能看出你的认真负责态度。
13、《用户使用手册》
按标准说，应该由文案写，但在大多数的软件公司中都不设这个职位，因此要么由项目经理写要么由测试人员写，关键看是谁给客户做培训。在目前我做的这个项目中，并没有专职测试，所以这个工作还是项目经理来做。《用户使用手册》可根据实际情况写成三种版本，其一，chm类型文件，适用于C/S的项目，就像微软的产品中，都会有此帮助手册；其二，做成网页形式的帮助文件，适用于B/S项目；其三，就是做成word文档，虽然可保存至本地，但使用起来没有前二者方便。
剩下的还有《开发任务书》、《项目总结报告》、《软件验收评审》等，并不是必须的，可根据客户需要和实际的项目来选择使用，再次并不一一赘述。
并且，以上所有文档，虽然有些是必须的，比如《需求分析说明书》、《测试结果》、《用户使用手册》等，但根据不同的行业、不同的地区以及不同的项目和团队规模，文档的具体内容都会有所不同，不必较真。
只要能抓到老鼠，白猫黑猫都是好猫，况且，没必要的多余的文档会浪费时间和成本等资源。