20xx-09-16 作者：Neo.Yan 来源：Neo.Yan 的blog

1、需求分析前的准备

在软件开发过程中，需求分析可以说是核心任务之一，就像一支将要远航的船队，要在指定时间内到达目录地，他们需要一条正确的航线，才能到达目的地，如果航线有误，他们将会误时到达，或是不回到原位将永远到达不了，这么重要的东西，但在国内很多团队中缺少，虽然我也做了一些，但在项目完成的时候，回头看看，其实我们做了很多不必要的事，浪费了很多时间、人力和物力，为保证在今后的开发中减少这些错误的发生，现将一些问题记录下来。 为了了解系统需求，先可以从概要式的需求着手，再细化需求，需求分析必须拟定文档，在写文档之前我们必须做好寻求分析的范围，总结为以下几点：

1.1要做一个什么样的系统

这个不说，我想做软件开发的人都知道，拟定这个后，一切才可以扩展开，比如我们要做一个B2C的商城，要卖母婴用品，知道了这些，我们就可以找现在网站有的B2C网站做参考，分析系统构架，系统功能等。

1.2系统将要在什么样的环境下进行

我上次经历的一个系统，就是要用asp.net重新发一个B2C商城，但有一些前提条件，以前公司有网站，是用java+MYSQL开发的，但我们开发的新系统必须兼容以前的数据，如客户信息，商品信息，还有一些资源信息，并且还要兼容Google,baidu收录的地址路径，还有与原ERP的通讯等条件，这样让我们的开发很受限制，这些需求就是这样，你无法改变，所以在设计新系统的同时你必须考虑，要花时间去了解以前系统的功能，接口等，如果不了解，等你把新系统开发完了才发现系统脱离了公司原有的业务流程，让公司无法运作，那就代表你开发的系统根本没有价值，我想这不是我们想要的结果。

1.3要解决哪些问题

开发出来软件系统就是为了解决客户需求的，一个B2C网站就是卖商品，主要由客户、商品、购物车、定单组成，将这些核心的功能定义好，我想其它的意外都不会太影响到整个系统的进程。

1.4将来可能会有哪些变化

面对将来的发展，我们也许不能完全考虑到，但与公司的战略发展，可以提前考虑些，能想到多少就想多少，多多益善，我们开发一个系统不是只满足当前的需求，如果眼光只放在眼前，那么你这个系统很快就会被淘汰，功能也许不需要现在实现，但接口总得留下吧，不然想改进都是很困难的事，如果一个稍微的小需求都要动系统构架，我想这个系统会越来越不稳定，作为系统分析师，这块也是至关重要的。

1.5系统可以维持任务的周期是多少

系统周期与公司战略发展是紧扣的，一个系统的功能不可能随着社会的变化，能一直满足市场需要的，在设计系统的时候，可以了解一下公司的战略发展，比如公司三年之内要做成什么样，客户多少，网站浏量，可以做下评估，这样就考虑系统构架的问题，你开始就准备构架一个大胖子，但现在需求简单，在实际的运行中，速度缓慢，其实你构架越

复杂，系统运行就越缓慢，虽说现在很多大系统运行的都很好，但要想想，人家服务器，网络构架是什么样的，你不可能让你的系统一线就有这么好的环境，就算有，那成本也太大了，一般的公司也吃不消。

1.6系统分几个阶段实施

在开发初期，我们不可能将系统所有的功能都能完成的很好，为了加快开进度，为了系统能尽早上线，我们得像建楼一样，分阶段进行，分段实施，如果我们现在只是要在网上卖商品，那我们就得把客户管理、商品管理、购物车、定单管理这几大块实现，把一个系统根基打好，谁都想让自己的系统变成最强大的系统，但这个想法几乎是不可能完成的，如果我们把根基打好了，再在上面加以改进，添砖添瓦，根据客户或市场的需要来完善，我想这个系统就会慢慢变成一个成功的系统，对于B2C网站来说，能完成商业的需要，能让公司的流程走顺，那就是个好系统，没有最好的系统，只有最适合的系统。

