企业培训_需求分析方式方法概述

需求分析方式方法,Version1.0020120424,2,内容导航,业务需求分析背景知识领域,1,需求分析的思路、过程、和要求,需求分析的基本方式方法,3,业务需求分析-WhatisBusinessAnalysis,Businessanalysisisthesetoftasksandtechniquesusedtoworkasaliaisonamongstakeholdersinordertounderstandthestructure,policies,andoperationsofanorganization,andrecommendsolutionsthatenabletheorganizationtoachieveitsgoals.,4,需求的级别,BusinessRequirements商业需求StakeholderRequirements各利益相关者需求,SolutionRequirements方案需求功能性需求2.非功能性需求,ImplementationRequirements迁移性需求,1,2,3,5,业务需求分析的知识范畴,识别利益相关者、分类+代表选择业务分析技术和管控流程、制定需求分析计划,管理需求的冲突、变更。需求管理的基线版本控制需求实现的跟踪矩阵,最高级别需求，定义项目解决方案的可行性标准项目成败的判定标准,保证完全和清晰地采集了所有利益相关者的需求。各种采集方式方法的利用,定义解决方案，保证完整满足业务需求和所有利益相关者的需求。各种分析方法和建模工具的使用。数据、业务、界面建模等。,建模方案的评估和验证。各个方案的SW优劣势分析。差距分析、性能分析，可行性分析等。,6,新发展趋势-MDA模型驱动架构，更高级别抽象,软件开发领域两个重要的变化：面向服务的体系架构(SOA)。-现在很多组织用一系列的服务和服务之间的相互连接表示他们的解决方案。软件的产品线。通常，在一个组织开发和维护的系统中，存在着大量的可公用的部分。我们能够将在开发的产品线视图中定义良好模式的应用理解成为一种从一个抽象级别到一个更底层抽象级别的方案转化描述的方法。暂时应用于银行、保险、金融等大型复杂系统。,OMG确定了四种模型类型：计算无关的模型（CIM），平台无关的模型（PIM），平台相关的模型（PSM）一个实现相关的模型（ISM）。,7,业务需求分析知识推荐阅读,TheGuidetotheBusinessAnalysisBodyofKnowledge,InternationalInstituteofBusinessAnalysis(IIBA)TheGuidetotheBusinessAnalysisBodyofKnowledge-右下角附件,UML建模,UML建模机制研究及在系统需求分析中的应用.pdf,UML在数据库建模中的应用.pdf,基于UML的数据库建模技术研究.pdf,利用UML获取功能需求的方法.pdf,以UML用例图为基础的系统需求分析.pdf,8,一些现行的标准,GB/T1526-89，信息处理，数据流程图，程序流程图，系统流程图，程序网络图和系统资源图的文件编制符号及约定；GB/T17549-1998，用于行政、商业和运输业电子数据交换的业务与信息模型化框架；GB/T19000-2000，ISO9000质量管理保证体系；IEEE1320.1-1998，功能建模方法IDEF0；IEEE1320.2-1998，信息建模方法IDEF1x；美国国防部标准，过程建模方法IDEF3；美国国防部标准，面向对象设计方法IDEF4；对象管理组织OMG建模语言标准，统一建模语言UML，MDA.,国家标准软件开发文档模板,9,内容导航,业务需求分析背景知识领域,2,需求分析的思路、过程、和要求,需求分析的基本方式方法,10,纷繁复杂的需求,11,错误的需求理解就像燎原的野火,12,需求分类的复杂性,一个超市系统的需求分类,通用类：-General1）系统/业务需求、合约/标准/规范、开发、设计、部署的约束条件。例如移动公司UI规范，南网接口规范等。2）需求描述是否明确具体，可衡量和验证。可靠性：-Reliability1）系统可靠性，MTBF,MTTR,MTTF（平均失效间隔、恢复时间、无故障时间）。2）系统可用时间，uptime/availabletime.3)健壮性，准确性是否考虑了。（robustnessrequirements）性能类：-Performence1）响应时间/延迟时间指标。（responsetime/latencyTIME）2)吞吐量要求throughput。3）输入/输出/存储容量要求。(Volume)4)峰值、短期并发量的要求。安全类：-safety、security：1）系统操作，是否会给客户造成故障，是否有警告和恢复处理措施。例如GPON的VLANID分配会导致客户现场业务瘫痪。2）系统安全，例如web系统对外界入侵的防御措施，验证码、链接、sql注入，防木马等。配置类：-Configuration1）某些频繁变动的数据需要可配置。2）与其他系统的兼容性。尤其是外部系统单点登录、异构数据库等。操作限制和易用性：-Usability、Operationable1）特殊的操作要求。例如必须支持远程访问、IE6浏览器等。2）国际化、本地化支持。UI规范等。,13,需求的层次和多视图分析,用例视图是中心和綦础，它定义系统的需求，描述系统的外在行为(即“做什么”)，对其他视图起决定和推动作用。需求需要从多个视角进行考虑和建模。,14,需求分析的基本方法,结构化分析方法建模,面向对象的分析方法建模,1.E-R实体关系图定义静态结构,2.数据字典定义数据,3.数据流图DFD、控制流图、状态迁移图定义动态变化,4。处理规格说明（PSpec）控制规格说明（CSpec）定义细节说明,静态结构,动态变化-逻辑规则,15,结构化分析方法老土了吗？,数据流图的画法实践.PDF,数据流图-希赛培训,结构化分析方法,16,面向对象的UML建模与“4+1”视图,服务于最终用户，描述描述用例图中功麓需求静逻辑结构,又称静态视图，是对问题域功能分解和抽象，常用类图、对象图，包图。,服务于系统集成测试人员，捕捉并发和同步特征，描述进程、线程，循环线程，中间件，连接件，远程调用等，关注非功能性需求，并发性、吞吐量，可扩充性等。,服务于工程实施人员，物理视图分为两种，实现视图和部署视图，对应构件图和部署图，描述拓扑结构，部署安装和通信安排。,服务于开发人员，描述了在开发环境中软件的静态组织结构，关注软件模块的组织与管理，通常是层次结构的。,逻辑视图,开发视图,物理视图,过程视图,类图对象图包图,无明确对应,部署图，构件图,4+1视图,UML十大建模视图,类图(对象图)，层次结构图,静态结构建模,动态行为建模,17,UML常见模型图,用例图,对象图-运行时系统镜像,构件图(物理视图)-模块、子系统-接口,协作图，消息的时间空间调用,状态图-复杂对象的状态迁移图,活动图-一段复杂的控制逻辑表现图,部署展开图-运行时,类图,Sequence序列图，消息的时间调用顺序,包图-模块结构-调用,18,用例图说明,1.用例图可以很好的描述系统边界，描述一个用户在系统中作用和操作范围。2.用例图是在用户的角度来看系统的。所以用例不是功能点，功能点是开发人员的视角。3.用例不是步骤和业务场景，一个用例包括一组步骤和业务场景。共同完成一个用户有意义的功能。4.用例之间原则是独立的。有的时候需要说明用例细节，就需要关联关系了。三种基本关系，包含、泛化、扩展，这些都是枝节。包含-拆分大用例成小用例。-常用。泛化-用例的特定实现。例如统计报表，泛化为人员统计表，车辆统计表等。扩展-用例会在某种条件下扩展出部分功能。例如湘潭光路调度流程，在资源不充足的情况下，需要启动工程建设流程。,19,流程图,1.两个维度，角色/部门/工作组，时间轴。-时候、人2.每个流程环节的重要处理逻辑，需要标注说明。-做什么事情1）重要的业务处理逻辑；2）重要的流程节点动作说明节点内转单、阶段性回复、签收、限时、超时标记、提交前校验必填项和重要逻辑、传阅知会、短信/邮件通知，撤销/中止标记。=后续与web室确定标准的动作列表3）不是所有处理都要一个节点，节点意味着时间、跨人/跨部门协作，不要自己给自己转单。4）不允许有悬空的节点3）明确标注并行逻辑，（分单并行+并行合单标记）4）退单线用红色虚线，与正常流向线区分。5）格式要求：节点大小一致、对齐、流向线横平竖直，尽量少交迭，整体简洁。,原则：流程图要说清楚，什么人，什么时候，做什么事情。,20,流程节点的动作-1,节点动作定义：流程中节点的执行人员可以执行的操作，或者系统可以自动执行的操作，包括执行人在这个节点需要完成的流程规定的任务，以及为了完成节点任务可以进行的影响流程流转顺序的操作等。节点动作的类别：任务动作：节点完成的任务，如“审批”。流转动作：影响流程流转顺序的动作，如“加签”。辅助动作：为完成任务而进行的辅助性动作，如“沟通”。,流转动作类：,21,流程节点的动作-2,任务动作类,辅助动作类,22,其他较为典型的图表,23,界面原型与分析常用工具,界面原型工具Axure侧重webGUI.Design.Studio侧重CS分析图形工具VISIOMindManagerTogetherRationalRoseSmartdraw,用户对应用例，用例包含一组业务场景，每个业务场景对应一个界面。,24,十八般武艺都要用吗？,大音希声，大象无形，见招拆招，无招胜有招，技能是工具，不是目的。,充分沟通是关键，逻辑分析是根本；关注业务范围和约束，关注利益相关者，定位VIP，抓重点，拨乱反正，关注需求背后根源和目的；需求要适可而止，解决方案要精益求精。需求是不可以引导的，要深挖；解决方案和计划安排是可以引导的。需求不能靠意会，必须抽象、提炼、概括、分析，写出来并全流程环节沟通；,需求分析的粒度考虑：1）需求不可能不变化，范围明确，预判范围内部需求逻辑变化对系统逻辑框架的影响，可控程度70%-80%。2）预见范围外的新需求，当期业务需求框架要考虑新需求的影响，引导客户将范围外需求规划为后期项目。,25,内容导航,业务需求分析背景知识领域,需求分析的思路、过程、和要求,需求分析的基本方式方法,26,需求采集和分析的过程和思路,项目启动,1.背景知识准备2.检视技术方案，深究背景和目的。3.确定业务需求和约束。-决定成败4.明确项目范围。确定用户和外部系统。5.总结风险和问题列表,需求采集和分析,开发启动,1.识别利益相关者类别和代表，包括用户、角色、VIP，制定用户需求采集里程碑计划。2.逐个用户采集用户需求。1）关注背景和目的。2）当天总结会议纪要；3）过程中不断反馈解决方案思路；4）用总用例图描述系统范围和功能结构；用E-R图和数据流图描述信息和数据结构和重要处理逻辑；用流程图+界面原型描述用户功能性需求；用seqence图等描述接口逻辑；用各种技能充分沟通，保证真客户正认可和理解你的解决方案。3.总结所有功能点的用户需求。确定需求优先级别，分类、聚类，细化、建模需求。结合业务需求假设和约束，核实和验证总体解决方案需求的合理性、可行性。4.再次考虑非功能性需求，可扩展性、部署问题，可行性。5.预见需求变化和挖掘后续需求，考虑业务逻辑框架的可扩展性。,1.需求变化可控了，输出完整的需求文档，客户确认。2.后台需求沟通会，共同预估工作量，确定初验开发里程碑计划和大版本发布计划。3.向客户主动沟通和承诺开发里程碑计划。4.启动分析设计与开发，,27,需求采集与分析一些说明,28,常用需求分析场景和对应建模方法,项目范围,说明：框是系统边界。框内是系统功能用例；框外是用户或者其他系统。用户对应功能用例，用例由一组业务场景组成，业务场景对应原型界面。其他系统对应接口需求。,功能性需求,说明：1.功能性需求，一般用细化用例说明。一个典型的用例，一般要有编号，描述，操作者，目的、触发条件，输入输出，前置后置条件，处理流程等。2.数据处理类功能，可以考虑用E-R图或者数据流可以说明。3.信息处理类功能，可以考虑用活动图说明，即控制信息转换的过程。4.流程用流程图说明。5.接口类功能，需要接口文档说明，可考虑序列图、协作图辅助说明。5.有重要和复杂界面操作的功能，用原型界面辅助说明。,部署环境,部署图，构件图。,非功能性需求,文本描述，无特殊方法。,29,需求文档基本格式,需求文档注意：1）要用公司正轨文档模板。2）文档内容至少包括以下章节：1项目概述项目背景项目目标项目相关干系人术语和引用2概要需求-目标理清项目边界，方法和工具：usecase总图。1）操作者描述;每个操作者，是一个角色，对应一组用例。说明他们在系统中的作用。2）外部系统和接口外部系统与系统有联系，所以肯定有接口。3）具体usecase，就是系统需要实现的功能点描述。3详细需求=注意需要编号，如REQ-用例1-00011）功能性需求.a.分用例描述b.用例中复杂业务场景，用原型界面-可以截图，或者引用.2）非功能性需求（性能性需求）3）部署性需求4）深层次需求：预见需求变化，其他新需求。(可不必在正式需求文档中体现)如何适应。4当前尚未解决的问题列表5文档版本修改历史6附录,版本管理，页眉页脚，版权说明，字体参照公司模板,湛江业支开发文件规范,30,内容导航,业务需求分析背景知识领域,需求分析的思路、过程、和要求,需求分析的基本方式方法,深入思考,31,三大涉众/干系人,32,需求四象限、优先级,Kano模型,经济价值、开发成本、新知识的重要性、故事之间会存在依赖关系、减少的风险,1.风