业务流程及功能需求分析.pptVIP

4.3.3用例模型的建立及检验“教学计划管理”用例模型4.3.3用例模型的建立及检验“日常教学管理”用例模型4.3.3用例模型的建立及检验“排课处理”用例模型4.3.3用例模型的建立及检验“学籍管理”用例模型4.3.3用例模型的建立及检验2、用例模型间的层次关系4.3.3用例模型的建立及检验角色之间的关系4.3.3用例模型的建立及检验3、用例模型的检验（1）检验用例模型与数据流程图之间的关系（2）用例模型的检验①用例模型中，除扩展用例和包含用例可以没有参与者外，每个用例都应该有角色，并且由角色启动用例。②两个参与者之间不应该有“单向关联”线，即某个参与者不能启动另一个参与者。③用例间的包含关系和扩展关系出现循环回路，在逻辑上是不合理的，应该重新考虑扩展用例或包含用例的设置问题④如果发现有两个参与者共同启动一个用例，那么说明用例也还可以进一步分解。⑤每个用例应该是一个相对独立的功能，如果包含多个功能，那么可以考虑对用例进行分解（3）用例模型的完整性检验与用户一起彻底检查每一个用例，确认其功能需求是否完整，用例的命名是否存在歧义，用例所表达的功能需求是否与用户的想法一致4.4功能描述4.4.1用例的活动图描述1、活动图要素开始、活动、状态、同步条、判断、结束、迁移和泳道4.4.1用例的活动图描述2、用例内部的活动图描述“学生档案管理”活动图4.4.1用例的活动图描述“审核学籍”活动图4.4.1用例的活动图描述“毕业资格审查”活动图4.4.1用例的活动图描述3、用例间关系的描述“学籍变更申请处理”活动图4.4.2状态图“学籍变更申请处理”状态图4.4.3用例说明1、用例说明的基本内容简要说明：概要描述用例的作用。一般认为，用例名称是对用例功能的高度概括。前置条件：说明执行该功能之前必须满足的条件。例如，“初审学籍变更申请”用例的执行前提是必须先由学生提交学籍变更申请。场景：描述具体细节，说明具体操作步骤。指出用例如何开始、进行哪些操作、正常的流程、出错后如何处理、用例如何结束等等。对场景的描述可采用结构式语言、判断树和判断表。后置条件：用例执行后必须为真的条件，即说明该用例执行完后在什么条件下才可以运行另一个用例等等。例如“初审学籍变更申请”用例执行完后，只有在初审通过的条件下才可以执行“审查学籍变更申请”用例。非功能性需求：对用例的运行在可靠性、可用性、可支持性方面的要求，以及性能上和设计约束方面的要求。例如，当学生提交了学籍变更申请之后，在院系负责人的电脑上给出相应的提示信号，提醒院系负责人有待审的学籍变更申请需要处理。4.1需求调查概述4.1.1良好需求的特征良好的需求一定具有可沟通性，保证所有人对需求的理解都是一致的，具有无歧义性、可检验性、确定性、完整性、可跟踪性和正确性。1、无歧义例：①保存两位与学生有着社会关系（如父母）的信息②打印学生基本信息③分析学生成绩4.1需求调查概述4.1.1良好需求的特征2、可检验例：①系统要操作简单②系统运行效率要高3、确定性强例：如果每个月有3天至5天的事假，则发放月奖金的一半，如果事假在5天以上，则没有奖金4.1需求调查概述4.1.1良好需求的特征4、完整性在需求调查时一定要获得全部完整的需求，不能有遗漏5、可跟踪性要有一套完善的管理机制和文档规范，明确标识和记录每项需求从最初被提出到最终被确定的变化轨迹，记录为实现需求所进行的分析、设计、实现和测试的方案及工作过程。6、正确性任何一项需求都必须是正确的，能够准确地描述系统必须提供的功能4.1需求调查概述4.1.2需求调查的步骤及工作产品4.1需求调查概述1、调查阶段——主要任务是获取需求，其内容包括功能性需求、非功能性需求2、分析阶段——从业务领域中抽取能够由计算机来完成或者是能够由人机共同来完成的业务活动，将数据流程图中的功能部分通过用例图的形式表达出来。3、描述阶段——对每个用例的详细描述可以使用自然语言，也可以使用图形方式来描述4、检验与确认阶段——获得的需求一定要经过检验和用户的确认4.1需求调查概述4.1.3需求调查前的准备1、阅读资料2、构建术语表3、制定调查计划调查前可以做一些培训工作，向用户讲解调查的目的、任务、内容以及表达需求的文档，以便用户能够对需求进行检验和确认。培训工作日程也应该一并纳入到调查计划中。4.2业务流程调查4.2.1业务流程图绘制标准范例：4.2.2业务流程概要调查一般来说，反映总体业务概况的高层业务流程图只有一张，它描述了业务过程