分阶段实施，可以有节约成本，也可以加快实施速度，不管是作为公司的管理人员还是开发人员，能尽快看到成果，会提高信心，可以举个例子，在设计一个B2C商城的时候，我们除了客户管理、商品管理、购物车、定单管理外，还要加入广告管理、促销管理、CPS、统计管理、用户积分、虚拟币、礼品、物流、接口等一些功能，如果开发周期只给两个月，四个人，从系统设计到系统上线，怎么做?怎样如期完成呢？如果你的团队都没接触过B2C这样的系统，开发起来是很难度的，在这样的情况下，我们必须分段实施，抓主干，把核心的东西完成了，系统可以上线，虽然没有理想的那么强大，但最少它能赚钱，再一个两个月可以把客户管理、商品管理、购物车、定单管理这几块主要的功能完善，公司业务可以进行，后面的功能虽然很有必要，但也可以分个先后，系统上线了，能给大家看到东西，能用用，建议也会多些，对于系统的优化改进，这个是无止尽的，如果没有这些基本的东西，天天都会有人在你耳边叫，你们什么时候上线呀，做了这么久，做的怎么样了，让你的团队心里承受着很大的压力，就算你在两个月内把开发任务完成了，那你的测试通的过吗，功能越多，问题越多，在后期维护问题越多，最后烦了，没办法，重构，那样不是亏大了。

1.7确认第一阶段解决那些问题

在一个新的环境中，一个新的团队，你说要在某一时间段里完成什么样的系统，你怎样做到让领导相信你，让公司相信你，一个大一点的软件系统，少则几个月，再多一点就一年半载，他们能等吗，再说了他们不懂代码，不会天天跟你的屁股后面问你，系统怎么样了，做了哪些，就算这样，我想你也进了疯人院了，所以我们做系统要打好第一枪，这样才会得到更多人的支持和理解，如果你不能理解，可以去看看商殃变法中的《徒木立信》的典故。

至于软件第一开发第一阶段要做哪些事，这个要根据一个系统的核心功能去了解，只有建立好了框架，不要太急于求成，没什么好处，把根基打好了，再想怎么包装，都不是件难事。

1.8系统开发团队由哪些人组成

一个好的团队，必定是发挥了团队中每个人的优势，在开发团队中，不是你技术能力强，你就是最有价值的人，我相信在开发团队里没有一个从头到尾都能支持的能人，不是不没，是我是觉得不可能存在，也许我么说有些人不服，其实我这么说也有我的理由，一个人也许有机会经历团队中的每个环节，并且都能深入，但绝对不是一个机会，如果有，那就是一个人的开发，一个人的开发我想也不能叫团队，有时候，一个人什么都能做，多了一个人，什么都做不好，但面对大的项目，不得不进行团队合作。

我所在的公司，我进去的时候，接到项目任务，我开始还有些心虚，因为有些工作我也没接触过，但又不得不去做，但我很意外的时候，我们的团队中有一位项目助理，她的出现让我们的团队协调管理得到了很好的实施，计划任务，可以做到很好的按排，但跟踪管理，我能收集分配，但指定到人后，我很难看到进展的情况，因为自身还有很多的工作，开始我部署了项目管理系统的，收集需求和BUG，也指定到人，但反馈往往不及时，因为我有时候隔一天才上去看，

后来我将这项目工作交给了项目助理，让她去管理这些，我发现她做的很好，她每天和我只花几分钟的时间做核对，出现意外情况我就出现解决，她的出现把我和团队中的每个开发人员的工作连接起来，让项目管理得以顺利的实施。

开发团队具体由哪些人组成，这是要根据公司实力，项目进度和项目大小来定的，现在说几个工作职则，可来灵活分配一下：

项目经理：对项目的决策性问题进行定位，一个功能做与不做，领导说的算

构架师：控制技术问题，解决技术难题，对分配下来的任务进行分析、评估，反馈给项目经理，再进行确定

