近来，我遇到一个开发小组开发包括代码编辑器在内的一套内部使用的计算机辅助软件。不幸的是，当他们开发完这个工具后，发现这个工具不能打印出源代码文件，使用者当然希望有这个功能。结果这个小组只好手工抄写源代码文档以供代码检查。这说明那怕需求明确无误并构思准确，如果我们没有编写文档，软件达不到期望目标也只能是咎由自取了。
相反的情况，我曾见一个要集成到“错误跟踪系统”中的简单界面写了一页需求说明。而操作系统系统管理员在为处理脚本时发现简单的一张需求清单竟是如此有用。他们依据需求对系统进行测试时，此系统不仅非常清晰地实现了所有必需功能，而且未发现任何错误。
事实上，需求文档在开发过程中一直起指导作用。
3.需求分析过程
可把整个软件需求工程研究领域划分为需求开发和需求管理两部分更合适
需求开发可进一步分为：问题获取、分析、编写规格说明和验证四个阶段。这些子项包括软件类产品中需求收集、评价、编写文档等所有活动。需求开发活动包括以下几个方面：
确定产品所期望的用户类别。
获取每个用户类的需求。
了解实际用户任务和目标以及这些任务所支持的业务需求。
分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息。
将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。
了解相关质量属性的重要性。
商讨实施优先级的划分。
将所收集的用户需求编写成文档和模型。
评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚。
需求管理需要“建立并维护在软件工程中同客户达成的合同” 。这种合同都包含在编写的需求文档与模型中。客户的接受仅是需求成功的一半，开发人员也必须能够接受他们，并真正把需求应用到产品中。通常的需求管理活动包括：
定义需求基线(迅速制定需求文档的主体)。
评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它。
以一种可控制的方式将需求变更融入到项目中。
使当前的项目计划与需求一致。
估计变更需求所产生影响并在此基础上协商新的承诺，这种承诺具体体现在项目解决方案上。
让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪。
在整个项目过程中跟踪需求状态及其变更情况。
以上几点说明是我总结了成功实施项目后系统分析人员的经验，同时也根据国内外的其他系统实施的相关成功经验，进行了总结。
文章来源于领测软件测试网 https://www.ltesting.net/
