前言：作为软件开发人员，一定要了解软件工程学，而这门科学的第一步就是需求分析，打开任何一本软件工程的书籍翻看目录就知道了。在实际的一个项目中，在进行需求分析之后，对这个项目进行规划、编码，到最后完成这个项目，看着这个项目最后实施应用，对我们开发人员来说，这真是一种成就感。可是在日后的使用过程中，客户不停地提出各种意见和建议，让我们没法把精力投入到其他项目，而是不停地修改旧作，相信我们都遭遇过。
需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程。需求分析主要（还有很多，比如性能需求、可靠性需求、逆向需求、将来可能提出的需求，这里不做介绍）包括：业务需求、客户需求和功能需求三个部分。业务需求（Business Requirement）意为客户对产品的目标或者要求；客户需求（User Requirement）意为客户在使用产品过程中需要完成的一系列任务，功能需求（Functional Requirement）指定了产品系统必须提供的功能。在整个软件系统的开发过程中，其实有很多问题是由于在需求分析阶段没有正确实施而产生的。下面一一列出：
1、对需求理解的错误
我是从工程角度来理解的，当甲方（客户）向乙方（开发方）提出产品需求的时候，其描述过程往往是通过口述语言来表达出来的，但不可能100%的保证其描述正确，同时也不能保证收听者完全正确理解，这是就产生了分歧。当乙方将产品初期模型交给甲方看，甲方惊呼这不是我们要的东西，这时已经浪费了大量的时间、人力和物力。
2、实际应用与初期预想有出入
当客户提出具体要求之前，其实他并不知道这个产品在实际使用中的情况，一切要求都是凭空想象出来的，客户将要求提给开发方，开发方开始工作，当客户拿到这个产品的Demo版的时候，开始实际操作，他就会慢慢对产品的界面、操作、易用性、功能等等有一些认识，这个时候就很有可能对产品需求有更改需求。
3、每个客户的情况不一
人的五根手指还不一样长呢，客户也一样，100人的公司和10000人的工厂，实际应用怎么可能完全一样？但这里也不排除人为因素的存在。
4、产品本身的问题
人无完人，我们会努力做到精益求精，力保产品的可靠性，但难免会遇到bug.客户在使用了一段时间后，发现产品的自身问题，可能是数据莫名丢失，也可能是系统崩溃，还可能是兼容性问题，这个时候就需要找到开发方来进行产品升级或者修改。 就算需求分析很完善，整个项目进行的一切顺利，但每个开发人员的能力参差不齐，造成产品自身问题，这是根本无法避免的。
我们当然希望客户永远不会提出需求变更，但如果一定要变化，而我们又不得不面对，我们该怎么办？
5、对需求分析人员培训
看了上面的分析，当然第一个需要培训的就是需求分析人员了，这是开始，也是根源，还有就是规范需求分析人员与客户的沟通方式，以及规范记录需求的文档格式。争取保证双方和谐地完成沟通会谈。如果还是不行，那就只能更换作需求分析的员工了。
6、对开发人员培训
我想这个不用多说了吧，我们都该有紧迫感了。
6、保证需求文档的有效性
工作以来我还从未看过正式的需求文档，这也是软件业普遍存在的问题，因为人们不重视它，没人关心它是否合理，没人关心它是否实用，有的甚至是在日后慢慢补进去的。所以希望开发公司一定要重视需求文档，要对需求文档有一个合理性的审查。
7、从软件工程学来看
首先要从系统分析和编码入手，提高系统的可靠性，保证代码的质量，增加系统的可扩展性和可移植性，降低因需求变更而带来的风险和维护代价。
从