需求分析方式方法培训

1、Version1.0020120424业务需求分析背景知识领域业务需求分析背景知识领域3 1需求分析的思路、过程、和要求需求分析的思路、过程、和要求33 1需求分析的基本方式方法需求分析的基本方式方法2Business analysis is the set of tasks and techniques used to work as a liaison amongstakeholders in order to understand the structure, policies, and operations of anorganization, and recommend soluti

2、ons that enable the organization to achieve its goals.Structure信息结构Policies制度约束Operation操作行为StakeholderAchieve Business goals业务需求分析Recommend Solutions解决方案Business Requirements商业需求商业需求Stakeholder Requirements各利益相关者需求各利益相关者需求Solution Requirements方案需求方案需求功能性需求功能性需求1. 2.非功能性需求非功能性需求Implementation Requir

3、ements迁移性需求迁移性需求123分析计划和监控需求分析需求收集/采集企业分析方案评估需求管理与沟通识别利益相关识别利益相关者、分类者、分类+ +代代表表选择业务分析技术和管控流程、制定需求分析计划管理需求的冲突、变更。需求管理的基线版本控制需求实现的跟踪矩阵最高级别需求，定义项目解决方案的可行性标准项目成败的判定标准保证完全和清晰地采集了所有利益相关者的需求。各种采集方式方法的利用定义解决方案，保证完整满足业务需求和所有利益相关者的需求。各种分析方法和建模工具的使用。数据、业务、界面建模等。建模方案的评估和验证。各个方案的SW优劣势分析。差距分析、性能分析，可行性分析等。软件开发领域两个

4、重要的变化：软件开发领域两个重要的变化：面向服务的体系架构(SOA)。-现在很多组织用一系列的服务和服务之间的相互连接表示他们的解决方案。软件的产品线。通常，在一个组织开发和维护的系统中，存在着大量的可公用的部分。我们能够将在开发的产品线视图中定义良好模式的应用理解成为一种从一个抽象级别到一个更底层抽象级别的方案转化描述的方法。暂时应用于银行、保险、金融等大型复杂系统。OMG 确定了四种模型类型：计算无关的模型（CIM），平台无关的模型（PIM），平台相关的模型（PSM）一个实现相关的模型（ISM）。CIMCIM开发开发PIMPIM转换转换PSMPSM开发开发ISMISM转换转换用例图、活动图

5、状态图、类图、序列图平台相关技术模型开发代码生成Th e Guide to theBusiness AnalysisBody of KnowledgeInternational Institute of Business Analysis (IIBA) The Guide to the Business Analysis Body of Knowledge-右下角附件右下角附件UML建模 http:/ https:/ 基于UML的数据库建模技术研究.pdf利用UML获取功能需求的方法.pdf以UML用例图为基础的系统需求分析.pdfGB/T 1526-89GB/T 1526-89，信息处理，数

6、据流程图，程序流程图，系统流程图，程序网络图和系统资源图信息处理，数据流程图，程序流程图，系统流程图，程序网络图和系统资源图的文件编制符号及约定；的文件编制符号及约定；GB/T 17549-1998GB/T 17549-1998，用于行政、商业和运输业电子数据交换的业务与信息模型化框架；用于行政、商业和运输业电子数据交换的业务与信息模型化框架；GB/T 19000-2000GB/T 19000-2000，ISO9000ISO9000质量管理保证体系；质量管理保证体系；IEEE 1320.1-1998IEEE 1320.1-1998，功能建模方法功能建模方法IDEF0IDEF0；IEEE 132

7、0.2-1998IEEE 1320.2-1998，信息建模方法信息建模方法IDEF1xIDEF1x；美国国防部标准，过程建模方法美国国防部标准，过程建模方法IDEF3IDEF3；美国国防部标准，面向对象设计方法美国国防部标准，面向对象设计方法IDEF4IDEF4；对象管理组织对象管理组织OMGOMG建模语言标准，统一建模语言建模语言标准，统一建模语言UMLUML，MDA.MDA.国家标准软件开发文档模板3 2业务需求分析背景知识领域业务需求分析背景知识领域3 2需求分析的思路、过程、和要求需求分析的思路、过程、和要求3需求分析的基本方式方法需求分析的基本方式方法1一个超市系统的需求分类需求工程

