信息系统分析与设计教程第2章 需求调查.pptVIP

4、用例之间的扩展关系和包含关系 1、高层用例模型 高层用例模型的形成来自与高层的业务流程图，转换方法是：把高层业务流程图中的功能转换为用例，把参与某项功能的人转换为参与者。 总体用例模型 2、会员卡管理用例模型 3、会员档案管理用例模型 4、卡作业处理用例模型 5、统计分析用例模型 6、用例模型间的层次关系 泛化处理还可继续向上进行，泛化出一个“系统角色”参与者 1、检验用例模型与业务流程图之间的关系 最高层用例图中的用例应该与最高层业务流程图中描述的功能对应，并且名称也要尽量一致，每个用例实际上是一个相对独立的业务领域，是完整系统中的一个子系统。 其余用例模型中的用例应该与对应的业务流程图中描述的功能有对应关系，用例集合是功能集合的一个子集，也就是说，业务流程图中的所有功能并不一定都能实现，但用例一定与某个功能有全部或部分对应关系，不能凭开发人员的想象而增加用例。 2、用例模型的检验 用例模型检验主要考虑以下几个方面的问题： ①用例模型中，除扩展用例或包含用例可以没有参与者外，每个用例都应该有参与者，并且由参与者启动用例。 ②两个参与者之间不应该有“单向关联”线，即某个参与者不能启动另一个参与者。 ③例间的包含关系和扩展关系出现循环回路，在逻辑上是不合理的，应该重新考虑扩展用例或包含用例的设置问题。 ④如果发现有两个参与者共同启动一个用例，那么说明用例也还可以进一步分解。 ⑤每个用例应该是一个相对独立的功能，如果包含多个功能，那么可以考虑对用例的分解。 3、用例模型的完整性检验 与用户一起彻底检查每一个用例，确认其功能需求是否完整，用例的命名是否存在歧义，用例所表达的功能需求是否与用户的想法一致。 2.4.1 活动图 1、活动图要素 活动图由开始、活动、状态、同步条、判断、结束、迁移和泳道等图例组成 2、用例间关系的描述 以“会员卡管理”用例模型为例 3、用例内部的活动描述 以“申请制卡”为例 2.1.1 良好需求的特征 1、无歧义 2、可检验 3、确定性强 4、完整性 5、可跟踪性 6、正确性 1、阅读资料 2、构建术语表 3、制定调查计划 1、问卷 2、实地观察 3、面谈 4、查阅资料 业务流程的调查和分析采用自顶向下调查、自底向上补充完善的方法进行。 1、业务流程图基本符号 2、业务流程图示例 从系统的观点出发，系统具有可分解性、层次性和相关性，因此在需求调查时，首先将系统分解为若干个业务领域，即大粒度功能范围，确定待开发系统的边界，研究大粒度功能范围之间的关系，从而获得待开发系统的概况。 例如，商场提出要针对会员卡的管理构建一个会员卡系统. 会员卡管理总体工作流程是：商场计划部首先设计并制作会员卡，交给商场服务台，顾客填写后交还给服务员，由服务员为其建立会员档案，再由服务员进行卡作业处理，将办好的会员卡交给顾客，顾客便可持卡消费。商场统计部定期根据顾客消费情况进行统计分析，分析结果提交给计划部，为制订销售计划提供依据。 在获得概要需求后，开发人员与用户讨论协商，共同确定系统业务功能包括会员卡管理、会员档案管理、卡作业处理和统计分析等四个部分 总体业务流程图 绘制总体业务流程图时，值得注意的问题： ①流程图中所描绘的人员并非都是某个具体的角色 ②在流程图的绘制中除了按照规范要求使用规定符号、按照自顶向下原则绘制流程图外，还应该按照流程走向从左到右地制图，在制图中要尽量避免线条交叉 ③每一张图都要标注图名、设计人、制图人、校对人、检验人、确认人，以便对文档实施有效的跟踪管理 ④概要调查中还应该获取用户对系统的整体期望目标，以及非功能性的宏观需求，这类需求可以使用自然语言描述，并形成文档 1、会员卡管理的详细需求调查 2、会员档案管理的详细需求调查 3、卡作业处理详细需求调查 4、统计分析详细需求调查 1、业务流程图的内部检验 检查所有功能、文档、存储数据、人员的命名是否规范和正确。 存在问题的业务流程图 2、业务流程图之间相关性检验 检查所有业务流程图中的存储数据符号，观察是否存在所有功能都需要使用某个存储数据，而没有一个功能产生这个存储数据,如果存在这种现象，则说明遗漏了产生存储数据的功能。 3、完整性、正确性检验 完整性检验，主要是对照相关的资料，检查是否存在被遗漏的功能，为满足未来发展变化需要，考察是否需要增加应对未来发展变化的功能；检查功能描述所包含的内容是否完整和明确，是否存在歧义。 目前进行系统分析和设计大多采用面向对象方法，并用统一建模语言（Unified Modeling Language，UML）来描述，其中利用用例图构建的用例模型便是需求分析的工作产品，对业务流程中描述的功能进行分析产生系统的功能需求，用用例来描述，功能之间的关系也就是用例之间的关系则描绘成用例图。 1、用例 用例