产品需求分析与管理课件-工程总述_第1页
产品需求分析与管理课件-工程总述_第2页
产品需求分析与管理课件-工程总述_第3页
产品需求分析与管理课件-工程总述_第4页
产品需求分析与管理课件-工程总述_第5页
免费预览已结束,剩余65页可下载查看

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

需求工程总述需求工程概述问题1:

ATM机提供什么服务?问题2:一台ATM机的设计有哪些特性?问题3:一台ATM机,服务的全流程是什么?问题4:银行为什么要提供ATM机服务?总结:提供的到底是什么产品?产品有能力控制完整的服务流程,输

质吗?产品拥有提供这个服务 需求能力,并不断提升 能力需求吗?完整的服务流程清晰后,是完备的还是有缺失的麻雀到鹰的距离--从ATM机开始产品需求42020年11月24日需求工程分析的意义意义一:职业素质的培养意义二:掌握需求分析的流程与规程意义三:扩大需求工程师技能需求工程师应具备的能力要想真正转型成为业务驱动需求人员,需要哪些素质呢?沟通力:需求的问题绝大多数都是沟通的问题,沟通力是做好需求的核心能力。业务分析力:信息系统、软件只是人们学习、生活、工作的工具,它的本质在于实现业务价值。需求分析团队只有建立良好的业务分析力,才能抛开表象,理解需求本质。可以说业务分析力是需求能力的重中之重。技术理解力:需求分析师是用户与软件开发人员之间的桥梁,这是一个十分经典的比喻。而要做好这个桥梁,具有良好的

技术理解力是十分必要和有效的。方案创新力:需求是不需要创新的,而如何低成本、高效率地满足客户的需求,就需要有良好的解决方案创新能力。需求管理力:对于任何项目、产品开发而言,时间和资源永远是不够的,因此我们还需要控制需求,对需求进行优先级

排列,以便在有限的时间和资源内交付最有价值的需求子集,这就是需求管理力。52020年11月24日一个完整软件工程阶段Requirement

Engineering需求工程High

Level

Design楖要设计Low

Level

Design详细设计CUT编码及单元测试SIT系统集成测试Release最新版本UAT用户接受测试62020年11月24日怎样理解需求工程软件需求的定义1.用户解决问题或达到目标所需的条件或能力(Capability)2.系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能3.一种反映上面(1)和(2)所描述的条件或权能的文档说明1997IEEC软件工程标准词汇表82020年11月24日需求的层次业务需求用户需求功能需求92020年11月24日功能需求(functional

requirement)定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足了业务需求非功能需求,它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约;外部界面的具体细节;性能要求;设计或实现的约束条件及质量属性User

Requirement

描述用户的目标,或用户要求系统必须完成的任务。用例(use

case),场景(scenario)描述都是表达用户需求的有效途径。描述用户能使用系统来做什么Business

requirement

表示组织机构或客户对系统、产品高层次的目标要求,它们在项目视图与范围文档中予以说明业务需求通常来自项目的投资人,购买产品的客户,实际用户的管理者,市场营销部门或产品策划部门。描述组织为什么要开发一个系统。不同层次需求的特征需求的标准及要点明确性(Clear)避免语言的二义性,无歧义完整性(Complete)从最初的计划制到到最后的需求评审一致性(Consistent)用户需求和业务需求一致功能需求和用户需求一致需求的边界定义可行性(Testable)避免需求的不可测试性实际上测试从需求分析过程就开始了需求是测试计划的输入和参照102020年11月24日112020年11月24日需求工程的目标1.

需求工程的目标就是“正确的需求”2.

谁的目标?3.

成果是什么?4.