8、需求开发需求管理优先级确定、分类、变更管理问题采集建议方案分析建模沟通优化总体验证需求文档非功能性需求常用类别通用类：通用类：-General-General1）系统/业务需求、合约/标准/规范、开发、设计、部署的约束条件。例如移动公司UI规范，南网接口规范等。2）需求描述是否明确具体，可衡量和验证。可靠性：可靠性：-Reliability-Reliability1）系统可靠性，MTBF,MTTR,MTTF（平均失效间隔、恢复时间、无故障时间） 。2）系统可用时间，uptime/available time.3)健壮性，准确性是否考虑了。（robustness requirements）性能类

9、：性能类：-Performence-Performence1）响应时间/延迟时间指标。（response time /latency TIME）2) 吞吐量要求throughput。3）输入/输出/存储容量要求。(Volume)4) 峰值、短期并发量的要求。安全类：安全类：-safety-safety、securitysecurity：1）系统操作，是否会给客户造成故障，是否有警告和恢复处理措施。例如GPON的VLAN ID分配会导致客户现场业务瘫痪。2）系统安全，例如web系统对外界入侵的防御措施，验证码、链接、sql注入，防木马等。配置类：配置类：-Configuration-Config

10、uration1）某些频繁变动的数据需要可配置。2）与其他系统的兼容性。尤其是外部系统单点登录、异构数据库等。操作限制和易用性：操作限制和易用性：-Usability-Usability、OperationableOperationable1）特殊的操作要求。例如必须支持远程访问、IE6浏览器等。2）国际化、本地化支持。UI规范等。用例视图是中心和綦础，它定义系统的需求，描述系统的外在行为用例视图是中心和綦础，它定义系统的需求，描述系统的外在行为( (即即“做什么做什么”) )，对其他视图，对其他视图起决定和推动作用。起决定和推动作用。需求需要从多个视角进行考虑和建模。系统/业务需求各利益相关

11、者需求方案性需求功能性需求非功能性需求实现性需求用例视图逻辑视图过程视图开发视图物理视图“ 4+1” 视图模型组问题域方案域结构化分析方法建模结构化分析方法建模 面向对象的分析方法建模面向对象的分析方法建模两种基本的两种基本的建模方法建模方法1.E-R实体关系图定义静态结构2.数据字典定义数据3.数据流图DFD、控制流图、状态迁移图定义动态变化4。处理规格说明（PSpec）控制规格说明（CSpec）定义细节说明静态结构动态变化-逻辑规则静态结构关系分析建模动态数据更新行为分析建模需求分析建模ONT中继电路语音业务语音业务逻辑端口逻辑端口逻辑设备0.*10.*1ONUOLTIP网络逻辑端口光路数

12、据业务逻辑端口数据业务电路1111PON链路11.*11.*1111数据流图的画法实践.PDF数据来源(外部实体)数据输出(外部实体)数据处理过程数据存储数据流图-希 赛培训静态动态结构化分析方法用例视图逻辑视图-最终用户-需求进程视图-系统集成人员物理视图工程人员开发视图开发编程人员服务于最终用户，描述描述用例图中功麓需求静逻辑结构,又称静态视图，是对问题域功能分解和抽象，常用类图、对象图，包图。服务于系统集成测试人员，捕捉并发和同步特征，描述进程、线程，循环线程，中间件，连接件，远程调用等，关注非功能性需求，并发性、吞吐量，可扩充性等。服务于工程实施人员，物理视图分为两种，实现视图和部署视

13、图，对应构件图和部署图，描述拓扑结构，部署安装和通信安排。服务于开发人员，描述了在开发环境中软件的静态组织结构，关注软件模块的组织与管理，通常是层次结构的。逻辑视图开发视图物理视图过程视图类图对象图包图无明确对应部署图，构件图4+1视图UML十大建模视图类图(对象图)，层次结构图 静态结构建模动态行为建模用例图对象图-运行时系统镜像构件图(物理视图)-模块、子系统-接口协作图，消息的时间空间调用状态图-复杂对象的状态迁移图活动图-一段复杂的控制逻辑表现图部署展开图-运行时类图Sequence序列图，消息的时间调用顺序包图-模块结构-调用1.用例图可以很好的描述系统边界，描述一个用户在系统中作用