项目助理：记录团队会议内容，协调工作中的日常事务

开发组长：调配开发组员，辅助组内开发人员并对成员工作进行监管，一般由主程担任

开发人员：负责编写代码，按需求完成任务

测试人员：对功能进行测试

如果这里的每项目工作按排到个人，我想开发团队的协调管理最好。

1.9系统运行环境是什么样的

在系统构架时，根据需要定义好，系统构架、程序环境、网络环境，如考虑分布式存储，日均访问量、系统安全、成本预算等。

asp.net的开发成本是要比java的开成本低的。

Sql server的运营成本是要oracle低的，但oracle在大型数据处理上要优于SQL Server,如果是SNS站我觉得上Oracle会好些。

选择什么样的环境，在没有特定要求的情况下，根据团队的现状去考虑我觉得就差不多了。

我们有了目的地将要远航，那么就得需要航海图、船、船长、舵手、水手、水和食物，虽然这样我们能保证100%完成任务，因为大海中的意外谁也不会知晓，但我们理想的是我们能安全到达，如果条件不允许，就算我们知道目的地在哪，出了海，我们将面对是一场艰辛冒险旅程。

2、收集需求

需求的收集是个很繁琐的过程，收集的不够，开发过程中变化会很多，特别是你上了一个演示版本后，开始别人一点意见都没，一看你的演示，你就意见一大堆，这样的问题我想在很多项目中都出现过，所以先在收集需求的时候要和客户或相关部门一一确认，我们考虑需求要从种两种角度去考虑，一种是用户角度，另一种是开发者角度，所以在谈需求时，必须边聊边记，把所谈的话记录整理，如果怕遗漏，可以录音，然后将采用文档的方式表达出来，将提出的需求加以分析，做下技术评估，如果有特别的难题可以提前让开发人员做技术预研，在做评估后，需要分段实施的，就做好规划，然后和提需求的人员确认，需求文档的功能可以多写点，根据企业的发展，能考虑的都考虑，这样可以在系统构架时，定位系统的生命周期时，给以更多的参考，在需求定出阶段后，我们得把要马上实施的功能放在当前，加以强化、细化，反复的进行，条件允许的时候应该做些Demo来确认。

第二篇：做需求分析一点心得

1、需求分析前的准备

在软件开发过程中，需求分析可以说是核心任务之一，就像一支将要远航的船队，要在指定时间内到达目录地，他们需要一条正确的航线，才能到达目的地，如果航线有误，他们将会误时到达，或是不回到原位将永远到达不了，这么重要的东西，但在国内很多团队中缺少，虽然我也做了一些，但在项目完成的时候，回头看看，其实我们做了很多不必要的事，浪费了很多时间、人力和物力，为保证在今后的开发中减少这些错误的发生，现将一些问题记录下来。

为了了解系统需求，先可以从概要式的需求着手，再细化需求，需求分析必须拟定文档，在写文档之前我们必须做好寻求分析的范围，总结为以下几点：

1.1要做一个什么样的系统

这个不说，我想做软件开发的人都知道，拟定这个后，一切才可以扩展开，比如我们要做一个B2C的商城，要卖母婴用品，知道了这些，我们就可以找现在网站有的B2C网站做参考，分析系统构架，系统功能等。

1.2系统将要在什么样的环境下进行

我上次经历的一个系统，就是要用asp.net重新发一个B2C商城，但有一些前提条件，以前公司有网站，是用java+MYSQL开发的，但我们开发的新系统必须兼容以前的数据，如客户信息，商品信息，还有一些资源信息，并且还要兼容Google,baidu收录的地址路径，还有与原ERP的通讯等条件，这样让我们的开发很受限制，这些需求就是这样，你无法改变，所以在设计新系统的同时你必须考虑，要花时间去了解以前系统的功能，接口等，如果不了解，等你把新系统开发完了才发现系统脱离了公司原有的业务流程，让公司无法运作，那就代表你开发的系统根本没有价值，我想这不是我们想要的结果。

