中国移动用户需求开发分析.ppt

1、需求分析培训,目录,需求概述,.,需求开发活动,3.,业务功能需求模板,3.,需求概述,需求问题的症状（1）,症状：在软件项目中，变更频繁，而且集中出现在项目的中后阶段。分析要点：变更是对原需求的背离，还是补遗(需求不完整)?背离发生在什么方面(流程间/流程内/数据使用)？这些变更是需求阶段是否可能预见的?是否存在无效的变更响应(管理有问题)?改进方向：变更的可预测性需求阶段标识(需求捕获/分析)变更渠道单一化、统一化(需求管理),需求问题的症状（2）,症状：软件项目上线运行时遇到很多阻力。分析要点：是否为组织因素?阻力源于操作层还是管理层?改进方向：清晰的业务需求导向(需求定义)面向不同层面

2、的需求分析正确识别组织因素(需求捕获),需求问题的症状（3）,症状：软件项目上线运行后效果很差。分析要点：为什么不使用(用户界面/功能/手工系统)?使用者的成本/效益分析?改进方向：抓准业务需求(需求定义)不同层面用户的分析(需求捕获/分析),需求问题的症状（4）,症状：产品二次开发量大。分析要点：二次开发量最要集中于什么方面(业务规则/用户界面/流程顺序/流程细节/报表格式)?改进方向：工作流模型顺序/细节弹性设计业务规则/UI报表格式理解数据模型,需求问题的症状（5）,症状：产品/项目完全不可用或崩溃。分析要点：忽略了哪方面非功能需求?改进方向：性能与能力操作环境可靠性,需求：导致项目失败

3、的罪魁祸首,根据StandishGroup对23000个项目进行的研究结果表明，28%的项目彻底失败，46%的项目超出经费预算或者超出工期，只有约26%的项目获得成功。而在于这些高达74%的不成功项目中，有约60%的失败是源于需求问题。也就是说，有近45%的项目最终因为需求的问题最终导致失败。,我们在哪里会摔跤,在StandishGroup的报告中总结了导致项目失败的最重要的8大原因中，有5个与需求相关：不完整的需求(13.1%)；缺乏用户的介入(12.4%)；不实际的客户期望(9.9%)；需求和规范的变更(8.7%)；提供了不再需要的(7.5%),项目成功的因素,用户的参与：15.9%管理层

4、支持：13.9%清晰的需求描述(13.0%)；合适的规划(9.6%)；现实的客户期望(8.2%)；较小的里程碑(7.7%)；有才能的员工(7.2%),软件需求曾经让我们如此狼狈,-,需求是什么？,业务需求,业务需求是指反映组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求，业务需求就是系统目标。背景描述：XX公司希望充分利用日益完善的移动通信技术，在原有的办公系统的基础上进行扩展，使得在外的业务人员能够及时地获得客户、业务相关的动态信息，与此同时，实现企业内部的即时通信。业务需求/目标：通过该系统的实施，将人工办理业务、人工稽核两项业务效率提高10以上，使企业内部沟通效率

5、大幅改善，以帮助企业运转效率得以提高。,客户需求,用户需求是指描述用户使用产品必须要完成什么任务，怎么完成的需求，通常是在问题定义的基础上进用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求。用户有不同类型：管理型、事务型信息系统、人决策层、使用层常用者、偶用者组织方法：用例、用户故事、特性例子：对快到期的客户，系统将通过短信将业务信息发给客户,软件需求,从系统实现的角度描述的需求。开发人员（设计及分析人员）在业务需求、用户需求的基础上生成的。有时还需要考虑相关联的硬件、环境方面的需求,功能需求,功能需求是需求的主体，是需求的本质功能需求定义了：系统必须完成的那些事，即为了向它