14、和操作范围。2.用例图是在用户的角度来看系统的。所以用例不是功能点，功能点是开发人员的视角。3.用例不是步骤和业务场景，一个用例包括一组步骤和业务场景。共同完成一个用户有意义的功能。4.用例之间原则是独立的。有的时候需要说明用例细节，就需要关联关系了。三种基本关系，包含、泛化、扩展，这些都是枝节。 包含-拆分大用例成小用例。-常用。 泛化-用例的特定实现。例如统计报表，泛化为人员统计表，车辆统计表等。 扩展-用例会在某种条件下扩展出部分功能。例如湘潭光路调度流程，在资源不充足的情况下，需要启动工程建设流程。泛化包含扩展1.1.两个维度，角色两个维度，角色/ /部门部门/ /工作组，时间轴。工作

15、组，时间轴。-时候、人时候、人2.2.每个流程环节的重要处理逻辑，需要标注说明。每个流程环节的重要处理逻辑，需要标注说明。-做什么事情做什么事情 1）重要的业务处理逻辑； 2）重要的流程节点动作说明节点内转单、阶段性回复、签收、限时、超时标记、提交前校验必填项和重要逻辑、传阅知会、短信/邮件通知，撤销/中止标记。=后续与web室确定标准的动作列表 3）不是所有处理都要一个节点，节点意味着时间、跨人/跨部门协作，不要自己给自己转单。 4）不允许有悬空的节点3 3）明确标注并行逻辑，（分单并行）明确标注并行逻辑，（分单并行+ +并行合单标记）并行合单标记）4 4）退单线用红色虚线，与正常流向线区分

16、。）退单线用红色虚线，与正常流向线区分。5 5）格式要求：节点大小一致、对齐、流向线横平竖直，尽量少交迭，整体简洁。）格式要求：节点大小一致、对齐、流向线横平竖直，尽量少交迭，整体简洁。原则：原则：流程图要说清楚，流程图要说清楚，什么人，什么时候什么人，什么时候，做什么事情。，做什么事情。节点动作定义：节点动作定义：流程中节点的执行人员可以执行的操作，或者系统可以自动执行的操作，包括执行人在这个节点需要完成的流程规定的任务，以及为了完成节点任务可以进行的影响流程流转顺序的操作等。节点动作的类别：节点动作的类别：任务动作：节点完成的任务，如“审批”。流转动作：影响流程流转顺序的动作，如“加签”。

17、辅助动作：为完成任务而进行的辅助性动作，如“沟通”。流转动作类：类别类别名称名称描述描述人执行人执行系统执行系统执行表现形式表现形式备注备注流转动作收回节点执行完，下一节点执行前，可以收回进行修改，然后再提交.Y按钮所有节点都可以有，无需设置.加签审批时，可以征求另一人或多人的意见，然后再回到原审批人。注： 执行人必须有审批权限才能进行加签，但是加签的人没有审批权限，他只能在审批栏里面填写意见。 取消加签的归档加签后，可以对指定的加签人取消加签，取消加签后，未执行加签的人将不再看到流程加签请求了。如果不取消加签，则不需等所有加签人加签完毕磁能继续执行流转。Y按钮转发转发人与执行人有完全相同的权

18、限，包括审批，转发后不用回原节点。(流程节点不变)Y按钮叫代理是不是更好点？跳签跳过接下来的一个或者多个环节，直接指定节点执行Y跳签按钮点击跳签按钮，列出所有节点列表，供选择跳签的节点（之前节点和特殊逻辑节点不可选）。如果调签的节点无法确定执行人，则手工选择。退单可退回到某个节点继续流转，具体退回那个节点由流程设计时制定，不可以手工选择。（默认上一个节点）Y“退单”按钮中止流程提前结束，当前节点后的节点不再执行。Y中止由各流程节点执行人操作，与撤销不同。可在流程设计时制定，中止是否自动归文或归档。撤销撤销即本流程提前结束，后续节点不再执行。不过撤销只能由流程发起人执行，但不一定只是在发起节点才

19、有撤销权限。流程可以设定是否撤销自动归文或归档.撤销按钮提醒超时未处理，提醒执行人系统提醒需要设置节点超时时间，提醒间隔，次数，提醒方式等。升级超时未完成，超时提醒时间内仍未完成，则提交指定上级主管或者督查人员。系统执行升级的主管负责人，升级事件考虑单独记录，以供绩效考核。拆单并行本节点的下一个节点需要拆单多人并行处理，全部处理完毕再合单串行处理系统执行流程设计时确定 拆单的原则。1.确定并行的部门或者人员，或者手工选择均可。并单串行本节点的上一个或多个节点是多人串行的节点，在本节点合单改为串行处理。系统执行签收流程节点发给一组人可见，但仅一人可签收处理。 系统执行汉佳有。任务动作审批有审批权