1.3要解决哪些问题

开发出来软件系统就是为了解决客户需求的，一个B2C网站就是卖商品，主要由客户、商品、购物车、定单组成，将这些核心的功能定义好，我想其它的意外都不会太影响到整个系统的进程。

1.4将来可能会有哪些变化

面对将来的发展，我们也许不能完全考虑到，但与公司的战略发展，可以提前考虑些，能想到多少就想多少，多多益善，我们开发一个系统不是只满足当前的需求，如果眼光只放在眼前，那么你这个系统很快就会被淘汰，功能也许不需要现在实现，但接口总得留下吧，不然想改进都是很困难的事，如果一个稍微的小需求都要动系统构架，我想这个系统会越来越不稳定，作为系统分析师，这块也是至关重要的。

1.5系统可以维持任务的周期是多少

系统周期与公司战略发展是紧扣的，一个系统的功能不可能随着社会的变化，能一直满足市场需要的，在设计系统的时候，可以了解一下公司的战略发展，比如公司三年之内要做成什么样，客户多少，网站浏量，可以做下评估，这样就考虑系统构架的问题，你开始就准备构架一个大胖子，但现在需求简单，在实际的运行中，速度缓慢，其实你构架越复杂，系统运行就越缓慢，虽说现在很多大系统运行的都很好，但要想想，人家服务器，网络构架是什么样的，你不可能让你的系统一线就有这么好的环境，就算有，那成本也太大了，一般的公司也吃不消。

1.6系统分几个阶段实施

在开发初期，我们不可能将系统所有的功能都能完成的很好，为了加快开进度，为了系统能尽早上线，我们得像建楼一样，分阶段进行，分段实施，如果我们现在只是要在网上卖商品，那我们就得把客户管理、商品管理、购物车、定单管理这几大块实现，把一个系统根基打好，谁都想让自己的系统变成最强大的系统，但这个想法几乎是不可能完成的，如果我们把根基打好了，再在上面加以改进，添砖添瓦，根据客户或市场的需要来完善，我想这个系统就会慢慢变成一个成功的系统，对于B2C网站来说，能完成商业的需要，能让公司的流程走顺，那就是个好系统，没有最好的系统，只有最适合的系统。

分阶段实施，可以有节约成本，也可以加快实施速度，不管是作为公司的管理人员还是开发人员，能尽快看到成果，会提高信心，可以举个例子，在设计一个B2C商城的时候，我们除了客户管理、商品管理、购物车、定单管理外，还要加入广告管理、促销管理、CPS、统计管理、用户积分、虚拟币、礼品、物流、接口等一些功能，如果开发周期只给两个月，四个人，从系统设计到系统上线，怎么做?怎样如期完成呢？如果你的团队都没接触过B2C这样的系统，开发起来是很难度的，在这样的情况下，我们必须分段实施，抓主干，把核心的东西完成了，系统可以上线，虽然没有理想的那么强大，但最少它能赚钱，再一个两个月可以把客户管理、商品管理、购物车、定单管理这几块主要的功能完善，公司业务可以进行，后面的功能虽然很有必要，但也可以分个先后，系统上线了，能给大家看到东西，能用用，建议也会多些，对于系统的优化改进，这个是无止尽的，如果没有这些基本的东西，天天都会有人在你耳边叫，你们什么时候上线呀，做了这么久，做的怎么样了，让你的团队心里承受着很大的压力，就算你在两个月内把开发任务完成了，那你的测试通的过吗，功能越多，问题越多，在后期维护问题越多，最后烦了，没办法，重构，那样不是亏大了。

1.7确认第一阶段解决那些问题

在一个新的环境中，一个新的团队，你说要在某一时间段里完成什么样的系统，你怎样做到让领导相信你，让公司相信你，一个大一点的软件系统，少则几个月，再多一点就一年半载，他们能等吗，再说了他们不懂代码，不会天天跟你的屁股后面问你，系统怎么样了，做了哪些，就算这样，我想你也进了疯人院了，所以我们做系统要打好第一枪，这样才会得到更多人的支持和理解，如果你不能理解，可以去看看商殃变法中的《徒木立信》的典故。

