参与人事档案管理系统将近一年了，这一年中通过这个项目发现了许多问题，不管是在软件设计方面还是在团队合作方面以及在与用户交流获取需求的过程中暴露出了许多问题，也学到了许多东西，今天主要总结一下在需求分析上的问题与收获。
在软件生存周期中，其它四个阶段都是面向软件技术问题，只有需求分析阶段是面向用户的。需求分析是对用户的业务活动进行分析，明确在用户的业务环境中软件系统应该"做什么"。但是在开始的时候，我们和用户双方都不能准确地提出系统要"做什么？"。而我们又不是用户问题领域的专家，不熟悉用户的业务活动和业务环境，又不可能在短期内搞清楚；而用户不熟悉计算机应用的有关问题。因此双方互相不了解对方的工作，又缺乏共同语言，所以在交流时存在着隔阂。
我们主要以进化型为主以探索型为辅，探索用户目标需求最终确定一种可行性。这样迭代将每一种可行性在上一可行性的基础上叠加，走进化型路线，逐步将原型进化成最终的系统。
对于需求变更是最令人头疼的事。首先由于我们不清楚业务所以最初是用户带着我们走，这样即使用户提出的需求存在问题，我们也没法去发现问题或者向用户提出我们的建议，去避免这些风险从而避免后期的需求变更。站在用户的角度来说，他们很难精确完整地提出它的功能和性能要求。一开始只能提出一个大概、模糊的功能，只有经过长时间的反复认识才逐步明确。有时进入到设计、编程阶段才能明确，更有甚者，到开发后期还在提新的要求。更何况有时候有些具体实现明明就是按需求完成的，但用户还是会更该需求，因为最初的需求是大概的、抽象的、模糊的，一但这些需求转变成实现再经过一段反复的认识用户提出一些更改也是在所难免的。面对需求变更我们要做的一是要做好准备应对需求变更，将风险降到最低，二是做好需求变更记录。
当我们拿到用户的需求时，有时这样的需求只符合软件的局部要求，而要将这些需求实现并且跟其他模块进行融合还需要去宏观掌控将这些需求适当改造，达到既能满足用户的需求还能符合系统的整体需求，这样的需求实现才能更好的为系统提供服务。
对于将来要变更的需求，我觉得紧紧做到严格控制需求变更的申请流程以及做好变更记录是远远不够的，因为有些需求的变更是不可避免的。我们还要在软件开发阶段将这些风险降低。在软件开发阶段可采取面向对象的设计思想，在设计之初多多应用设计模式，充分考虑将要变化的需求，预留出接口。另一方面就是将软件的功能之间尽可能的解耦，做到灵活可配置。两种方法有点共同之处，首先可能不应用设计模式的话我们只需要一个类几个方法就可以满足需求，而我们还要去抽象出接口，建立实现类之间的联系。这样有点将简单的问题复杂话的意思，同样软件功能做灵活不仅仅需要我们把这个功能实现出来，还需要我们后期将这个功能进一步做成可配置、可管理，这就需要我们额外添加功能去配置去管理将要变化的功能，从而实现将功能的变化控制在一个可控的范围内。
原文地址：http://blog.csdn.net/leimengyuanlian/article/details/34527633
