需求分析个人总结

1 / 25 需求分析个人总结 关于需求分析的总结报告 在学习了第四章的需求获取之后做出以下总结 这部分主要强调了在优秀的软件工程中抽象和建模的关键原则。使用模型来从已有的需求中梳理出误解和遗漏的的细节并与他人沟通需求。讨论了需求的不同资源和不同类型功能需求 VS 质量需求 VS 设计约束解释如何编写易测试的需求并描如何解决冲突。讨论需求引出、需求文档、需求评审、需求质量及度量以及如何选择一个规格 说明方法的示例。 为了开发出真正满足用户需求的软件产品首先必须知道用户的需求。对软件需求的深入理解是软件开发工作获得成功的前提条件不论人们把设计和编码工作做得如何出色不能真正满足用户需求的程序任然是失败的程序。 那么这些工作需要在编码前进行细致的安排包括 一需求分析任务的建立 1 确定对系统任务的综合要求 1 功能需求指定系统必须提供的服务通过需求分析应该划分出系统必须完成的所有功能 2 性能需求指定系统必须满足的定时约束和容量约束 3 可靠性和可行性需求定量的指定系统的可靠性 4 出错处理需求说明系统对于 环境错误应该怎样响应 5 接口需求描述应用系统与它的环境通信的格式 6 约束设计约束或实现约束描述在设计或实现应用系统时2 / 25 应遵守的限制条件 2 分析系统的数据要求 软件系统本质都是信息处理系统系统必须处理的信息和系统应该产生的信息在很大程度上决定了系统的面貌对软件设计有深远影响 3 到处系统的逻辑模型 4 修正系统开发计划 二与用户沟通获取需求的方法 分析员提出一些事先准备好的具体问题例如询问客户公司销售的商品种类、雇佣的销售人员数目以及信息反馈时间应该多快等在非正式访谈中分析员提出一些用户可以自由回答的开性 问题以鼓励被访问人员说出自己的想法例如询问用户对目前正在使用的系统有哪些不满意的地方。 在访问用户的过程中使用情景分析技术往往非常有效。 三分析建模与规格说明 1 分析建模 2 软件需求规格说明 通常使用自然语言完整、准确、具体地描述系统的数据要求、功能需求、性能需求、可靠性和可用性要求、出错处理需求、接口需求、约束、逆向需求以及将来可能提出的要求。 四实体 联系图 五数据规范化 六状态转换图 七验证软件需求 1 从哪些方面验证软件需求的正确性包括一致性、完整性、现实性、有效性 2 验证软件需求的方法 1 验证需求的一致性 2 验证需求的现现实性 3 验证需求的完整性和有效性 为了详细的了解并正确的解用户的需求必须使用适当方法与用户沟通访谈是与用户最基本的沟通。为了提高软件需求精确度快速建立软件原型是最准确最有效和最强大的需求分析技术。快速原型应该具备的基本3 / 25 特征是 “ 快速 ” 和 “ 容易修改 ” 。为了跟好的理解问题常常采用建模的方法结构化分析实质就是一种建模活动除了创建分析模型之外在需求分析阶段还应该写出软件需求规格说明书经过严格评审并得到用户确认后才能作为这阶段的最终成果。通常要从一致性完整性现实性和有效性四个方面复审软 件需求规格说明书。 通过做一些小项目我更深体会发到对于软件的需求分析一旦分析失误或者不能很好的满足用户的要求都将是一项失败的项目。如果是大项目将给公司带来不可估量的损失。特别是书写需求规格说明书除了与用户进行很好沟通外自己要梳理出很清晰的思路这样才能很好的按照需求进行编码。 文件编号： MAC-SWE-TMP-17 密级： 保密 通用 需求分析总结报告 模板 Requirement Analysis Report Template 本程序属 MAC 公司所有，未经书面许可， 不得以任何形式复印或传播。 4 / 25 修 改 记 录 文件编号： 密级： 保密 通用 需求分析总结报告 该报告由开发团队编制作为需求分析阶段的结论。其概述了需求分析的结果并建立开始概要设计的基线。建议内容如下： 1引言 必填 1 1 编写目的 说明编写这份需求规格说明书的目的，并指出预期的读者。 1 2 背景 说明： a) 待开发的软件系统的名称； 5 / 25 b) 本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络； c) 该软件系统同其他系统或其他机构的基本的相互来往关系。 1 3 定义 列出本文件中用到的专门术语的定义和外文首字母组词的原词组。 1 4 参考资料 列出用得着的参考 资料，如： a) 本项目的经核准的计划任务书或合同、上级机关的批文； b) 属于本项目的其他已发表的文件； c) 本文件中各处引用的文件、资料，包括所需用到的软件开发标准。 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源 2复用建议 关键复用候选项和系统全面体系概念。 6 / 25 3 操作概要 对需求分析阶段执行活动所产生的系统和操作概念的更新。 a) 更新操作方案。 b) 操作模型，包括在操作的每种模式、次序和类型中将处理的数据的容量和频率。 必填 简单的用户手册 c) 更新输入、输出和信息说明。 4规格说明分析 a) 需求 和规格说明类别的概要 b) 有疑问的规格说明 对矛盾、含混、不可行、不可测试和 TBD 需求的识别和讨论。 c) 未解决的需求 /操作问题，包括解决所需要的数据。 d) 对数学算法的分析。 5 系统限制 必填 7 / 25 a) 硬件可用性 执行、储存、外围设备 b) 操作系统限制 c) 支持软件限制 6性能估计和模型。 7开发假设 8风险 包括进度和进度的。 9原型化工作 解决技术风险所需要的，包括每个原型工作的目标和完成准则。 10数据流和面向对象图表 必填 对需求分析阶段执行的需求的结构化或面向对象分析的结果。 11数据字典 图表中显示的更新的过程、数据流和对象。 需求分析一点心得 8 / 25 2016 年 8 月 15 日，我休假回到公司， 四川分支 crm 行业部进行了四维分工，我分在了需求组。组长徐茜之前已经与我沟通过需求组具体的工作明细，但自己心里还是很担心，是否能做好这份新工作，毕竟自己以前都是做的开发工作，接触的都是代码，很少编写文档；不过我还是很高兴，新的工作具有挑战性，可以更好的锻炼自己各方面的能力； 首先我查看了一些以前同事写的需求分析文档，从中积累一些好的经验，比如如何描述需求要点，如何绘制流程图等； 然后给自己制定了工作要求，明确用户需求、不遗漏需求点、对需求进行分析、提出自己的意见和建议、输出需求规格说明书给开发人员；就这样我井井有序的开展着自己的新工作，本以为自己已经做的够细致了，几周下来还是出现了不少问题。需求规格说明书写的不够细、自己写的需求规格说明书开发人员看后理解的与需求原意不一致、测试上线开发点不齐全、设计需求时未考虑到后期的维护使维护工作增多、需求不能按照之前与用户指定的时间上线等；对于这些问题，自己进行了深入的思考，如何避免这些问题的出现；深思后发现大家好像缺乏沟通，需求的每一个环节没有贯穿起来，每个环节似乎都断开了，不像以前一个需求自己与用9 / 25 户沟通、自己开发、自己测试、上线，整个环节都在同一个人的掌控中，时间也是由自己安排； 作为需求分析负责人，自己是不是应该贯穿整个需求，而不仅仅只是把输出需求规格说明书作为一个需求分析工作完成的目标呢？ 首先沟通，与用户沟通，明确需求要点，不仅需要聆听用户的需求说明，还要懂得在用户已说明的基础上进行拓展，发掘客户没有讲出来的潜在需求。在已有业务的基础上进行模拟业务流程，分析业务是否走的通并且有无逻辑上不合理的地方。发现问题，及时与用户沟通，及时修改需求；与开发组长沟通，明确开发人员和上线完成时间；与开发人员沟通，使开发人员知晓需求要点，自己更好的完善需求分析规格说明书；与测试人员沟通，需求测试要点，判断需求上线的标准；与维护人员沟通， 对应需求的维护工作如何开展等； 其次就是协调，开发时间的协调，如果用户同时有几个需求都要求比较紧急，那么需要我们协调用户是否能将这些都很紧急的需求排一个优先级；需求要点协调，如果两个需求都要修改同一个模块的代码，那么为了保障程序版本问题，需要协调将两个需求开发时间错开；以及当维护人员发现模块10 / 25 BUG 时，需要协调用户发起对该 BUG 的优化； 有时还需要引导，引导用户走向有利于系统开发的轨道上，用户的一些需求，有些对整个业务其实可有可无，如果在实现起来很麻烦的话，可以引导用户取消这个需求，避免对系统大的改造影响了其他正常的业务，也浪费了开发人员的时间。如果系统本来就已经具备的功能，那么就要引导用户复用该功能，使系统可以最大程度的复用原来的功能。提高系统的代码的使用率，同时提高我们的工作效率。 最后就是完善，完善我们编写的需求规格说明书，可以使用需求用例、业务逻辑图、办理流程图、表格、界面图片等对需求进行说明，使需求规格说明书简单易懂，避免歧义； 这一年的需求分析工作，使自己对该工作有了更多、更深的认识；不仅要认真，还要有细心、耐心、有责任感；不仅要考虑当前的需求，还要分析系统已经具备的和将来需要支撑的；希望通过自己的努力，能将需求分析工作做的更好； 需求分析是项目开发的基础，基础打的牢不牢直接关系到后面所有的工作，是项目实施成败的关键 11 / 25 总体上说，我们的需求分析是做了，但是做得很不够，我们做的需求只解决了我们能做出这样的项目，但是没有解决这样的项目是不是真就是客户想要的。造成这种状况的原因主要是下面几个情况： 客户本身说不清楚 文物网是这样，中彰国际更是这样，但是这不能怪客户，毕竟客户在软件方面的知识要少的多，也没有相关的经验，可能心里只有一个想要的软件的轮廓，于是可能会要求我们去替他们来完整这个轮廓的细节，而我们的能力、我们能否真正站在客户角度去搜集和整理这些需求，就决定了这个需求的完整性和有效性。 软件开发网 需求自身经常变动 随着客户对这个项目越来越深刻的理解，那么可能他的需求也会随之改变，这些变化的可能性越大项目风险就会越大，我们在需求分析的时候就要充分考虑到哪些需求是相 对固定的需求，哪些可能会是产生变动的需求，考虑到他的可变12 / 25 性，这样设计功能和数据库的时候不致因为后面的变动而影响整个工程。 分析人员或客户理解有误 毕竟，不是每个分析人员都是专业而合格的，为避免这种情况的发生，需求分析必须要有审核制度，公司自己内部要审核一遍，客户再审一遍，提出意见，修改后双方共同评审签字，确认。 由此出现的问题： a) 需求分析过于笼统，只关注到面上，没有关注到点上，开发出来的东西在具体的细节上和客户的理解有误差，并且无法严格界定是否属于需求变更。中彰的方案就是这样的。 软件开发网 b) 需求报告只求我们这方评审通过，不去关心客户的评审，认为只要客户签字认可就行。虽然签字认可能够给日后出现问题时划清我们的责任，但是不能保证使项目实施成功。 c) 需求分析中含有技术实施上有难度的功能，一味的求全和盲目按照客户的设想，受客户影响过大，毕竟，很多时候，客户的想法在实际实施过程中是不现实的，或者可以有更为13 / 25 简便的方法来替代的。如中彰国际的在线交易功能，后台大批量邮件群发功能。 d) 对双方已经确定的需求，实现以后并不适合客户使用，需要按照变更手续执行的时候，客户可能会纠缠，提出 “ 你们是专业人士，你们应该事先能提醒我们可能会出现这种问题 ” 并以此来把责任推给我们，而我们又不好完全按照变更手续执行，因为可能激化双方的矛盾，比如 508 的批量处理功能，因为属于人事管理比较专业的细节问 题，需求分析师开始没有对客户业务熟悉到如此细致的地步，而客户也没有过多关注这些细节，导致软件的某些功能不合用，较为繁琐，而重新按着客户的意见修改的话工作量比较大，导致成本增加、工期延长。 e) 项目的成熟度受客户预算的限制。大部分客户在项目投入上都是有预算的，在成本有上限的前提下，项目的功能设计 (软件的成熟度 )方面必然受一定影响，毕竟功能越多越完善，相应的开发成本就越高。这种功能上的不完善需要事先告知客户并得到理解。 f) 此项工作的反复造成思想上的倦怠，使需求分析最后虎头蛇尾。需求分析是一项繁琐枯燥的工作，需要和客户之间不断的商讨、确认和反复，另外由于大部分的客户虽然安排专人负责这项工作，但是该人并不只做这项工作，特别当他14 / 25 被很多其他的事情缠身的时候，而无心细看提交过去的需求报告的时候，他很可能会给你一个错觉，让你认为他已经真正的理解并认可了你的设计。 结论 a) 需求分析 是整个项目管理中需要重点控制的几个关键节点之一，首先思想上一定要重视。 软件开发网 b) 需求分析报告的编写者要参与到需求的搜集工作中，准确领会客户的意图，并转化成软件能够实现的功能。对于说不清楚需求的客户，要善于问关键问题，引导客户提出自己的需求。可以采取的措施是事先编制一个问卷调查之类的文档，详细列举需要客户回答的问题，以便防止遗漏。 c) 需求报告的编写者要能够对客户需求进行深入分析，区别出哪些需求存在日后变更的可能，哪些需求属于相对固定的，哪些需求能够实现，哪些需求需要变通才能实现，以便于指导后面的功能设计。 d) 需求分析报告对功能细节的描述不能有歧义，描述一定要全面、准确，防止开发方和客户只见对同一个问题有两个截然不同的理解。可以通过评审，用大家的力量来避免这种情况发生 15 / 25 e) 需求报告的每个关乎功能的描述都要让客户明白和理解，客户在理解之上的确认才能够保证日后一旦出现问题不致出现双方互相推托责任纠缠不清的情况。 f) 需求报告一定要经过一个有技术人员和业务人员参加的评审，要充分发挥团队的力量，重视每个人的才智，一个模块一个功能的逐一的过，让 大家来共同找出需求报告里不合理的、有歧义的、不完善的、遗漏的等等问题 软件开发网 g) 帮助客户去理解提交给他的需求分析报告而不是只等签字，对于有能够用好几种方式实现的功能，尽 量做到能让客户去比较和选择。不要让客户对报告中的部分产生歧义。只有客户对报告的完全的理解，才能在日后客户提出的修改被认为是需求变更的时候能够得到客户的理解 h) 最后，需求分析报告一定要双方共同签字确认 做需求分析一点心得 16 / 25 2016-09-16 作者： 来源： 的 blog 1、需求分析前的准备 在软件开发过程中，需求分析可以说是核心任务之一，就像一支将要远航的船队，要在指定时间内到达目录地，他们需要一条正确的航线，才能到达目的地，如果航线有误，他们将会误时到达，或是不回到原位将永远到达不了，这么重要的东西，但在国内很多团队中缺少，虽然我也做了一些，但在项目完成的时候，回头看看，其实我们做了很多不必要的事，浪费了很多时间、人力和物力，为保证在今后的开发中减少这些错误的发生，现将一些问题记录下来。 为了了解系统需求，先可以从概要式的需求着 手，再细化需求，需求分析必须拟定文档，在写文档之前我们必须做好寻求分析的范围，总结为以下几点： 要做一个什么样的系统 这个不说，我想做软件开发的人都知道，拟定这个后，一切才可以扩展开，比如我们要做一个 B2C 的商城，要卖母婴用品，知道了这些，我们就可以找现在网站有的 B2C 网站做参考，分 析系统构架，系统功能等。 17 / 25 系统将要在什么样的环境下进行 我上次经历的一个系统，就是要用重新发一个 B2C 商城，但有一些前提条件，以前公司有网站，是用 java+MYSQL 开发的，但我们开发的新系统必须兼容以前的数据，如客户信息，商品信息，还有一些资源信息，并且还要兼容 Google,baidu收录的地址路径，还有与原 ERP 的通讯等条件，这样让我们的开发很受限制，这些需求就是这样，你无法改变，所以在设计新系统的同时你必须考虑，要花时间去了解以前系统的功能，接口等，如果不了解，等你把新系统开发完了才发现系统脱离了公司原有的业务流程，让公司无法运作，那就代表你开发的系统根本没有价值，我想这不是我们想要的结果。 要解决哪些问题 开发出来软件系统就是为了解决客户需求的，一个 B2C 网站就是卖商品，主要由客户、商品、购物车、定单组成，将这些核心的功能定义好，我想其它的意外都不会太影响到整个系统的进程。 18 / 25 将来可能会有哪些变化 面对将来的发展，我们也许不能完全考虑 到，但与公司的战略发展，可以提前考虑些，能想到多少就想多少，多多益善，我们开发一个系统不是只满足当前的需求，如果眼光只放在眼前，那么你这个系统很快就会被淘汰，功能也许不需要现在实现，但接口总得留下吧，不然想改进都是很困难的事，如果一个稍微的小需求都要动系统构架，我想这个系统会越来越不稳定，作为系统分析师，这块也是至关重要的。 系统可以维持任务的周期是多少 系统周期与公司战略发展是紧扣的，一个系统的功能不可能随着社会的变化，能一直满足市场需要的，在设计系统的时候，可以了解一下公司的战略发展，比如公司三年之内要做成什么样，客户多少，网站浏量，可以做下评估，这样就考虑系统构架的问题，你开始就准备构架一个大胖子，但现在需求简单，在实际的运行中，速度缓慢，其实你构架越 复杂，系统运行就越缓慢，虽说现在很多大系统运行的都很好，但要想想，人家服务器，网络构架是什么样的，你不可能让你的系统一线就有这么好的环境，就算有，那成本也太19 / 25 大了，一般的公司也吃不消。 系统分几个阶段实施 在开发初期，我们不可能将系统所有的功能都能完成的很好，为了加快开进度，为了系统能尽早上线，我们得像建楼一样，分阶段进行，分段实施，如果我们现在只是要在网上卖商品，那我们就得把客户管理、商品管理、购物车、定单管理这几大块实现，把一个系统根基打好，谁都想让自己的系统变成最强大的系统，但这个想法几乎是不可能完成的，如果我们把根基打好了，再在上面加以改进，添砖添瓦，根据客户或市场的需要来完善，我想这个系统就会慢慢变成一个成功的系统，对于 B2C 网站来说，能完成商业的需要，能让公司的流程走顺，那就是个好系 统，没有最好的系统，只(转 载于 : 海达 范文 网 :需求分析个人总结 )有最适合的系统。 分阶段实施，可以有节约成本，也可以加快实施速度，不管是作为公司的管理人员还是开发人员，能尽快看到成果，会提高信心，可以举个例子，在设计一个 B2C 商城的时候，我们除了客户管理、商品管理、购物车、定单管理外，还要加入广告管理、促销管理、 CPS、统计管理、用户积分、虚拟20 / 25 币、礼品、物流、接口等一些功能，如果开发周期只 给两个月，四个人，从系统设计到系统上线，怎么做 ?怎样如期完成呢？如果你的团队都没接触过 B2C 这样的系统，开发起来是很难度的，在这样的情况下，我们必须分段实施，抓主干，把核心的东西完成了，系统可以上线，虽然没有理想的那么强大，但最少它能赚钱，再一个两个月可以把客户管理、商品管理、购物车、定单管理这几块主要的功能完善，公司业务可以进行，后面的功能虽然很有必要，但也可以分个先后，系统上线了，能给大家看到东西，能用用，建议也会多些，对于系统的优化改进，这个是无止尽的，如果没有这些基本的东西，天天都会有人在你耳边叫， 你们什么时候上线呀，做了这么久，做的怎么样了，让你的团队心里承受着很大的压力，就算你在两个月内把开发任务完成了，那你的测试通的过吗，功能越多，问题越多，在后期维护问题越多，最后烦了，没办法，重构，那样不是亏大了。 确认第一阶段解决那些问题 在一个新的环境中，一个新的团队，你说要在某一 时间段里完成什么样的系统，你怎样做到让领导相信你，让公司相信你，一个大一点的软件系统，少则几个月，再多一点就一年半载，他们能等吗，再说了他们不懂代码，不会天天跟你的21 / 25 屁股后面问你，系统怎么样了，做了哪些，就算这样，我想你也进了疯人院了，所以我们做系统要打好第一枪，这样才会得到更多人的支持和理解，如果你不能理解，可以去看看商殃变法中的徒木立信的典故。 至于软件第一开发第一阶段要做哪些事，这个要根 据一个系统的核心功能去了解，只有建立好了框架，不要太急于求成，没什么好处，把根基打好了，再想怎么包装，都不是件难事。 系统开发团队由哪些人组成 一个好的团队，必定是发挥了团队中每个人的优势，在开发团队中，不是你技术能力强，你就是最有价值的人，我相信在开发团队里没有一个从头到尾都能支持 的能人，不是不没，是我是觉得不可能存在，也许我么说有些人不服，其实我这么说也有我的理由，一个人也许有机会经历团队中的每个环节，并且都能深入，但绝对不是一个机会，如果有，那就是一个人的开发，一个人的开发我想也不能叫团队，有时候，一个人什么都能做，多了一个人，什么都做不好，但面对大的项目，不得不进行团队合作。 我所在的公司，我进去的时候，接到项目任务，我开始还有22 / 25 些心虚，因为有些工作我也没接触过，但又 不得不去做，但我很意外的时候，我们的团队中有一位项目助理，她的出现让我们的团队协调管理得到了很好的实施，计划任务，可以做到很好的按排，但跟踪管理，我能收集分配，但指定到人后，我很难看到进展的情况，因为自身还有很多的工作，开始我部署了项目管理系统的，收集需求和 BUG，也指定到人，但反馈往往不及时，因为我有时候隔一天才上去看， 后来我将这项目工作交给了项目助理，让她去管理这些，我发现她做的很好，她每天和我只花几分钟的时间做核对，出现意外情况我就出现解决，她的出现把我和团队中的每个开发人员的工作连接起来，让项目管理得以顺利的实施。 开发团队具体由哪些人组成，这是要根据公司实力，项目进度和项目大小来定的，现在说几个工作职则，可