6、的用户提供有用的功能，产品必须执行的动作零散（需求项）整理（特性、用例）,非功能性需求,可靠性：成熟性、容错性、易恢复性易使用性：易理解性、易学习性、易操作性效率：时间特性、资源特性可维护性：易分析性、易更改性、稳定性、易测试性可移植性：适应性、易安装性、一致性、易替换性,设计约束,也称为限制条件、补充规约，这通常是对解决方案的一些约束说明。例如：必须采用国有自主知识版权的数据库系统再如：必须运行在UNIX操作系统之下再如：用户将在户外完成作业,优秀的需求,完整性：完整描述即将交付使用的功能正确性：经过用户的审阅无歧义：对所有读者只有一种一致的解释必要性：每项需求记录的功能都应是用户真正需要的

7、有优先次序：提供了实现优先级可行性：在已知能力和约束条件中实现可验证性：可以设计测试方法来检查,需求开发活动,需求开发活动,需求获取的常用技术,阅读背景资料讨论分析文档考古面谈（用户访谈）用户调查现场观摩,用户访谈,用户访谈是最基本、最常见的技术利：直接有效、形式灵活、交流深入，应该做为主要的需求捕获技术（宽带通信、固有灵活性、各类信息）弊：占用时间长（特别当客户忙时更显示出其不足）、面窄而容易造成信息的片面性。要点：首先要有准备：通常包括说明对流程的理解，并征得客户的意见；预先根据流程中的不明确点设计要询问的问题，并将客户的反馈记录下来；应留有一些即兴的空间，根据实际情况应变，以确保信息完善

8、。第二是要有计划性：计划好时间、计划好人员、计划好策略。,用户访谈,一般建议不超过1小时，否则应安排下一次面谈时间安排：开场白：陈述理解515Min预先计划问题：主体工作2530Min即兴问题：展开性2030Min总结：陈述理解510Min地点选择：适当的不受干扰和避免打扰记录：自己做笔记（分神）,用户访谈：特点,最传统的方法，单独使用并不有效，通常别期望用户知道并能够说出他们的需求应先草拟一份问卷，向要访谈的用户发出一份涉及访谈主题和时间安排的材料在访谈的过程中，及时用草图绘制模型，从而得以及时反馈应以业务事件为谈话的中心，问问题，听取回答，然后反馈理解,用户访谈：操作方法,避免类似以下暗示

9、：我的时间比你宝贵，我不知道我在做什么，你不知道你在讲什么用简单的语言清楚地表达问题，采用对方的术语和行话不要遗漏任何事情不要搞错基本信息流要求的方向有效结合开放性、半封闭性、封闭性问题,用户调查,用户调查是面最广的技术利：面广，能够获得更多的人的反馈。这点是对用户访谈技术不足之处的最好补充。弊：不够深入，容易形而上学。而这点是正是用户访谈技术所能够解决的。要点：结合用户访谈技术使用。先访谈，后调查用调查验证访谈结果先调查，后访谈用调查理清方向,用户调查:主要用途,搜索某项假设的统计依据：设计一些封闭的问题，例如“从现有系统中取得客户统计资料的难易程度：非常困难、相当困难、容易、非常容易”搜索

10、意见、建议：询问与用户访谈类似的开放性问题，例如“日常工作中的三个最大问题是什么？”，“你对能够更好地支持日常常工作的IT系统有什么建议”。-误解你的问题，你误解他的回答,文档考古,文档考古是最贴近实现的技术利：能详细、直观地对数据流细节进行了解与分析。弊：易陷入文山书海之中不可自拔，甚至常引起误导。要点：应该尽量让客户提供写有真实数据的文档。特点：从旧的工作材料中挖掘新的需求检查收集的文档，从中找出名词，包括列标题、命名的表格区域涉及内容：文档、打印输出、清单、手册、屏幕等,文档考古：优缺点,优：获取信息相对比较直接，获得系统所有输入、输出及内部文档（但不应假定已获得全部描述）；有助于数据模

11、型分析。缺：文档说明的系统与实际系统可能是不匹配的；文档考古的传统分析方式（如开发文档流图）可能导致产生现有系统的结构模型，从而带入新系统,现场观摩,现场观摩是最生动的技术利：百闻不如一见，能够对需求与业务流程建立直观的认识。弊：消耗时间长，而且由于“被观摩”的微妙心理变化，会使得“观摩”失真。适用性：要对于复杂流程更加深入的理解时。要点：悄悄地进行，明确要强化理解的具体流程环节。,现场观摩,任务示范：要求用户示范如何执行特定的任务利：可用于发现异常的、关键性的任务弊：“示范”失真、耗时做学徒：和用户坐在一起，通过观察、问问题、并在用户指导下完成一些工作来学习适用性：用户无法详细解释清楚他们在

