背景
参与人事档案管理系统将近一年了，这一年中通过这个项目发现了许多问题，不管是在软件设计方面还是在团队合作方面以及在与用户交流获取需求的过程中暴露出了许多问题，也学到了许多东西，今天主要总结一下在需求分析上的问题与收获。
供需交流困难
在软件生存周期中，其它四个阶段都是面向软件技术问题，只有需求分析阶段是面向用户的。需求分析是对用户的业务活动进行分析，明确在用户的业务环境中软件系统应该"做什么"。但是在开始的时候，我们和用户双方都不能准确地提出系统要"做什么？"。而我们又不是用户问题领域的专家，不熟悉用户的业务活动和业务环境，又不可能在短期内搞清楚；而用户不熟悉计算机应用的有关问题。因此双方互相不了解对方的工作，又缺乏共同语言，所以在交流时存在着隔阂。
如何获取需求
需求分析是软件工程中很重要的一个环节，直接决定着项目的成败。需求分析是一项重要的工作，也是最难的工作。需求分析的方法有很多种，如面向过程（自上向下分解）、 信息工程（数据驱动）（数据流分析结构化分析方法）、 面向对象（对象驱动）。这些方法很实用对需求分析过程来说也很常用，但是对于我们这些完全不了解用户业务的开发人员来说再好的分析方法也用不上，不了解业务不知道如何将业务一层层分解、不能正确的把握数据的流向，更不用谈面向对象了。
面对这样的情况，我们只能每次接受用户的一部分需求，然后做一个最基础的原型出来。这种原型要比需求分析方法中的原型方法复杂一点。需求分析的原型方法只要求我们用某些软件工具快速的建造一个原型系统，这个系统只是一个界面，然后听取用户的意见，改进这个原型。以后的目标系统就在原型系统的基础上开发。而现实中如果我们只做一个界面的话，一个没有数据的一个空壳子，对于不懂如何开发软件、不知道何为原型的用户来说，让他们从这样的原型上去提建议、提需求还是有些困难的。所以我们在原型方法的基础上将获得的原型功能全部实现了，以此作为一个原型再去进一步获取需求。
谈到原型方法就得必须谈谈原型方法的三种类型：探索型、实验型、进化型。
探索型：目的是要弄清楚对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性。
实验型：用于大规模开发和实现前，考核方案是否合适，规格说明是否可靠。
进化型：目的不在于改进规格说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统。
我们主要以进化型为主以探索型为辅，探索用户目标需求最终确定一种可行性。这样迭代将每一种可行性在上一可行性的基础上叠加，走进化型路线，逐步将原型进化成最终的系统。
客户的需求为何总是再变
对于需求变更是最令人头疼的事。首先由于我们不清楚业务所以最初是用户带着我们走，这样即使用户提出的需求存在问题，我们也没法去发现问题或者向用户提出我们的建议，去避免这些风险从而避免后期的需求变更。站在用户的角度来说，他们很难精确完整地提出它的功能和性能要求。一开始只能提出一个大概、模糊的功能，只有经过长时间的反复认识才逐步明确。有时进入到设计、编程阶段才能明确，更有甚者，到开发后期还在提新的要求。更何况有时候有些具体实现明明就是按需求完成的，但用户还是会更该需求，因为最初的需求是大概的、抽象的、模糊的，一但这些需求转变成实现再经过一段反复的认识用户提出一些更改也是在所难免的。面对需求变更我们要做的一是要做好准备应对需求变更，将风险降到最低，二是做好需求变更记录。
对获取的需求进行加工
当我们拿到用户的需求时，有时这样的需求只符合软件的局部要求，而要将这些需求实现并且跟其他模块进行融合还需要去宏观掌控将这些需求适当改造，达到既能满足用户的需求还能符合系统的整体需求，这样的需求实现才能更好的为系统提供服务。
捕获将来一定或者可能要变的需求
对于将来要变更的需求，我觉得紧紧做到严格控制需求变更的申请流程以及做好变更记录是远远不够的，因为有些需求的变更是不可避免的。我们还要在软件开发阶段将这些风险降低。在软件开发阶段可采取面向对象的设计思想，在设计之初多多应用设计模式，充分考虑将要变化的需求，预留出接口。另一方面就是将软件的功能之间尽可能的解耦，做到灵活可配置。两种方法有点共同之处，首先可能不应用设计模式的话我们只需要一个类几个方法就可以满足需求，而我们还要去抽象出接口，建立实现类之间的联系。这样有点将简单的问题复杂话的意思，同样软件功能做灵活不仅仅需要我们把这个功能实现出来，还需要我们后期将这个功能进一步做成可配置、可管理，这就需要我们额外添加功能去配置去管理将要变化的功能，从而实现将功能的变化控制在一个可控的范围内。
总结
以往做系统需求都很明确，并且还有原型系统作为参考，很少能够凸显出需求分析的重要性。自己提需求，然后自己开发系统，这样明显降低了很多要求，而开发出来的系统也只能自己用。软件工程学了那么多，需求分析的方法也学了很多，但与实际应用联系起来的实践机会还很少，所以我们对知识的掌握还停留在理论层次上，真正碰到问题的时候还不能做到手到擒来。而这一次是第一次将需求提供与开发角色分离需，也就决定了系统开发不再全部以我们开发人员自己的意志为转移，更多的是站在用户的角度去思考问题、解决问题。
透过项目谈需求分析