需求分析师工作总结（精选8篇）

需求分析师工作总结 篇1

职责：

1、负责与客户沟通，了解客户需求，将客户需求转化成需求文档；

2、帮助进展需求调研，需求分析并收集、整理客户反应的问题和需求；

3、负责需求变更的`跟踪，确保需求变更的可追述性；

4、领导安排的其他任务。

任职要求：

1、计算机相关专业，具备计算机、通信、网络等相关学问；

2、有软件开发阅历者优先或需求分析阅历者优先；

3、了解软件需求猎取与分析技术和治理方法；

4、思维清楚，规律性强，良好的沟通力量，擅长发觉和精确把握需求；

5、具备良好的责任心和团队精神，有较强的文档编写力量。

需求分析师工作总结 篇2

xx年，转瞬即逝，但回想刚到客户现场时的不知所措，却好像又过去了很久一样。在这一年的时间里，我们经历了酸甜苦辣，但是，最让人值得骄傲的是，我学习到了很多项目管理和质量控制的知识，同时在平时的工作中得到应用，并积累了一些相关经验。下面是我对过去一年的工作经验总结和自认为好的一些实践，请领导评审。

项目管理分为九大知识领域，分别是：范围管理、时间管理、成本管理、质量管理、人员管理、沟通管理、风险管理、采购管理和综合管理。

范围管理最应该关注的是：防止不必要的变更。但是目前项目组在开发的过程中，不能详细而明确的说明用户需求，让用户在程序开发之前进行需求确认，使得后期不可避免的发生所谓的变更，而实际上也许是项目组不能实现用户的需求，用户没有别的办法，只能采取另一种实现方式的变更，或者程序实现了的并不是用户真正的需要，导致uat测试阶段大量的变更。我们一直以来的想法就是“抓两头，控中间”，所以，需求阶段建议采用原型法，在用户无法提出明确需求的条件下，尽量引导、还原用户需求，且需求一定要业务部门确认。另外，据我的经验，项目组在制定项目计划的时候，一定要把项目组所有的任务都包含在进度表里，包括文档的评审、代码检查、上线会议等管理及沟通工作。事实证明，如果按照行方的过程要求，把任务尽量全面的列入进度管理表中，到了对应的时间点，也不会忘记此项活动的执行，因此，相对能比较好的执行要求的过程。

需求分析师工作总结 篇3

一、学会了怎样编写测试需求更规范

首先从前面一个pcft银行按揭贷款管理系统中选总结了一些经验，进入qc程序里，新建需求前，要和组内统一一下注意事项，使全组的需求编号看起来更统一。遇到分歧时，向别人请教，需求描述不是测试用例，不要一步一步，只要写出此项需求有什么功能就行了，写的太繁琐误让别人以为是测试用例呢。产品名称，已审阅，类型过，直接覆盖状态都要填写清楚，优先级要根据优先级的分类来选择。经过后来的开会，评审让我对需求规范长了不少的经验。pcft银行按揭贷款管理系统完成后，又进行了家财通3这个项目，我会把以前总结的经验用来认真写这个项目的需求的。

二、学会了怎样编写测试用例更规范

首先，由pcft银行按揭贷款管理系统工程，从测试用例的编写到交叉执行，到后来的用例评审，让我深知如果需求没写好，后面的反复工作将会是个大麻烦。从需求到用例这种反复的工作量真是很麻烦，所以我们下次再写的.时候一定要注意测试用例要覆盖所有的需求，同时用例也是根据需求来写的，所以需求一定要分得仔细，这样下面的用例才好写。

最后，通过会议评审和开项目总结大会，并通过qc报告给负责人。现在开始熟悉家财通3项目，虽然这个项目工作量大，难度相比上面一个更大，但有以前项目的经验，相信问题都能被好好的解决。

此外，在这周里我还用日语写测试需求，用日语写测试用例。已经初步了解了该项目的内容和性质，在以后的时间里我会更加努力学习，使自己快速进入工作。

需求分析师工作总结 篇4

职责：

1、负责公司的软件工程需求分析工作，准时确认调研记录，准时梳理业务需求相关文档；

2、负责与用户进展需求争论后对用户需求进展补充、细化与修改，进而渐渐明确需求，编写有效的需求规格说明书；

3、负责或参加对客户的需求确认工作、对工程组相关人员的.需求讲解和答疑的工作；

4、负责需求评审工作，并不断完善；

5、跟踪需求在实际开发过程中的偏差或变更；

6、参加编写技术方案、需求分析、具体设计、操作手册等相关文档的撰写；

7、参加整个产品公布流程，与研发及测试团队一起保证最终产品的胜利公布。

8、担当工程或部门交办的其他工作。

任职要求：

1、大学专科以上学历，计算机相关专业；

2、良好的沟通、协调力量；

3、有较强的需求文档写作和PPT制作力量；

4、具有良好的团队精神，积极进取，思维清楚灵敏，规律分析力量强。

需求分析师工作总结 篇5

职责

1、依据产品规划或者工程要求，开展需求调研，完成调研报告、需求规格说明书及系统设计文档；

2、负责分析用户需求，完成工程产品方案设计、流程图、原型等相关工作；

3、向开发工程师供应询问指导，解释业务需求，向用户汇报系统功能；

4、整理和分析客户需求，对其分类汇总和实现预估，提出需求分析报告和实现规划要求；

5、参加整个产品开发流程，负责需求开发与跟踪，完成需求变更的掌握与治理，与开发测试团队一起保证最终产品的正确定位；

6、指导测试工程师依据测试需求，组建测试环境的工作。

岗位要求

1、本科以上学历，2年以上软件需求分析阅历，胜利参加过大型产品工程的.需求分析；

2.熟识需求调研的方法，有较强的业务流程及业务模型分析设计力量，丰富的用户沟通阅历，能快速把握需求的核心要点；

3.熟识电力相关业务学问，对泛在电力物联网有肯定熟悉，熟识当前电力生产环节，尤其是配网规划、运行调度、用电效劳、电力交易等。具有较强的学习和创新力量，问题推断和决策解决力量，跨部门、跨领域沟通协调力量、工程规划与管控力量；

4、有电网或能源行业从业经受者优先。

需求分析师工作总结 篇6

一、20xx年工作内容总结

1、完成了广东培训平台的设计，并进行了后续的验收、优化，以及项目实施的跟进。

2、在广东平台基础上向省培平台的改版设计、优化，以及项目实施的跟进。

3、进行适用于非学历培训的平台改版设计。

4、东北师大免费师范生网上学—台的问题跟进、处理、优化工作。

5、商务平台需求修改的跟进。

6、进行了明德特色平台需求的初步分析及报价。

7、教育部杂志社平台改版需求（需求分析后已交予程老师等待确认）。

8、老培训平台的新需求接收、整理、安排、跟进问题。

9、处理业务部门发来的问题邮件1800余封。

10、接收并安排用户提出的平台搭建申请242个。

11、接听教务、教学、客服、办事处打来的各种电话，并予以解答、处理。

二、工作中存在的不足及自我反思

1、心理承受能力差，当多个项目的事情同时压过来时，容易手忙脚乱，在做一件时的时候想着另一件事，影响效率和质量。针对此类问题，第一时间不应该是忙乱，而是应该结合业务的紧急情况，确定事情的优先级，踏踏实实的干完一件事，再干另一件事。

2、技能水平有待提高，例如在看到别的同事设计的demo模型时，感觉自己设计的太简单，没有美化，也缺少灵动性。应该继续深化自己对demo模型绘画工具的使用水平。将demo做的更精细，更便于ui制作页面，更便于开发理解需求。

三、对部门及中心的建议

1、规范各部门的工作流程，除了常规问题的处理流程外，能够有一套紧急问题处理流程。避免有紧急问题时，因为某一环节的人员不在单位而导致事情的搁置。

2、规范问题处理机制，确定什么类型的问题可以技术中心自行处理；什么类型的问题必须向领导汇报并得到确认后才能处理；什么类型的问题需要向业务部门及客户通报后得到确认才能处理。

3、针对发现问题、处理问题的追责制度，避免大家没有解决问题的紧迫性和积极性或者推卸责任，提高问题的解决效率和质量。

4、技术中心发展迅速，但导致人与人之间不认识或不了解，甚至会发生一些误会，不利于之间的合作。建议开展一些户外拉练，加强同事之间的合作互助。

5、能够有一个很好的技术中心文化、氛围，让大家在开心的氛围内工作，有共同的目标去奋斗。

6、考评结果反馈表中，有一条是感觉部门中最差的是谁。这类问题如果漏出，容易造成同事之间的不和谐，建议取消这类问题。

7、进行一些员工培训，使员工有更多的成长进步。

需求分析师工作总结 篇7

需求分析是项目开发的基础，基础打的牢不牢直接关系到后面所有的工作，是项目实施成败的关键

项目经理博客

总体上说，我们的需求分析是做了，但是做得很不够，我们做的需求只解决了我们能做出这样的项目，但是没有解决这样的项目是不是真就是客户想要的。造成这种状况的原因主要是下面几个情况：

客户本身说不清楚

文物网是这样，中彰国际更是这样，但是这不能怪客户，毕竟客户在软件方面的知识要少的多，也没有相关的经验，可能心里只有一个想要的软件的轮廓，于是可能会要求我们去替他们来完整这个轮廓的细节，而我们的能力、我们能否真正站在客户角度去搜集和整理这些需求，就决定了这个需求的完整性和有效性。

需求自身经常变动

随着客户对这个项目越来越深刻的理解，那么可能他的需求也会随之改变，这些变化的可能性越大项目风险就会越大，我们在需求分析的时候就要充分考虑到哪些需求是相对固定的需求，哪些可能会是产生变动的需求，考虑到他的可变性，这样设计功能和数据库的时候不致因为后面的变动而影响整个工程。

分析人员或客户理解有误

毕竟，不是每个分析人员都是专业而合格的，为避免这种情况的发生，需求分析必须要有审核制度，公司自己内部要审核一遍，客户再审一遍，提出意见，修改后双方共同评审签字，确认。

由此出现的问题：

a) 需求分析过于笼统，只关注到面上，没有关注到点上，开发出来的东西在具体的细节上和客户的理解有误差，并且无法严格界定是否属于需求变更。中彰的方案就是这样的。

b) 需求报告只求我们这方评审通过，不去关心客户的评审，认为只要客户签字认可就行。虽然签字认可能够给日后出现问题时划清我们的责任，但是不能保证使项目实施成功。

c) 需求分析中含有技术实施上有难度的功能，一味的求全和盲目按照客户的设想，受客户影响过大，毕竟，很多时候，客户的想法在实际实施过程中是不现实的，或者可以有更为简便的方法来替代的。如中彰国际的在线交易功能，后台大批量邮件群发功能。

d) 对双方已经确定的需求，实现以后并不适合客户使用，需要按照变更手续执行的时候，客户可能会纠缠，提出“你们是专业人士，你们应该事先能提醒我们可能会出现这种问题”并以此来把责任推给我们，而我们又不好完全按照变更手续执行，因为可能激化双方的矛盾，比如508的批量处理功能，因为属于人事管理比较专业的细节问题，需求分析师开始没有对客户业务熟悉到如此细致的地步，而客户也没有过多关注这些细节，导致软件的某些功能不合用，较为繁琐，而重新按着客户的意见修改的话工作量比较大，导致成本增加、工期延长。

e) 项目的成熟度受客户预算的限制。大部分客户在项目投入上都是有预算的，在成本有上限的前提下，项目的功能设计（软件的成熟度）方面必然受一定影响，毕竟功能越多越完善，相应的开发成本就越高。这种功能上的不完善需要事先告知客户并得到理解。

f) 此项工作的反复造成思想上的倦怠，使需求分析最后虎头蛇尾。需求分析是一项繁琐枯燥的工作，需要和客户之间不断的商讨、确认和反复，另外由于大部分的客户虽然安排专人负责这项工作，但是该人并不只做这项工作，特别当他被很多其他的事情缠身的时候，而无心细看提交过去的需求报告的时候，他很可能会给你一个错觉，让你认为他已经真正的理解并认可了你的设计。结论

a) 需求分析是整个项目管理中需要重点控制的几个关键节点之一，首先思想上一定要重视。

b) 需求分析报告的编写者要参与到需求的搜集工作中，准确领会客户的意图，并转化成软件能够实现的功能。对于说不清楚需求的客户，要善于问关键问题，引导客户提出自己的需求。可以采取的措施是事先编制一个问卷调查之类的文档，详细列举需要客户回答的问题，以便防止遗漏。

c) 需求报告的编写者要能够对客户需求进行深入分析，区别出哪些需求存在日后变更的可能，哪些需求属于相对固定的，哪些需求能够实现，哪些需求需要变通才能实现，以便于指导后面的功能设计。

d) 需求分析报告对功能细节的描述不能有歧义，描述一定要全面、准确，防止开发方和客户只见对同一个问题有两个截然不同的理解。可以通过评审，用大家的力量来避免这种情况发生

e) 需求报告的每个关乎功能的描述都要让客户明白和理解，客户在理解之上的确认才能够保证日后一旦出现问题不致出现双方互相推托责任纠缠不清的情况。

f) 需求报告一定要经过一个有技术人员和业务人员参加的评审，要充分发挥团队的力量，重视每个人的才智，一个模块一个功能的逐一的过，让大家来共同找出需求报告里不合理的、有歧义的、不完善的、遗漏的等等问题

g) 帮助客户去理解提交给他的需求分析报告而不是只等签字，对于有能够用好几种方式实现的功能，尽量做到能让客户去比较和选择。不要让客户对报告中的部分产生歧义。只有客户对报告的完全的理解，才能在日后客户提出的修改被认为是需求变更的时候能够得到客户的理解

h) 最后，需求分析报告一定要双方共同签字确认

需求分析师工作总结 篇8

职责：

1.参加产品/系统的规划和设计，负责工程的用户需求调研，需求争论，需求梳理，需求分析等工作；

2.负责工程进展前期调研，编写调研报告和工程解决方案；

3.负责编写具体需求规格说明书，用户手册，培训资料等；

4.对外负责与客户沟通需求，对内协作工程组的.需求讲讲解明；

5.产品测试验证；

6.协作工程经理完成其他事项；

岗位要求：

1.计算机相关专业，本科以上学历。

2.拥有1-3年软件需求分析阅历，尤其是零售行业阅历；

3.熟识使用相关的业务需求分析，设计工具，如Visio,Office等；

4.具有良好的英文读写力量，较强的语言表达沟通力量，文档撰写力量；

5.具有较强的用户需要推断，引导，掌握力量；

6.需有较强的团队协作精神；

7.有零售行业进销存产品阅历者优先考虑，有开发阅历者优先考虑，懂粤语者优先考虑；