怎样确定”完整的需求”?需求的内容122020年11月24日产品需求的内容产品的需求过程产品是端到端的过程,端即用户。产品需求过程三步骤142020年11月24日产品创新源于三新技术创新带来的机会152020年11月24日人群特点变化带来的机会新业务模式带来的机会产品需求的理解产品需求需要关注的……2020年11月24日17产品设计需求少即是多兼容性无所不用其极关注性能和速度抓住高端用户大气的设计满足用户个性化需求需求差异运营需求不稳定会”功亏一篑”跟踪用户定位问题抗灾容灾能力交互类需求符合用户习惯与预期做适时的提醒不强迫用户选择最佳方案操作便利视觉类需求传播产品理念干净整洁,工具化规范与统一重点突出天下武功唯快不破优秀的技术实现+优秀的产品体验=优秀的产品能力和速度产品设计需求—无所不用其极体现最强技术产品设计需求—少即是多做得越多越不好,需要经常告诫:是不是做得太多了用户价值不会因为是大而全而体现的,而是每一个单项是否能真正获得用户的喜爱。简单的核心在于:做好最核心的10个,放弃其它的90个技术人员总希望将每个需要的不需要的功能都放到面板上。好的产品总是让用户看不到技术的存在192020年11月24日产品设计需求—用户的口碑支持高端用户IOS,Android手机体验浏览器的兼容性,包括IE内核类,Firefox,

Chrome,

Safari产品功能的向后兼容性产品升级时的兼容性考虑,包括用户的设置配置和使用习惯配置安装位置,命名格式等减少操作系统或安全产品的预警告202020年11月24日产品设计需求—满足用户个性化需求,持续增加新的功能于无形中提供针对用户的个性化服比如提供用户设置等个性化换肤(推送+自定义)常规功能逐步完善细小局部创新永不满足建立快速反应开发机制,实现灰度上线谨慎增加,判断用量,适时出现212020年11月24日产品运营需求—抗灾容灾能力如QQ邮箱,发生硬件故障时,至少能让用户看邮件QQMail开发的”实时只读容灾系统”,即使硬件故障,用户也能利用实时备份数据进入到邮箱的”只读”模式222020年11月24日产品运营需求—跟踪用户定位能力当看到用户在论坛或博定上提到的某些不明确的问题时,需求人员可以通过QQ,邮箱,电话等多种方式,主动去联系对方,搞清楚问题的细节。当然用户也会报答一个好的口碑232020年11月24日值得学习的产品,可以作为需求分析设计242020年11月24日252020年11月24日对需求工程分析的思考需求的完整全面性的意义全面性是一致性的必要的前提和基础思维程序正确地观察和思考问题的思维程序是:先宏观,后微观;先一般,后特殊常问自已“别忘了什么”会说“一二三”262020年11月24日需求风险1.

无足够用户参与2.

用户需求的不断增加3.

模棱两可的需求4.

不必要的特性5.

过于精简的规格说明6.

忽略了用户分类7.

不准确的计划272020年11月24日需求评审分层次评审正式评审和非正式评审结合分阶段评审精心挑选评审员对评审员进行培训充分利用需求评审检查单建立标准的评审流程充分准备评审282020年11月24日业务需求报告和规格说明书的区别请大家思考:业务需求报告的需求规格说明书的区别需求工程的最佳实践最佳实践—需求的沟通与分析302020年11月24日312020年11月24日避免沟通失真的关键手段文档Review启示1客户:放大需求项目经理:控制需求分析人员:技术加工编程人员:断章取义322020年11月24日启示2两种手段来检查需求的正确性需求评审需求测试332020年11月24日34202200年201年1月1214月日24日需求工程最佳实践(1)需求规格说明不应该采用技术为导向,应该采用业务为导向来组织,分别面向不同层面(决策者、事务管理层、操作层)将需求分成不同的部分,让合适的人验证适当的部分,然后再汇总。最简单、最有效的review就是在用户代表阐述了需求之后,需求分析用自己的语言再复述一遍,以确保沟通没有失真。(工作安排技巧:让工作接受者复述任务内容)定义需求访谈问题列表引导用户划分需求的优先级需要按照业务、技术开发、项目管理三个角度来确定优先级,技术开

发、项目管理只提级不降级。业务角度根据业务价值和频度进行评价,技术开发根据技术依赖性进行调整,项目管理根据项目风险对优先级

