需求分析个人总结精选 .doc

需求分析个人总结 文件编号：MAC-SWE-TMP-17 密级：■ 保密 □ 通用 需求分析总结报告 [模板] Requirement Analysis Report [Template] 本程序属MAC公司所有，未经书面许可， 不得以任何形式复印或传播。 修 改 记 录 文件编号： 密级：■ 保密 □ 通用 需求分析总结报告 该报告由开发团队编制作为需求分析阶段的结论。其概述了需求分析的结果并建立开始概要设计的基线。建议内容如下： 1．引言 必填 1．1 编写目的 说明编写这份需求规格说明书的目的，并指出预期的读者。 1．2 背景 说明： a) 待开发的软件系统的名称； b) 本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络； c) 该软件系统同其他系统或其他机构的基本的相互来往关系。 1．3 定义 列出本文件中用到的专门术语的定义和外文首字母组词的原词组。 1．4 参考资料 列出用得着的参考资料，如： a) 本项目的经核准的计划任务书或合同、上级机关的批文； b) 属于本项目的其他已发表的文件； c) 本文件中各处引用的文件、资料，包括所需用到的软件开发标准。 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源 2．复用建议 关键复用候选项和系统全面体系概念。 3． 操作概要 对需求分析阶段执行活动所产生的系统和操作概念的更新。 a) 更新操作方案。 b) 操作模型，包括在操作的每种模式、次序和类型中将处理的数据的容量和频率。 必填 简单的用户手册 c) 更新输入、输出和信息说明。 4．规格说明分析 a) 需求和规格说明类别的概要 b) 有疑问的规格说明——对矛盾、含混、不可行、不可测试和TBD需求的识别和讨论。 c) 未解决的需求/操作问题，包括解决所需要的数据。 d) 对数学算法的分析。 5． 系统限制 必填 a) 硬件可用性——执行、储存、外围设备 b) 操作系统限制 c) 支持软件限制 6．性能估计和模型。 7．开发假设 8．风险 包括进度和进度的。。 9．原型化工作 解决技术风险所需要的，包括每个原型工作的目标和完成准则。 10．数据流和面向对象图表 必填 对需求分析阶段执行的需求的结构化或面向对象分析的结果。 11．数据字典 图表中显示的更新的过程、数据流和对象。 需求分析一点心得 2011年8月15日，我休假回到公司，四川分支crm行业部进行了四维分工，我分在了需求组。组长徐茜之前已经与我沟通过需求组具体的工作明细，但自己心里还是很担心，是否能做好这份新工作，毕竟自己以前都是做的开发工作，接触的都是代码，很少编写文档；不过我还是很高兴，新的工作具有挑战性，可以更好的锻炼自己各方面的能力； 首先我查看了一些以前同事写的需求分析文档，从中积累一些好的经验，比如如何描述需求要点，如何绘制流程图等； 然后给自己制定了工作要求，明确用户需求、不遗漏需求点、对需求进行分析、提出自己的意见和建议、输出需求规格说明书给开发人员；就这样我井井有序的开展着自己的新工作，本以为自己已经做的够细致了，几周下来还是出现了不少问题。需求规格说明书写的不够细、自己写的需求规格说明书开发人员看后理解的与需求原意不一致、测试上线开发点不齐全、设计需求时未考虑到后期的维护使维护工作增多、需求不能按照之前与用户指定的时间上线等；对于这些问题，自己进行了深入的思考，如何避免这些问题的出现；深思后发现大家好像缺乏沟通，需求的每一个环节没有贯穿起来，每个环节似乎都断开了，不像以前一个需求自己与用户沟通、自己开发、自己测试、上线，整个环节都在同一个人的掌控中，时间也是由自己安排； 作为需求分析负责人，自己是不是应该贯穿整个需求，而不仅仅只是把输出需求规格说明书作为一个需求分析工作完成的目标呢？ 首先沟通，与用户沟通，明确需求要点，不仅需要聆听用户的需求说明，还要懂得在用户已说明的基础上进行拓展，发掘客户没有讲出来的潜在需求。在已有业务的基础上进行模拟业务流程，分析业务是否走的通并且有无逻辑上不合理的地方。发现问题，及时与用户沟通，及时修改需求；与开发组长沟通，明确开发人员和上线完成时间；与开发人员沟通，使开发人员知晓需求要点，自己更好的完善需求分析规格说明书；与测试人员沟通，需求测试要点，判断需求上线的标准；与维护人员沟通，对应需求的维护工作如何开