20、限的节点，一般指定某个表单的字段，填写审批意见。Y同意/不同意审批意见编辑框会签用于审批后给相关配合人签字，以便获得工作上的协调Y会签和签字按钮在列表的会签栏里面留下执行人的名字和签字。如果可以关联笔迹签名更好。知会/传阅与会签类似，但是不需要留签字。只是给知会的人看一下,知会人可以查看流程。YY知会/传阅按钮需要记录知会/传阅人是否查看流程。一般审批后传阅，流程设计时可以确定传阅时，流程是否继续流转。归文将流程表单归入指定文档目录YY归文按钮归档流程结束前将其做归档炒作。YY归档按钮使用表单除了流程的主表单外，还可以在节点中选择启用预先配置的系统表单或者自定义表单。YY“表单”按钮特殊应用。

21、需要预先配置表单，流程中才可以选择应用。子流程/分发两种情况： 子流程启动后，父流程照常流转。1.子流程启动后，父流程停止流转，直至子流程流转结束，才继续流转。YY子流程按钮沟通/阶段性回复流程节点不变，用户可以分阶段填写沟通或者阶段性反馈内容，类似论坛留言。Y按钮任务动作类辅助动作类辅助动作手机短信短信通知，手工发送或系统自动发送。短信批复.短信通知组的设置.电子邮件邮件通知备注附件界面原型工具p Axure侧重webpGUI.Design.Studio侧重CSl分析图形工具pVISIOpMindManagerpTogetherpRational RosepSmartdraw用户对应用例，用

22、例包含一组业务场景，每个业务场景对应一个界面。大音希声，大象无形，见招拆招，无招胜有招，技能是工具，不是目的。充分沟通是关键，逻辑分析是根本；关注业务范围和约束，关注利益相关者，定位VIP，抓重点，拨乱反正，关注需求背后根源和目的；需求要适可而止，解决方案要精益求精。需求是不可以引导的，要深挖；解决方案和计划安排是可以引导的。需求不能靠意会，必须抽象、提炼、概括、分析，写出来并全流程环节沟通；需求分析的粒度考虑： 1）需求不可能不变化，范围明确，预判范围内部需求逻辑变化对系统逻辑框架的影响，可控程度70%-80%。 2）预见范围外的新需求，当期业务需求框架要考虑新需求的影响，引导客户将范围外需

23、求规划为后期项目。3 3业务需求分析背景知识领域业务需求分析背景知识领域3 3需求分析的思路、过程、和要求需求分析的思路、过程、和要求1需求分析的基本方式方法需求分析的基本方式方法21.确定业务需求背景、目标和约束技术方案书技术方案书功能点功能点3.识别用户制定需求采集方法和计划4.采集用户需求初步建议解决方案2.2.初步初步确定项目范围确定项目范围( (总用例图总用例图) )8.8. 确定确定解决方案，解决方案，输出需求文档。输出需求文档。5.流程图，界面原型图、E-R图、数据流图等。沟通解决方案循环迭代优化7.后台解决方案沟通，确定方案的可行性6.预见需求变化，考虑高级需求，预见和挖掘后续

24、需求预判对解决方案业务框架的影响9.客户邮件确认或签字10.预估工作量制定初验里程碑计划11.版本发布需求变更管理项目启动1.背景知识准备2.检视技术方案，深究背景和目的。3.确定业务需求和约束。-决定成败4.明确项目范围。确定用户和外部系统。5.总结风险和问题列表需求采集和分析开发启动1.识别利益相关者类别和代表，包括用户、角色、VIP，制定用户需求采集里程碑计划。2.2.逐个用户采集用户需求。逐个用户采集用户需求。1）关注背景和目的。2）当天总结会议纪要；3）过程中不断反馈解决方案思路；4）用总用例图描述系统范围和功能结构；用E-R图和数据流图描述信息和数据结构和重要处理逻辑；用流程图+界

25、面原型描述用户功能性需求；用seqence图等描述接口逻辑；用各种技能充分沟通，保证真客户正认可和理解你的解决方案。3.总结所有功能点的用户需求。确定需求优先级别，分类、聚类，细化、建模需求。结合业务需求假设和约束，核实和验证总体解决方案需求的合理性、可行性。4.再次考虑非功能性需求，可扩展性、部署问题，可行性。5.预见需求变化和挖掘后续需求，考虑业务逻辑框架的可扩展性。1.需求变化可控了，输出完整的需求文档，客户确认。2.后台需求沟通会，共同预估工作量，确定初验开发里程碑计划和大版本发布计划。3.向客户主动沟通和承诺开发里程碑计划。4.启动分析设计与开发，1.需求采集是采集系统、业务和用户需

