本章内容虽然叫“需求分析”，实际上关于具体的需求分析操作步骤并没有深入去写，因为细化的话那将是一本厚厚的书，而需求分析在本系列中，是帮助大家了解项目的基本要求（主要针对本项目而已）。而写本章的主要目的想告诉初学者们一些常识与重要性，顺便写一写本项目的开发需求与需求文档格式，而不是具体的需求分析步骤。由于个人水平有限，文笔也并不怎么样，为了加快进度早点进入编码阶段所以写得有点水，大家先将就将就吧。
慢工出细活，磨刀不误砍材工。计划将要做的事情，按计划内容去做计划中的事情。
前言
需求分析文档按正常来说，它不应该由程序员来写的，是由项目经理与客户共同来完成，但是对于国内大多数软件公司（除了少数比较规范的公司专门设置有对应的职位外），很多是需求方口头提出、在WORD写几条要求或提供相关表格文档、提供参考的网站或软件、用相关模型软件简单的做出模型等一种或多种组合方式提出需求，然后由技术部负责人或直接是程序员来编写，当然还有不少情况是根本就没有需求分析这个步骤，需求方直接口头描述需要实现什么功能后，程序员就直接开工......相信大部分朋友正在处于这种水深火热当中或即将进入这种类型的公司。而初学者如果能了解需求文档编写，对以后参与项目的设计与开发将有非常大的帮助。
曾经看到一个园友讲述，他们公司做的外包，用了3个多月做需求分析，花一个月时间编码，一个月时间做测试与修改BUG，然后就交付客户使用了。从中可以看出需求分析在项目开发中的重要性。
当然更多听到的是无尽的吐槽，至于原因在前文已经简单的描述过了。对于需求分析，很多中小型公司都不太在意。我碰到不少拍脑袋的老板和客户，想法很多，变得也快，弄得你无从适合。同他们讲需求，确认功能，真的是一项非常艰巨的任务。而需求没有最终确定，产生的结果就是无限期的需求变动与修改，一个小小的功能可能改上N多次。没有文档就很难评估出你的工作量，通常是加班加点完成功能又没有加班费，而上头还会以为你开发效率低下，一个小功能你就要花费大把时间，浪费金钱。
为什么多数公司会忽略需求分析的重要性，主要原因我觉得有三种，一是需求方也不明白自己要的是什么；二是沟通问题，需求方自认为讲得很清晰了，以为开发方相关人员明白它想要的，而开发方也自认为已经理解了需求方的要求；三是觉得需求很简单，不必要花太多时间浪费，早点开发早点完工，节省开支。
由于篇幅有限，而需求知识点太多，所以本文不会详细描述需求分析的每个步骤，只是简单讲解需求分析的一些常识和本项目相关的需求分析。
需求分析说明
如果严格按照软件工程操作，需求分析阶段有很详细的操作流程，包括需求获取、需求分析、编写需求规格说明、需求验证、知识培训、需求管理、项目管理等等。而对于中小型项目来说，只要求做到前四项基本就足够了。
在处理需求前，首先我们要知道，需求对于需求方来说（不懂技术的），它就像是要实现功能的一份详细说明；一份业务流程；一份表格或文档；甚至可能是一个网站或软件等。他们不太可能与你细说具体要用到什么技术、算法、数据库该存储什么内容、服务器性能、安全等等，而我们如果与他讲太专业的东西，他们大都也会一头雾水，不知道我们在说什么。
其次，由于大家对各自专业领域的认知有所区别，我们也可能不了解他们专业里的工作流程和具体操作要求。
所以需求的采集，重点在于沟通与记录，要多提问多思考多论证。
怎么进行需求采集
在同用户的交流过程中收集各种用户的信息与要求，且第一时间将得到的需求整理成文字描述，一一记录下来。在需求采集的过程中，可以要求需求方提供相关的文档、报表、业务流程图等内容给我们参考，然后在这些基础上认真思考在软件上实现的UI大概样子，里面包含什么功能，可能存在什么问题或难点，及时与需求提出者做多次确认，看我们的理解是否是正确的，排除不合理的地方，明确各个业务流程与约束。
那我们这个项目要做什么（实现什么功能）？
第二章已经简单进过，在这里再整理一下：
1、开发一个有扩展性的框架，以后在这个基础上能实现网站后台、OA、CMR、SCM等各种系统；
2、要求开发、维护操作要简单，不要那么繁琐（即增加页面、添加修改或删除字段时，操作简单）；
3、有权限管理功能；
4、实现类似QQ登陆限制的效果，即同一时间一个帐号，只能单独在线，在不同地方登陆时会将前一个踢除下线并提醒；也可以设置公众帐号，多人使用同时在线；
5、用户登陆后使用操作都有详细操作日志记录（即进入什么页面执行了什么操作）；
6、后端管理员只能属于一个部门，但可以有多个职务（角色），有多个职务时也将拥有多个职务的共同权限；
7、所有页面、按键（工具栏的）操作权限都可以设置，不赋予权限将不能操作；
8、所有页面访问都需要加密处理，即不能修改页面参数中的属性（比如更新Id值）就可以查看到别人的资料或信息；
......（暂时先实现这些功能吧，其他的以后根据需要再考虑增加）
占用多少时间
一般对于中小型项目来说，视项目的复杂度与难易度，需求分析大概需要占用3到12个工作日比较合适，当然如果项目涉及到复杂的计算和业务流程，对安全、性能等要求也比较高的，需要分析占用时间也将成倍增长。
编写需求文档
需求文档的编写原则是：必须清晰明了描述要求，只描述做什么，不描述怎么做。
对于一些简单的小型项目，前面的需求描述+原型设计可能就已经足够了，有原型的话，在视觉上能更直观。
（注：由于时间关系，需求文档只简单的编写例子，不深入编写细节）
需求确认与变更
编写好需求文档后，要即时与需求方进行确认，将整理出来的问题与难点进行反复讨论确认，然后再次完善需求文档再次确认，直到双方达成共识认可文档。
当然在整个开发过程中，需求不断变化这是不可避免的，所以在需要分析阶段需要尽可能的将一些可能会产生重大变量的需求提前爆露出来。因为它在开发的不同时间段内提出变更，而对软件产生的影响也是不一样的。小的变更可能会导至开发周期延长，而大的变更，有可能会导至项目推倒重做。
我们在做需求的时候，要让需求方知道需求变更对项目的影响，以便让他们在考虑需求变更时更加谨慎。当然最好让需求方签属以下内容，有存档为证也可以避免一些不必要的不合理需求出现。
“我同意这份文档表达了目前我们对项目软件需求的了解。进一步的变更可在此基础上通过项目定义的变更过程来进行。我知道变更可能会使我们要重新协商成本、资源和项目时间工期任务等。”（这句话摘自《北京理工大学软件工程实践》汤铭端老师的PPT）
每次需求变更时，也必须编写对应的变更文档，且让需求方签字确认，这样对计算工期（开发成本）、延长项目进度，以及向上层或需求方反馈我们开发人员工作强度、能力都有明确的凭证。
我们在开发本框架时，前期虽然设定好框架结构和功能要求，但实际开发中可能会遇到一些不可避免的因素影响，产生一些变化，这时将会认真思考需求变更要求，对于必不可少，必须添加的功能则会直接加入到项目开发中，而对于可有可无的，或对当前项目开发暂时不会产生影响的，将会放到以后开发，一切以开发文档中的设计好的功能要求为准，以做好项目开发周期控制，能按时按质按量完成项目开发。
总结
最近看了不少这方面的资料，知识量太大了，很难消化完全，无从下手。本章写完后反复看了N多次，都不怎么满意，没有讲明需求分析的要点，在此向大家抱歉。自己在需求分析这一块也是比较薄弱的，还需要继续努力学习。
总之需求分析是一项技术活，需要沟通与细心，它决定整个项目最终完成效果，是一个非常重要的步骤。没有足够的准备，越早开始写程序，就要花越长时间才能够完成。方向错了，跑得越快离目标就越远，越难掉头。离开了计划，在开发中不停的添加需求，那项目将永远也完成不了，结束不了。
版权声明：
本文由AllEmpty原创并发布于博客园，欢迎转载，未经本人同意必须保留此段声明，且在文章页面明显位置给出原文链接，否则保留追究法律责任的权利。如有问题，可以通过1654937@qq.com 联系我，非常感谢。
发表本编内容，只要主为了和大家共同学习共同进步，有兴趣的朋友可以加加Q群：327360708 或Email给我（1654937@qq.com），大家一起探讨。
更多内容，敬请观注博客：http://www.cnblogs.com/EmptyFS/
来源：https://www.cnblogs.com/EmptyFS/p/3653934.html