12、做什么时“人们正在做一件事时，最能解释他们在做什么，为什么要这么做”需求分析员可以通过学徒关系试验他的需求和设计思想,需求分析,所谓分析是指通过对问题域的研究，获得对该领域特性及存在于其中（需要解决）的问题特性的透彻理解并用文档说明分析方法：结构化分析法、面向对象分析法、面向问题域分析法任何分析法，均需描述以下几个方面:问题域的结构问题子域的固有属性及行为问题域中的重要事件及现象需求：应产生的效果,需求分析的方法结构化vs.面向对象,结构化分解符合人的心智模型适用于宏观层面DFD、E/R、DD面向对象符合事物客观规律适用于微观层面UML(用例模型、类模型、活动图),需求分析何时进行,应该在“业

13、务需求”充分理解，并且收集了最本质的“用户需求”之后就开始需求分析，但并不是等到需求捕获完全做完之后交替进行，先把握用户需求主要部分，然后在分析的基础上引入系统级的需求（系统的设计与实现角度），并且分析模型，成为开发人员之间、开发人员与客户之间达成共识的一个平台分析的基础上，就会发现更多的不明确项，更多待捕获的信息，这时就可以生成第二次的需求调研的计划、问题、素材,需求分析何时结束,需求捕获、分析与建模、规格说明书的编写、需求的验证这个需求开发的循环，是在整个软件开发生命周期中存在的每一次的循环，都将在需求开发的工作要点与份量上有所不同，它们应该遵循以下：从本质到边缘：本质、重要、次重要、一般

14、、镶金细化阶段是需求开发最密集的阶段构建阶段需求开发逐渐减少,编写规约,规格说明书是对需求分析结果的文档化过程比较“正规”的开发组织都会重视这个活动，甚至可以说是“重视过度”，而且产生出来的文档经常是与实际的开发脱离，完成之后就束之高阁，再也不使用、不更新，这是一个需求崩溃的信号规格说明书的格式与所采用的开发过程、分析方法相关的，不同的方法格式不同定义统一的格式是一个很重要的工作规约内容的严谨、正确、无岐义是很重要的,需求验证,这个工作大多数组织都不够重视，导致这个工作直到交付系统时才真正被履行，这也就是为什么客户拿到系统后才提出许多这样那样的需求变更，甚至认为整个系统都不是他所需要的提高需求

15、质量的重要手段：需求评审需求确认通过原型来验证需求,案例BOSS1.5资源管理,需求调研,初步沟通/问卷调查赴地市调研,文档编写,编写并细化需求文档（编写中不断征求业务部门/地市的反馈意见）,与业务部门反馈,汇报设计原则与模型介绍资源管理基本流程,业务目标,制定完整的可涵盖所有资源并与实际操作流程相符的订单流程提供准确的实时库存信息，达到稽核、盘点的管理要求,需求验证,召集各地市业务人员开会评审资源管理业务功能、业务流程根据评审意见调整修改,业务功能需求模板,模板内容,业务描述业务原则2.1适用范围2.2前提条件2.3业务互斥2.4开通限制功能。3业务管理3.1业务流程3.2业务受理3.3票据说明3.4相关业务。,模板内容,计费处理帐务处理资费原则6.1营业资费6.2帐务资费6.3计费原则优惠说明7.1营业优惠7.2帐务优惠结算报表统计外系统接口其它,注意事项业务原则,业务开放的地市、开放的用户类型、开放的品牌、产品业务的前提条件业务的依赖、互斥规定开通、限制的功能,注意事项业务管理,业务流程：涉及功能多，涉及的角色多，涉及的交互步骤多，画出流程图说明业务受理：受理的步骤、界面要素、功能按钮、业务校验规则、短信的通知内容、菜单位置、开放角色权限、开放的受理渠道票据说明：受理免填