谈什么呢，先谈需求分析，做了几年开发下来，发现需求分析是个很重要的问题，很多程序改了又改，甚至有同事说：“程序就是改出来的”，这其中很大一部分问题就是需求分析没做好或是做的有缺失，所以先把这个问题拿出来说说，既是对自己的一个总结，也希望对别人有所帮助！

做需求分析，我的感觉是尽可能的减少信息传递的个体，先说下我对需求分析的理解，就是把客户的功能描述转化为软件员所能理解的功能描述，并在客户描述的基础上去除不合理的地方，补充系统缺失的地方，***为系统的概要设计，详细设计提供准确，有效的数据基础。那么这边就有个信息传输的问题，例如一个企业要做个系统，他的老板把他的系统理解传递给手下经理，再由经理传递给科员，然后找软件公司，在来个来回，从前台人员传递给项目经理，再由项目经理传递给程序员，在这样一个信息传递中，每个人都有各自对系统的理解，那么就会产生偏差，误解，而如果把每一个人的偏差与误解累加起来，我们就会发现一个很恐怖的事情，那就是我们的系统可能与客户原始的初衷相差很远，甚至可能就是两种系统的理解，所以我个人感觉在条件允许的情况下尽可能地减少中间的信息传递，让信息损失与误差降低到***！！

还有一种情况是他的软件需求是由很多个人的集体意见构成的，那么这里就有主次，轻重之分了。比如一个办公自动化系统，信息发布的需求是由某个科长提出的，公文流转是由打印室提出的，文档管理是由档案室提出的，而且在提需求的过程中，有科员也有领导，那么在这里，我们就要区别对待了，首先要做的便是把所有人意见整理一下，把大家的共同意见先整理出来，因为这是我们必须要做的，而且是首要考虑的，然后，我们便是抓大头，如果某个科员和他的领导在需求方面有分歧，甚至南辕北辙，那么我们就是要把领导的需求放在首要位置，当然这建立在合理的基础上，优先考虑领导需求，把两份文档整理出来，那么系统的雏形也就差不多出来了。还有不要忘记，那就是确认，把整理好的需求与各个科室的领导再对下，***是形成文档，那么这个需求相对完善了！

还有一种情况也是我碰到过的，那就是客户对某个要求比较强硬，而这个需求在软件实现上有其不合理的地方，那么我们就要据理力争，虽说“客户是上帝”，但是我觉得维持一个公司的技术独立型，运营独立性很重要，我们不能被客户牵着鼻子走，而是我们引导客户实现他的系统功能，完善他的各项管理！

而我遇到最多的便是小软件公司不负责任，说难听点就是忽悠人，但也不是说他乱做，而是仅实现功能地做，甚至我原来公司做个办公自动化系统就是照着别人的做，就差没把别人的代码拿过来换成自己公司的名称了，完全脱离需求实际，不需要的功能多做了，要的功能少做了或是彻底没做，结果呢就是改啊，拖啊，老板竟然还在那自鸣得意，认为照别人做是个不错的主意，而项目完不成便就是我们的责任，哎！而且很多公司认为只要实现功能就行了，对他们来说最重要的就是收到钱，完全不负责任。所以个人认为在做需求分析时，站在客户的角度设身处地的去思考系统这是很重要的，我们的客户不只是要一个实现功能的系统的，而是要一个给他带来效益的，科学的，合理的，人性化的系统，那么很多时候客户在系统中没有想到的，我们就要考虑到，这不是给自己找麻烦，而是保持一个系统完整性所必须的，我们提供的不只是个软件，而是一个精致的产品，一种优质的服务，甚至是一整套科学合理的完成某些工作的先进理念！而且在很多时候，用户体验是很重要的，而在我接触的公司基本就不考虑这个，在他们来说实现功能，收到钱比什么都重要，所以便一直就是小公司！

关于需求分析的总结大体就到这了，当然还有很多其他的东西也是很重要的，例如在系统开发前我们必须做好功课，充分了解系统所在行业的行业背景，相关流程，甚至去下一些别人写的与系统有关的程序，“存在的都是合理的”，很多时候别人的系统是很值得借鉴的，注意，是借鉴而不是抄袭，我们要学的是思想。当然关于需求分析还有很多东西，说白了，这也是门学问，而我只是个学习者，还有很多不足，望各位不吝赐教！

【编辑推荐】

1. 资深项目经理谈软件项目管理应注意的问题
2. 软件项目管理总体流程设计
3. 减少软件开发成本的十个技巧
4. 软件工程师必知的十个概念
5. 小型软件项目开发流程探讨