需求分析的任务

1. 需求分析的任务

2. 项目管理：怎样做需求分析

首先不知道你的项目是哪种类型的客户，拿通用的信息系统的项目来讲（对于工程类的项目你可以参考一下），需求分析主要有以下内容和步骤：
1、确定客户的原始想法，大的思路。他开展这个项目的目的是什么？要达到什么目标？
2、找出所有的项目干系人，分析每种类型的干系人对项目的期望值。如：客户业务操作员，他们希望操作简单，符合他们目前的操作习惯；管理人员，希望项目能替他们解决月报和年度的报表统计，这项工作手工做很复杂，很占时间；客户领导（决策者）希望系统能在他决策时提供一些参考意见；系统管理员希望所有的参数都可以配置，业务流程可以自己改动等。
3、调研方式：问卷，讨论会，贴身岗位实习（对于复杂业务很有用）等。
4、在调研时，最为重要的是需要随时记录，及时整理。
5、调研后，及时整理用户需求文档，并且和客户确认。
6、用户需求文档确认后，由系统分析员一起，对需求进行分析，整理形成需求规格说明书，并且进行客户参与的需求评审，通过评审后的需求客户进一步确认。
7、根据需求规格说明书，形成需求矩阵，以便需求跟踪。至此，需求分析工作基本结束。
随后，根据需求规格说明书，结合自身技术特点，选择技术路线，确定技术架构。开始设计工作。

3. 项目管理：怎样做需求分析

做项目真辛苦阿！这样的感叹整天都挂在口上。客户需求变动确实是一个软件开发永远不变的话题。为什么小的软件企业面对经常变动的需求是如此的狼狈？到底要怎么做才能满足客户的需求？
听棠的“客户需求何时休”深刻的披露了这个问题存在的根源。
需求分析，不仅仅是拿到客户的需求，更重要的是还需进行分析，了解细节，并就细节跟客户咨询，获取最详细的资料。客户所能提供给你的只是他们想到的功能需求，很多问题并不在他们考虑的范围之内，如果作为项目承担方没有去做分析，简单的按照功能要求去设计、规划，最终出来的系统是很难完全符合客户的业务流程的，这时，自然需要更改，被看成了需求的更改。其实，都是缺乏分析所一手造成的。问题等到系统出来了才被发现，这样的系统本身就是先天不足的了。
听棠所说到的几点，感受特别深：
“其实问题出在开头，客户需求只是软件需求分析的一部分，虽然是比较重要的一部分，但也不要只是去记客户的需求，而是要把客户的需求进行分析”
“客户本身是不怎么懂技术的，客户只知道自己的业务需求，而在软件设计时，是在把业务需求抽象到系统中实现的，把业务转变为逻辑时，一切都应该符合逻辑的，但客户的业务思想有时候在软件系统实现时会有问题的，这就需要分析时分析出来的。少了分析，问题也会在后面的开发中暴露出来，到时可就更麻烦了。”
还有客户的需求本身会有矛盾（这矛盾是指在逻辑角度来讲），客户本身是意识不到的，只有在分析设计时，才会分析出这里的矛盾，而这些问题，如果在期初时，软件负责人不分析，而是纯粹的“听从”客户要求去做，当暴露这些问题时，你怪客户也没用啊。
项目需求分析报告，在了解客户需求时，不要不动脑子，不要一味的点头说“i
c”，其实在表面的业务里面可能包含着n多的细节，这些细节是需要你反问客户的，只有当你提的问题越多，最终获取的需求最具体，才能让项目越顺利。而且有很多问题，都是在你的反问中，客户也才开始思考本来没思考过的问题，客户也会找到一种合理的需求给你，有人会觉得这样了解客户需求未免太麻烦了。至于一些在技术上会遇到问题的地方，也要告诉客户，别以为到时候再说，客户是不关心你的技术细节的，但你如果给他解释的话，他也会试着理解的。
客户的需求本身是无休止，因为他们本身也在变，但当你期初的分析合理，后面的变动也将在逻辑上变动，相信代价已经不会那么大了。这其实也体现了系统的扩展性。
需求分析，是一个项目提出方和承担方相互沟通的过程，一方是系统的使用者，一方是系统的制造者，在系统制造过程中，只有双方相互配合，共同对系统进行设计才能最后达到使用的要求。客户是业务上的熟悉者，对业务流程有非常清晰的了解，但是，对于软件需求方面的描述是不了解的，他们所能提供的只是他们最终要达到的功能，但是，这其中包含的业务流程是非常复杂的。我们拿到客户需求后，应该根据功能、流程进行初步的设计，构造出业务流程图，再让客户进行评审，提出业务流程上不对的地方进行修改。这样来回的交流，最终才能取得较全面的需求，并减少后期的修改。