进行调整客户如果提出解决方案,需要多问一次为什么需要这样,以找到问题的本质。35202200年201年1月1214月日24日需求工程最佳实践(2)需求分析人员需要尝试理解业务场景,并需要处理客户言过其实、抗拒、推卸责任等心理.在需求捕获阶段,用户访谈中被访谈者建议包括四类:高层管理人员、中层管理人员、操作层、技术团队.概念模型(设计)和物理模型(设计)区分:概念模型(设计)属于需求视图,物理模型(设计)属于开发视图。业务场景中才能得到需求实质界面原型不应该是解决方案,它是客户对业务的要求和约束,是需求人员的实现建议362020年11月24日需求实践常见的问题我们是在描述一个需求,而不是在策划一个创意、创造一个概念。分解是必需的,但最终的目的是为了更好的组合,而不是为了分解。没有任何需求是不对的,不对的只是你的需求分析需求分析和程序设计不尽相同,合理、可行是才是重要的372020年11月24日需求最佳实践的核心线索业务需求=目标+范围目标的表达必须包括目标+优势+度量+合理+可行,或者说

SMART原则。同时在目标表达上可以考虑场景法,即问题是什么-》影响谁-》后果是什么-》解决方案优点是什么?范围表达的两个重要方面是人和物,人包括干系人和最终用户;物包括业务事件和管理控制点。需求定义输出业务需求;需求捕获输出用户需求;需求分析输出软件需求。需求分析的本质动作就是分解,抽象和消除歧义。而对于需求分析的本质线索则是人,事

(流程),物(数据)和接口。因此需求分析不能完全等同于建模型。分析是本质,建模仅仅是手段。38需求最佳实践-需求获取需求获取编写项目视图和范围文档选择用户代表确定使用实例分析用户工作流程检查问题报告用户群分类召开

议确定质量属性需求重用需求分析编写需求规格说明书需求验证需求管理2020年11月24日39客户的五边形-好的客户决定好的解决方案客户需要专业解决方案客户需要业务痛点理解客户需要尊重客户需要建议客户的五边形在重视客户的基础上,借助自身的专业程度注意对客户真实需求的理解和导向性引导,如:提醒客户对现状问题点的重视,让客户了解所能获得的改善,明确的交流改善所能带来的显性效果等等客户需要认可需求最佳实践-需求分析需求获取绘制关联图分析可行性需求建模创建开发原型确定需求优先级编写数据字典需求分析编写需求规格说明书需求验证需求管理40需求最佳实践-需求规格说明书需求获取采用模板指明需求来源为每项需求注上标号记录业务规范创建需求 能力矩阵需求分析编写需求规格说明书需求验证需求管理41需求最佳实践-需求验证需求获取需求文档依照需求编写测试用例编写用户手册确定合格的标准需求分析编写需求规格说明书需求验证需求管理42需求最佳实践-需求管理需求获取确定变更控制过程进行变更影响分析变易影响的产品建立基准和控制版本变更的历史记录每项需求的状态衡量需求的稳定性需求分析编写需求规格说明书需求验证需求管理43442020年11月24日需求工程的建议步骤1.确定需求范围和目标2.分析需求范围,准备调研素材3.进行需求开发,获取需求和素材4.分析获取到的信息和资料5.撰写需求规格说明书草案6.进行需求验证7.必要时:进行补充开发8.形成需求规格说明书9.需求跟踪和管理10.需求变更审批和跟踪452020年11月24日需求的变化就是创新的机会没有不变的需求需求的变化就是创新的机会需求分析是一个工业化的写作过程80%的套路+20%的创意好的语文水平有利于抓住关键词汇有利于培养数字敏感有利于增强形容能力有利于组织文档结构有利于提高沟通能力462020年11月24日472020年11月24日优异的文档能力有结构就有思路,有思路就有文档只有当一个人对思路有体系以后,才能够写出完整的需求文档了解业务最有效的方法就是亲自做几次详尽的业务调研积累大量可公用的素材库需求规格说明书不能成为功能列表482020年11月24日怎样实现一个优秀的需求完整性正确性可行性必要性有优先次序无歧义可验证案例

:灰度发布产品需求分析报告灰度发布的需求背景灰度发布的业务需求业务需求512020年11月24日灰度发布的需求分析

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论