26、求，这些都是问题域。2.我们的价值是帮客户解决问题，最终目的将客户的需求落实到我们的解决方案上，并得到客户认可。所以问题域需求转换为解决方案的需求，方案性的需求是技术平台相关的，是可实现的，可扩展的，可指导开发的，这才是需求分析的价值。3.系统需求、业务需求，是高压线，是纲领，是系统成败的判定标准。在采集用户需求和考虑方案需求的时候，要不断检视是否与系统需求和业务需求冲突。4.用户需求，是系统的各个使用者角色具体的需求，在功能性需求基本确定，流程图，界面原型完成后，需要召开沟通会，各个相关部门、角色要派代表参与需求评审。注意： 1）很多时候客户方经理认为他们谁都可以代表，但是不保证。-湛江网服

27、红线外流程的例子。 2）每个客户说的需求都是对的，和在一起就有冲突。5.问题域的需求，也就是客户需求，包括数据，总是零散的，没有逻辑的，与技术和平台无关的。我们所有建模和分析的目的，就是将问题域的需求，转换为可见的，可验证的，技术可实现的，数据和逻辑关联关系清晰一致的，可指导开发的方案性需求。 需求分析，就是权衡和取舍解决方案的过程系统/业务需求用户需求利益相关者需求方案需求功能性、非功能性问题域方案域需求分析项目范围说明： 框是系统边界。框内是系统功能用例；框外是用户或者其他系统。用户对应功能用例，用例由一组业务场景组成，业务场景对应原型界面。其他系统对应接口需求。功能性需求说明： 1.功能

28、性需求，一般用细化用例说明。一个典型的用例，一般要有编号，描述，操作者，目的、触发条件，输入输出，前置后置条件，处理流程等。2. 数据处理类功能，可以考虑用E-R图或者数据流可以说明。3. 信息处理类功能，可以考虑用活动图说明，即控制信息转换的过程。4. 流程用流程图说明。5. 接口类功能，需要接口文档说明，可考虑序列图、协作图辅助说明。5. 有重要和复杂界面操作的功能，用原型界面辅助说明。部署环境部署图，构件图。非功能性需求文本描述，无特殊方法。需求文档注意：1）要用公司正轨文档模板。 2）文档内容至少包括以下章节： 1项目概述 项目背景 项目目标 项目相关干系人 术语和引用 2概要需求-目

29、标理清项目边界，方法和工具：use case总图。 1）操作者描述; 每个操作者，是一个角色，对应一组用例。 说明他们在系统中的作用。 2）外部系统和接口 外部系统与系统有联系，所以肯定有接口。 3）具体use case，就是系统需要实现的功能点描述。 3详细需求=注意需要编号，如REQ-用例1-0001 1）功能性需求. a. 分用例描述 b. 用例中复杂业务场景，用原型界面-可以截图，或者引用. 2）非功能性需求（性能性需求） 3）部署性需求 4）深层次需求： 预见需求变化，其他新需求。(可不必在正式需求文档中体现) 如何适应。 4当前尚未解决的问题列表 5文档版本修改历史 6附录版本管理

30、，页眉页脚，版权说明，字体参照公司模板湛江业支开发文件规范3 3业务需求分析背景知识领域业务需求分析背景知识领域需求分析的思路、过程、和要求需求分析的思路、过程、和要求1需求分析的基本方式方法需求分析的基本方式方法23 4深入思考深入思考3工作工作意义意义客户客户(购买者购买者)提供目标、约束、业务价值和资金决定产品是否成功谁来决定产品是否成功如果多人，听谁的 产品负责人产品负责人（业务负责人）（业务负责人）提供阶段目标定义交付功能、定义业务价值功能进行产品验收、跟踪产品应用情况Onsite Customer, Product Owner 、Product Manager总体目标划分不同涉众目标的优先级谁为客户负责任用户用户（业务执行者（业务执行者 ）最终使用产品的人、角色、组织、团队或组织具体业务价值Kano模型模型 经济价值、开发成本、新知识的重要性、 故事之间会存在依赖关系、减少的风险1.风险和价值都高；2.价值高风险低；3.价值低风险低;4.价值低风险高，尽量不做，或换种