至于软件第一开发第一阶段要做哪些事，这个要根据一个系统的核心功能去了解，只有建立好了框架，不要太急于求成，没什么好处，把根基打好了，再想怎么包装，都不是件难事。

1.8系统开发团队由哪些人组成

一个好的团队，必定是发挥了团队中每个人的优势，在开发团队中，不是你技术能力强，你就是最有价值的人，我相信在开发团队里没有一个从头到尾都能支持的能人，不是不没，是我是觉得不可能存在，也许我么说有些人不服，其实我这么说也有我的理由，一个人也许有机会经历团队中的每个环节，并且都能深入，但绝对不是一个机会，如果有，那就是一个人的开发，一个人的开发我想也不能叫团队，有时候，一个人什么都能做，多了一个人，什么都做不好，但面对大的项目，不得不进行团队合作。

我所在的公司，我进去的时候，接到项目任务，我开始还有些心虚，因为有些工作我也没接触过，但又不得不去做，但我很意外的时候，我们的团队中有一位项目助理，她的出现让我们的团队协调管理得到了很好的实施，计划任务，可以做到很好的按排，但跟踪管理，我能收集分配，但指定到人后，我很难看到进展的情况，因为自身还有很多的工作，开始我部署了项目管理系统的，收集需求和BUG，也指定到人，但反馈往往不及时，因为我有时候隔一天才上去看，后来我将这项目工作交给了项目助理，让她去管理这些，我发现她做的很好，她每天和我只花几分钟的时间做核对，出现意外情况我就出现解决，她的出现把我和团队中的每个开发人员的工作连接起来，让项目管理得以顺利的实施。 开发团队具体由哪些人组成，这是要根据公司实力，项目进度和项目大小来定的，现在说几个工作职则，可来灵活分配一下：

项目经理：对项目的决策性问题进行定位，一个功能做与不做，领导说的算

构架师：控制技术问题，解决技术难题，对分配下来的任务进行分析、评估，反馈给项目经理，再进行确定

项目助理：记录团队会议内容，协调工作中的日常事务

开发组长：调配开发组员，辅助组内开发人员并对成员工作进行监管，一般由主程担任

开发人员：负责编写代码，按需求完成任务

测试人员：对功能进行测试

如果这里的每项目工作按排到个人，我想开发团队的协调管理最好。

1.9系统运行环境是什么样的

在系统构架时，根据需要定义好，系统构架、程序环境、网络环境，如考虑分布式存储，日均访问量、系统安全、成本预算等。

asp.net的开发成本是要比java的开成本低的。

Sql server的运营成本是要oracle低的，但oracle在大型数据处理上要优于SQL Server,如果是SNS站我觉得上Oracle会好些。

选择什么样的环境，在没有特定要求的情况下，根据团队的现状去考虑我觉得就差不多了。

我们有了目的地将要远航，那么就得需要航海图、船、船长、舵手、水手、水和食物，虽然这样我们能保证100%完成任务，因为大海中的意外谁也不会知晓，但我们理想的是我们能安全到达，如果条件不允许，就算我们知道目的地在哪，出了海，我们将面对是一场艰辛冒险旅程。

2、收集需求

需求的收集是个很繁琐的过程，收集的不够，开发过程中变化会很多，特别是你上了一个演示版本后，开始别人一点意见都没，一看你的演示，你就意见一大堆，这样的问题我想在很多项目中都出现过，所以先在收集需求的时候要和客户或相关部门一一确认，我们考虑需求要从种两种角度去考虑，一种是用户角度，另一种是开发者角度，所以在谈需求时，必须边聊边记，把所谈的话记录整理，如果怕遗漏，可以录音，然后将采用文档的方式表达出来，将提出的需求加以分析，做下技术评估，如果有特别的难题可以提前让开发人员做技术预研，在做评估后，需要分段实施的，就做好规划，然后和提需求的人员确认，需求文档的功能可以多写点，根据企业的发展，能考虑的都考虑，这样可以在系统构架时，定位系统的生命周期时，给以更多的参考，在需求定出阶段后，我们得把要马上实施的功能放在当前，加以强化、细化，反复的进行，条件允许的时候应该做些Demo来确认。

