《需求分析与用例建模课件.pptx》由会员分享，可在线阅读，更多相关《需求分析与用例建模课件.pptx（51页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、需求分析与用例建模需求分析与用例建模第1页，此课件共51页哦主要内容主要内容1 需求分析2 需求建模3 活动图4 需求分析用例建模案例2第2页，此课件共51页哦1 需求分析需求分析1、系统调查2、系统需求陈述3、需求分析的任务及特点3第3页，此课件共51页哦1、系统调查、系统调查系统调查分为两个阶段初步调查初步调查：在可行性分析阶段进行，即先投入少量的人力对系统进行大致的了解，分析其开发的可行性。详细调查详细调查：在系统分析阶段进行的，即在确定系统可行并立项后，投入大量的人力，展开大规模、全面详细的系统调查。4第4页，此课件共51页哦1、系统调查、系统调查初步调查是接受客户提出建立新系统的要求
2、后，系统研制人员和用户管理人员的第一次沟通。主要技术方法包括：对现有文档、表格和数据库进行抽样；实地访问，观察工作环境；发调查表；面谈；联合需求计划（JRP）等。5第5页，此课件共51页哦1、系统调查、系统调查初步调查主要关注的内容现行系统的概况现行系统的概况：规模、目标、历史、组织结构、管理体制、人员分工、技术条件及技术水平等。系统外部的资源系统外部的资源：现行系统和外部环境有哪些联系，哪些外部条件制约系统的发展。现行系统的资源现行系统的资源：现行系统有哪些资源，信息系统的状况。6第6页，此课件共51页哦1、系统调查、系统调查初步调查主要关注的内容用户资源和要求用户资源和要求：开发新系统用户
3、可以提供的人力、物力和财力等情况，用户的时间要求、人员分工、功能要求、非功能要求和开发目标等。现有系统存在的问题现有系统存在的问题：可以通过调查表，收集一些信息。了解现有系统存在的主要问题。7第7页，此课件共51页哦1、系统调查、系统调查详细调查的原则系统性原则计划性原则科学性原则前瞻性原则8第8页，此课件共51页哦1、系统调查、系统调查详细调查的内容全面调查内容全面调查内容：与初步调查一样，要了解现行系统的发展历史、现状、规模、经营状况、业务范围、与外界的联系、确定系统的边界；对系统的组织结构进行调查，了解各个部门的权限、职责、人员分工和关系等；了解系统的资源状况，现有系统的物资、资金、设备
4、、建筑平面布局和其他的资源。9第9页，此课件共51页哦1、系统调查、系统调查详细调查的内容重点调查内容重点调查内容：包括业务流程和数据的调查。业务流程调查业务流程调查：主要弄清楚某项业务做什么？为什么做？由谁来做？在哪里做？何时做以及如何做等，在做的过程中产生了哪些数据。即：What、Why、Who、Where、When、How。数据调查数据调查：主要包括输入信息、输出信息、信息处理过程、存储方式、代码信息和信息需求调查等。10第10页，此课件共51页哦1、系统调查、系统调查建立获取信息的渠道用户和客户公司研发管理部门公司技术管理部门项目实施管理部门营销管理部门旧系统的研发项目组或组内成员11
5、第11页，此课件共51页哦1、系统调查、系统调查数据来源渠道 组织正式报告（对于手工系统）；各种卡片、报表；会议决议；现行系统的说明性文件（局部计算机化的系统）；各种流程图；计算机文件（或数据库），系统的数据组织结构；组织外的数据来源；上级下达的各种文件和各项任务指标；与本单位密切相关的其它单位的有关信息。12第12页，此课件共51页哦1、系统调查、系统调查调查方法 询问法 观察法 实践法 抽样调查法 查阅档案资料法 联合需求计划13第13页，此课件共51页哦1、系统调查、系统调查调查策略了解现有文档、表格、报告和文件；如果合适，观察工作中的系统；根据你已经收集到的信息，设计并分发调查表，澄清
6、你没有完全理解的问题；进行面谈来验证和澄清最困难的问题；对于没有理解的功能需求或者需要被验证的需求，使用合适的调查研究技术验证事实。14第14页，此课件共51页哦2、系统需求陈述、系统需求陈述为获得正确的业务模型，要建立需求陈述。内容包括：问题范围、功能需求、性能需求、出错处理需求、接口需求、约束、应用环境、假设条件及将来可能提出的要求等。需求陈述应该阐明“做什么”，哪些是必须的，哪些是任选的。需求陈述案例（见备注）15第15页，此课件共51页哦3、需求分析的任务及特点、需求分析的任务及特点需求分析阶段的工作定义需求分析与综合制订规格说明评审16第16页，此课件共51页哦3、需求分析的任务及特
7、点、需求分析的任务及特点定义需求从系统角度来理解软件，确定对所开发系统的综合要求，并提出这些需求的实现条件，以及需求应该达到的标准。需求包括：功能性需求和非功能性需求。功能性需求：描述一个系统必须提供的活动和服务（做什么）；非功能性需求：描述一个满意的系统的其他特征、特点和约束条件等。17第17页，此课件共51页哦3、需求分析的任务及特点、需求分析的任务及特点分析与综合逐步细化所有的软件功能，找出系统各元素间的联系，接口特性和设计上的限制，分析他们是否满足需求，剔除不合理部分，增加需要部分。最后，综合成系统的解决方案，给出要开发的系统的模型（做什么的模型）。18第18页，此课件共51页哦3、需
8、求分析的任务及特点、需求分析的任务及特点编制需求规格说明书描述需求的文档称为软件需求规格说明书。需求分析阶段的成果是需求规格说明书，是提交下一阶段的文档资料。评审对功能的正确性、完整性和清晰性，以及其它需求给予评价。评审通过才可进行下一阶段的工作，否则重新进行需求分析。19第19页，此课件共51页哦3、需求分析的任务及特点、需求分析的任务及特点需求分析的特点用户与开发人员很难进行交流。用户的需求是动态变化的。对于一个大型而复杂的软件系统，用户很难精确完整地提出它的功能和性能要求。系统变更的代价呈非线性增长。需求分析是软件开发的基础。假定在该阶段发现一个错误，解决它需要用一小时的时间，到设计、编
9、程、测试和维护阶段解决，则要花2.5、5、25、100倍的时间。20第20页，此课件共51页哦2 需求建模需求建模1、用例建模2、确定系统的边界3、确定参与者4、确定用例5、用例模型的关系6、构造业务用例模型图7、用例规格说明21第21页，此课件共51页哦1、用例建模、用例建模基本概念用例图是UML图中较为重要和常用的一种图，常常用于软件开发的分析阶段，也能用于软件的系统测试阶段。需求分析主要是定义业务用例模型，使用用例来描述系统需求。业务用例模型的目的在于描述企业的内部组织结构；描述企业各部门的业务；关注于角色和系统的交互界面。用例建模被认为是描述信息系统功能需求的最佳实践，用例模型描述系统
10、外部的参与者所理解的系统功能。22第22页，此课件共51页哦1、用例建模、用例建模用例图的组成用例用例是系统执行的一组动作序列、并为执行者产生一个可供观察的结果，这个结果对系统的一个或多个参与者是有价值的。用例描述一个系统做什么，而不是怎么做。用例命名（层次命名法）图书管理系统:静态模型:顶层包:取款23第23页，此课件共51页哦1、用例建模、用例建模用例图的组成参与者表示用例的使用在与这些用例 进行交互时所扮演的角色的一个紧密的集合（即角色），通俗地讲，是和系统打交道的人、系统、设备等。一个人可以有多个角色，一个角色可以是多个人。如，小明是图书馆的管理员，他可以参与管理，也可以普通用户的角色
11、去借书。24第24页，此课件共51页哦1、用例建模、用例建模用例图的组成关系参与者与用例间的关系：关联用例与用例间的关系：包含（使用）、扩展和泛化参与者与参与者间的关系：泛化25第25页，此课件共51页哦关系关系功能功能表示法表示法关联参与者与其参与执行的用例之间的通信途径扩展在基础用例上插入基础用例不能说明的扩展部分泛化用例之间的一般和特殊关系，其中特殊用例继承了一般用例的特性并增加了新的特性；参与者之间的泛化关系包含在基础用例上插入附加的行为，并且具有明确的描述1、用例建模、用例建模用例图的组成关系26第26页，此课件共51页哦1、用例建模、用例建模关系举例27第27页，此课件共51页哦1
12、、用例建模、用例建模关系举例28第28页，此课件共51页哦1、用例建模、用例建模用例描述用例描述是业务事件以及用户如何同系统交互以完成任务的文字描述。用例图可以直观地展现需求中的所有用例、参与者、系统边界，以及它们之间的关系，但这还不足以表达需求分析所要求表达的内容。用例图必须辅之以用例说明，才能完整清楚地表达。针对每一个用例都应该有一个用例规约文档与之相对应，该文档描述用例的细节内容。29第29页，此课件共51页哦1、用例建模、用例建模用例建模的步骤 确定将要设计的系统范围和它的边界。确定系统外的参与者。从参与者（用户）和系统对话的角度继续寻找一下两方面的特征：寻找参与者怎样使用系统；系统向
13、参与者提供什么样的功能。把离用户最近（接口）的用例作为顶层用例。对复杂的用例做进一步分解，并确定低层用例以及用例间的关系。对每一用例做进一步细化。30第30页，此课件共51页哦1、用例建模、用例建模用例建模的步骤 寻找每一个用例发生的前提条件和发生后对系统产生的结果。寻找每一个用例在正常条件下的执行过程。寻找每一个用例在非正常条件下的执行过程。用UML建模工具画出分层的用例模型图。审核用例模型。编写用例模型图的补充说明文档。31第31页，此课件共51页哦1、用例建模、用例建模用例建模应注意的问题业务用例是仅从系统业务角度关注的用例，而不是具体系统的用例。如登录。业务用例仅包含客户“感兴趣”的内
14、容。业务用例的所有名称应该让客户能看懂。用例建模的重点是用例说明而不是用例图。32第32页，此课件共51页哦2、确定系统的边界、确定系统的边界系统边界是一个软件系统需要处理的整个问题空间的范围。定义系统边界就是定义系统的范围，即哪些元素属于本系统，哪些元素属于相邻系统，明确系统目标范围。在确定好系统的执行者和用例后，系统的边界就确定了。33第33页，此课件共51页哦3、确定参与者、确定参与者参与者是在系统之外与系统交互的某人或事物，每一个执行者都对应一种特定的角色，每一个系统之外的实体对应多种执行者，就好比一个人在系统中他会有多种角色一样，又或者几个人可以用一个执行者来表示，因为他们对于系统来
15、讲属于同一个角色。参与者是在系统之外，在系统之内的不是参与者，参与者与系统有明显的系统边界。34第34页，此课件共51页哦3、确定参与者、确定参与者确定参与者的常用方法 系统开发完成之后，有哪些人会使用这个系统？系统需要从哪些人或其他系统中获得数据？系统会为哪些人或其他系统提供数据？系统需要与哪些其他系统交互？系统是由谁来维护和管理并保持其正常运行？系统需要应付（处理）哪些硬设备？谁（或什么）对系统运行产生的结果感兴趣？有没有自动发生的事件？35第35页，此课件共51页哦4、确定用例、确定用例用例是系统的一个功能单元，描述了参与者与系统发生的一次交互行为。用例，就是一件事情，要完成这件事情，需
16、要一系列活动。做一件事情可以有很多不同的方法和步骤，也可能会有各种各样的意外情况，因此，这件事情由很多不同情况的集合构成，在UML中称为场景。用例必然是以动宾形式出现，用例相对独立，但不意味用例不与其他用例交互而独立完成参与者的目的。36第36页，此课件共51页哦4、确定用例、确定用例确定用例的常用方法 从原始需求中寻找所包含的功能。未来的系统，需要和哪些系统发生信息交互？哪些人将操作未来的软件系统？系统有哪些受限的条件？未来的软件界面怎样组织？系统的响应有哪些去向？37第37页，此课件共51页哦5、用例模型的关系、用例模型的关系包含关系扩展关系泛化关系38第38页，此课件共51页哦5、用例模
17、型的关系、用例模型的关系包含关系39第39页，此课件共51页哦5、用例模型的关系、用例模型的关系扩展关系40第40页，此课件共51页哦5、用例模型的关系、用例模型的关系泛化关系41第41页，此课件共51页哦5、用例模型的关系、用例模型的关系包含和扩展的主要区别42包含的用例包含的用例扩展的用例扩展的用例这个用例是可先的吗？否是没有这个用例基本用例还完整吗？否是这个用例的执行是有条件的吗？否是这个用例改变了基本用例的行为吗？否是第42页，此课件共51页哦6、构造业务用例模型图、构造业务用例模型图进销存管理系统业务用例图43第43页，此课件共51页哦6、构造业务用例模型图、构造业务用例模型图库存管
18、理子系统业务用例图44第44页，此课件共51页哦7、用例规格说明、用例规格说明一个完整的用例包括参与者、前置条件、场景和后置条件等用例建模图画完以后，就要进行描述文档的编写，文档主要用来弥补图形表示的不足和增强系统的完整性。对于用例描述的内容，一般没有硬性规定的格式，但一些必须或者重要的内容还是必须要写进用例描述里面的。通常包括的内容有：用例名称、参与者、前置条件、后置条件、基本事件流、备用事件流、异常事件流等。45第45页，此课件共51页哦7、用例规格说明、用例规格说明一个完整的用例46第46页，此课件共51页哦7、用例规格说明、用例规格说明可以详细描述用例的方式用例规约描述活动图状态图顺序
19、图通信图47作用不大第47页，此课件共51页哦用例规约描述用例规约描述用例描述格式48描述项描述项说明说明用例名称和编号名称和唯一标识用例描述对用例的角色、目的的简要描述参与者与此用例相关的参与者优先级可选一个有序的排列，1代表最高优先级状态可选分为：进行中、等待审批、通过审查或未通过审查前置条件一个条件列表，这些条件必须在访问该用例前被满足后置条件一个条件列表，这些条件必须在完成该用例后被满足基本操作流程描述该基本流程（正常）备选操作流程表示这个行为或流程是可选或备选的，并不是总要执行它们异常事件流表示发生了某些非正常的事情所要执行的流程相关用例列表可选包括此用例相关的用例（泛化、包含和扩展
20、）列表第48页，此课件共51页哦不好的案例不好的案例只描述参与者的行为，没有描述系统的行为。49用例名称取款用例描述客户取款事件流基本事件流1.储户插入ATM卡，并键入密码；2、储户按“取款”按钮，并键入取款数目；3、储户取走现金、ATM卡以及收据；4、储户离开。第49页，此课件共51页哦不好的案例不好的案例只描述系统的行为，没有描述参与者的行为。50用例名称取款用例描述客户取款事件流基本事件流1、ATM系统获得ATM卡和密码；2、设置事务类型为“取款”；3、ATM系统获取要提取的现金数目；4、验证账户上是否有足够储蓄金额；5、输出现金、数据和ATM卡；6、系统复位。第50页，此课件共51页哦不好的案例不好的案例描述过于冗长51用例名称 客户维护用例描述 对客户资料进行维护事件流 备选事件流修改客户资料1在客户资料维护的主界面，用户选择查询某客户资料；2系统显示符合条件的客户资料，内容包括；客户编号、来源、类型、省份、公司名称，同时在每行的开始位置放置“修改”的按钮，以便让用户点击进行资料修改；3用户选择某客户记录左边的“修改”按钮，修改某客户资料；4系统打开修改客户资料界面；5第51页，此课件共51页哦