需求分析的流程及规范标准[详].ppt

刘云 2012年11月 需求分析的流程和规范 需求分析的流程 业务建模 需求获取 分析 编写需求规格说明书（需求说明书） 验证 什么是业务建模 业务建模就是将客户所需求的业务从概念到实例的建立，从抽象到具体的模型化，是需求工作的开始 业务建模的目的 了解客户所在的业务、用户所在的业务（将要在其中部署系统的组织）的结构及机制 了解客户所在的业务、用户所在的业务（以下简称“目标组织”）中当前存在的问题并确定改进的可能性 确保客户、最终用户和开发人员就目标组织达成共识 导出支持目标组织所需的业务需求 业务建模 业务建模很重要的一点是在分析目标组织流程的同时分析出基础业务对象（简称CBO）,任何目标组织都有最基础的一些元素，例如社保的CBO是参保人员和险种，其他的CBO都是从这两个CBO的基础上发展起来的，参保人员和险种间是多对多的关系，根据关系理论，任何多对多的关系都可以拆分成多个一对多或一对一的关系，而新的CBO将根据分组情况产生，例如：民族，性别年龄等 业务建模 CBO是做业务建模的基础，在此基础上，通过评估业务状态，说明当前业务，确定业务流程，改进业务流程的定义，设计业务流程的实现，改进角色和职责，研究流程自动化，开发领域模型等一系列工作流程实现业务建模的目标 需求获取 需求获取是需求工程的主体，对于所建议的软件产品，获取需求是一个确定和理解不同用户类的需要和限制的过程 跟谁谈需求 客户、最终用户和间接用户 用户是一种泛称，它可细化为“客户”、“最终用户”和“干系人” 掏钱买软件的用户称为客户 真正操作软件的用户称为最终用户。客户和最终用户可以是同一人也可不是同一人 不是客户和最总用户，但对系统有一定影响的用户称为间接用户（或干系人） 跟谁谈需求 客户是“上帝” 客户将决定是否掏钱，是否扣钱 最终用户直接使用软件，他们的评价直接影响付款 “上帝”也不愿意在最终用户都不乐意的情况下掏钱买软件，得罪人啊 别忽略了间接用户 间接用户经常是规范、标准的制定方 分功能性需求的重视者（信息中心） 需求的分类 业务需求：反应了目标组织结构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明； 用户需求：描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明； 功能需求：定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求 需求的分类 非功能性的需求：描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制； 下一层次需求：用户清楚要使用该产品完成什么任务和一些非功能性的特性需求，例如：程序的易用性、健壮性和可靠性，而这些特性都将使用户很好地接受具有该特点的软件产品。 需求获取 业务需求决定用户需求，它描述了用户利用系统需要完成的任务。从这些任务中，分析这能获得用于描述系统活动的特定的软件功能需求，这些系统活动有助于用户执行他们的任务，需求获取是在问题及最终解决方案之间架设桥梁的第一步。获取需求的一个必不可少的结果是对项目中描述的客户需求的普遍理解。一旦理解了需求，分析这、开发者和客户就能探索出描述这些需求的多种解决方案。 需求获取的重要性 参与需求获取者只有在他们理解了问题之后才能开始设计系统。否则，对需求定义的任何改进，设计上都必须大量的返工。 需求是项目质量的基础，项目质量的定义是“与需求保持一致” 甲方对需求的要求 项目范围：“只要是业务需要的，都必须实现” 客观的态度 统筹规划、分布实施 过高的期望： “最好以最新的技术实现，每个模块都做成精品” “新系统在扩展性、灵活性、安全性、性能、可维护性等方面将上升一个台阶” 对乙方的依赖？ 乙方对需求的要求 项目范围： “给多少钱办多少事，在合同约定的范围内谈需求，超过合同范围不予考虑，或走需求变更” 对系统的预期： 一期建设一个基本可用的系统，不影响客户业务，在后续升级中完善 在满足客户需求和质量要求的情况下，以最简单、成熟的技术实现，将皮饭使用的模块做成精品 系统要有一定的灵活性和扩展性，以减少后期维护的工作量，但也要有一定的规范性 消极的态度 “客户给我谈了这些，我只要实现客户的这些需求就行了，如果需求不充分，那是客户的事，打补丁实现就好” 如何进行需求获取 需求的获取应该把重点放在“做什么”上。你可以使用假设“怎么做”来分类并改善你对用户需求的理解。 把需求获取集中在用户任务上，而不是集中在用户接口上有助于防止开发组由于草率处理设计问题而造成的失误。 在需求的获取过程中，分析模型、屏幕图形和原型可以是概念表达得更加清楚，然后提供一个寻找错误和遗漏的办法。 需求获取的结束 重要性排序，从高到低，没有新实例时 新实例可以用其它实例中获取 重复原先讨论过的问题 新