第三篇：需求分析一点心得

需求分析一点心得

20xx年8月15日，我休假回到公司，四川分支crm行业部进行了四维分工，我分在了需求组。组长徐茜之前已经与我沟通过需求组具体的工作明细，但自己心里还是很担心，是否能做好这份新工作，毕竟自己以前都是做的开发工作，接触的都是代码，很少编写文档；不过我还是很高兴，新的工作具有挑战性，可以更好的锻炼自己各方面的能力；

首先我查看了一些以前同事写的需求分析文档，从中积累一些好的经验，比如如何描述需求要点，如何绘制流程图等；

然后给自己制定了工作要求，明确用户需求、不遗漏需求点、对需求进行分析、提出自己的意见和建议、输出需求规格说明书给开发人员；就这样我井井有序的开展着自己的新工作，本以为自己已经做的够细致了，几周下来还是出现了不少问题。需求规格说明书写的不够细、自己写的需求规格说明书开发人员看后理解的与需求原意不一致、测试上线开发点不齐全、设计需求时未考虑到后期的维护使维护工作增多、需求不能按照之前与用户指定的时间上线等；对于这些问题，自己进行了深入的思考，如何避免这些问题的出现；深思后发现大家好像缺乏沟通，需求的每一个环节没有贯穿起来，每个环节似乎都断开了，不像以前一个需求自己与用户沟通、自己开发、自己测试、上线，整个环节都在同一个人的掌控中，时间也是由自己安排；

作为需求分析负责人，自己是不是应该贯穿整个需求，而不仅仅只是把输出需求规格说明书作为一个需求分析工作完成的目标呢？

首先沟通，与用户沟通，明确需求要点，不仅需要聆听用户的需求说明，还要懂得在用户已说明的基础上进行拓展，发掘客户没有讲出来的潜在需求。在已有业务的基础上进行模拟业务流程，分析业务是否走的通并且有无逻辑上不合理的地方。发现问题，及时与用户沟通，及时修改需求；与开发组长沟通，明确开发人员和上线完成时间；与开发人员沟通，使开发人员知晓需求要点，自己更好的完善需求分析规格说明书；与测试人员沟通，需求测试要点，判断需求上线的标准；与维护人员沟通，对应需求的维护工作如何开展等；

其次就是协调，开发时间的协调，如果用户同时有几个需求都要求比较紧急，那么需要我们协调用户是否能将这些都很紧急的需求排一个优先级；需求要点协调，如果两个需求都要修改同一个模块的代码，那么为了保障程序版本问题，需要协调将两个需求开发时间错开；以及当维护人员发现模块BUG时，需要协调用户发起对该BUG的优化；

有时还需要引导，引导用户走向有利于系统开发的轨道上，用户的一些需求，有些对整个业务其实可有可无，如果在实现起来很麻烦的话，可以引导用户取消这个需求，避免对系统大的改造影响了其他正常的业务，也浪费了开发人员的时间。如果系统本来就已经具备的功能，那么就要引导用户复用该功能，使系统可以最大程度的复用原来的功能。提高系统的代码的使用率，同时提高我们的工作效率。

最后就是完善，完善我们编写的需求规格说明书，可以使用需求用例、业务逻辑图、办理流程图、表格、界面图片等对需求进行说明，使需求规格说明书简单易懂，避免歧义；

这一年的需求分析工作，使自己对该工作有了更多、更深的认识；不仅要认真，还要有细心、耐心、有责任感；不仅要考虑当前的需求，还要分析系统已经具备的和将来需要支撑的；希望通过自己的努力，能将需求分析工作做的更好；