前言：作为软件开发人员，一定要了解软件工程学，而这门科学的第一步就是需求分析，打开任何一本软件工程的书籍翻看目录就知道了。在实际的一个项目中，在进行需求分析之后，对这个项目进行规划、编码，到最后完成这个项目，看着这个项目最后实施应用，对我们开发人员来说，这真是一种成就感。可是在日后的使用过程中，客户不停地提出各种意见和建议，让我们没法把精力投入到其他项目，而是不停地修改旧作，相信我们都遭遇过。

需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程。需求分析主要(还有很多，比如性能需求、可靠性需求、逆向需求、将来可能提出的需求，这里不做介绍)包括：业务需求、客户需求和功能需求三个部分。业务需求(Business Requirement )意为客户对产品的目标或者要求;客户需求(User Requirement )意为客户在使用产品过程中需要完成的一系列任务，功能需求(Functional Requirement )指定了产品系统必须提供的功能。在整个软件系统的开发过程中，其实有很多问题是由于在需求分析阶段没有正确实施而产生的。下面一一列出：

1、对需求理解的错误

我是从工程角度来理解的，当甲方(客户)向乙方(开发方)提出产品需求的时候，其描述过程往往是通过口述语言来表达出来的，但不可能100%的保证其描述正确，同时也不能保证收听者完全正确理解，这是就产生了分歧。当乙方将产品初期模型交给甲方看，甲方惊呼这不是我们要的东西，这时已经浪费了大量的时间、人力和物力。

2、实际应用与初期预想有出入

当客户提出具体要求之前，其实他并不知道这个产品在实际使用中的情况，一切要求都是凭空想象出来的，客户将要求提给开发方，开发方开始工作，当客户拿到这个产品的Demo版的时候，开始实际操作，他就会慢慢对产品的界面、操作、易用性、功能等等有一些认识，这个时候就很有可能对产品需求有更改需求。

3、每个客户的情况不一

人的五根手指还不一样长呢，客户也一样，100人的公司和10000人的工厂，实际应用怎么可能完全一样?但这里也不排除人为因素的存在。

4、产品本身的问题

人无完人，我们会努力做到精益求精，力保产品的可靠性，但难免会遇到bug。客户在使用了一段时间后，发现产品的自身问题，可能是数据莫名丢失，也可能是系统崩溃，还可能是兼容性问题，这个时候就需要找到开发方来进行产品升级或者修改。 就算需求分析很完善，整个项目进行的一切顺利，但每个开发人员的能力参差不齐，造成产品自身问题，这是根本无法避免的。

我们当然希望客户永远不会提出需求变更，但如果一定要变化，而我们又不得不面对，我们该怎么办?

对需求分析人员培训

看了上面的分析，当然第一个需要培训的就是需求分析人员了，这是开始，也是根源，还有就是规范需求分析人员与客户的沟通方式，以及规范记录需求的文档格式。争取保证双方和谐地完成沟通会谈。如果还是不行，那就只能更换作需求分析的员工了。

对开发人员培训

我想这个不用多说了吧，我们都该有紧迫感了。

保证需求文档的有效性

工作以来我还从未看过正式的需求文档，这也是软件业普遍存在的问题，因为人们不重视它，没人关心它是否合理，没人关心它是否实用，有的甚至是在日后慢慢补进去的。所以希望开发公司一定要重视需求文档，要对需求文档有一个合理性的审查。

从软件工程学来看

首先要从系统分析和编码入手，提高系统的可靠性，保证代码的质量，增加系统的可扩展性和可移植性，降低因需求变更而带来的风险和维护代价。

从测试入手，一定要保证测试的质量，并且及时作测试。

采用面向对象(OO)技术

面向对象方法学的出发点和基本原则，是尽可能地模拟人类习惯的思维方式，使开发软件的方法与过程尽可能接近人类认识世界解决问题的方法与过程，也就是使描述问题的问题域与实现解法的求解域在结构上尽可能一致。OO 的意义在于分析和设计软件系统的思考方式，以及建立对象库以后的软件重用将给软件系统的开发带来质的改变，但是在建立OO 开发体系之前的过程，一定会是一段荆棘遍布的路，需要付出加倍的努力以及达成思想的转变。这里还有一个误区需要澄清的是很多人以为用了C++，PB ，VB ，DELPHI 就是面向对象的开发了，其实只是用了一些面向对象的工具，骨子里仍然是结构化的分析和设计方法，套上一层OOP 的外壳而已。

可见，在面对需求变更时，除了要对人员培训来提高开发团队的整体素质外，从系统分析和设计角度可以提高产品的可靠性，做到对需求变更的灵活应对，这些至少可以在一定程度上降低产品的风险和维护代价，提高客户的满意度。

以上这些是我工作以来对软件工程学以及实际工作中的一些认识，并且参考了一些书籍和网络文献写出来的，希望可以对大家在解决问题中有一些实际的帮助。