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