04_OOAD-UML_04.ppt

为了有效地收集需求，您需要遵循预先定义的方法。例如，您需执行以下活动以收集需求： 会见项目干系人。 在项目干系人之中举行一场集体讨论会。 准备调查问卷。 观察企业的现有流程。 约见领域专家。 设计故事版方式 需求收集技术 需求分析指将需求分类和组织为功能性需求和非功能性需求的过程。 非功能性需求指软件系统的隐含特性。 非功能性需求通常不直接表示软件系统的功能。 需求分析和协商 软件需求规范（SRS）是详细分析任务后产生的文档。 SRS 必须提供以下信息： 软件系统定义 SRS 文档的用途 软件系统的范围 功能性需求 非功能性需求 目标软件系统的运行条件 需求规范 需求验证是在指定所有需求后对需求进行验证的活动。 需求验证包括： 确定所有的模糊需求 确定每条需求的来源 说明需求数量 确定需求之间的依赖关系 验证需求是否简明、可测试并且可跟踪。 验证需求与软件系统中的约束是否有冲突 需求验证 用例关系图： 显示目标软件系统的用例和角色之间的交互关系。 显示用例之间或角色之间的关系（如关联和泛化等）。 用例可以（文本方式，活动图等方式）描述外部实体与软件系统之间的交互过程。 用例应该包含以下特征： 向角色提供服务 提供明确而又简要的功能描述。 创建用例关系图以进行系统建模 用例应包含以下信息： 名称 概要 事件的基本过程 可选路径 异常路径 触发器 假设 前置条件 后置条件 业务规则 非功能性需求 作者 日期 创建用例关系图以进行系统建模 (续) 系统角色是与软件系统交互并影响系统功能的外部实体。 系统角色可以被分成以下几类： 主要角色： 直接与系统交互并启动用例。 次要角色： 不直接与系统进行交互但能启动主要角色与系统的交互。 创建用例关系图以进行系统建模 (续) 与角色有关的关系有两种类型： 泛化关系： 存在于有类似的行为和特性的角色之间。 关联关系： 显示用例与角色之间通信路径。 关联用箭头或单线条表示。 箭头显示单向通信的方向，线表示通信是双 向的。 创建用例关系图以进行系统建模 (续) 问题陈述： InfoSuper 银行是一家著名的金融机构，其客户遍布全球。该银行向客户提供以下服务： 企业银行业务 个人银行业务 共同基金 理财服务 住房贷款 InfoSuper 银行 45% 的收入来自个人银行业务。因此，银行希望进一步提升个人业务的服务质量并争取留住客户并提高他们的忠诚度。该银行进行了一次市场调查以了解客户在个人银行业务处理时间、满意度和资源需求方面的要求。 演示：确定 InfoSuper 银行需求和创建用例关系图 (续) 调查结果显示为了来办理银行事务（如，提取现金、支票存款、和获取交易概要等），一个客户平均每月要跑 10 到 15 趟银行。 银行希望开发一个软件系统以通过改进的设施来减少客户访问银行的次数并提高客户服务。为此 InfoSuper 银行的代表找到了软件开发商 Janes Technologies 公司。 在分析了银行的需求文档后 Janes Technologies 公司项目经理 Jennifer 建议银行开发自动取款机（ATM）系统提供以下功能： 现金提款 现金存款 交易概要 更改 PIN 演示：确定 InfoSuper 银行需求和创建用例图 (续) 同行转帐 有关银行提供的其他服务的信息 还需要在部署 ATM 系统的地方提供箱子以供客户丢弃支票及请求支票簿。 演示：确定 InfoSuper 银行需求和创建用例图 (续) 解决方案： 要设计 ATM 系统，需要执行以下任务： 确定需求。 创建 SRS。 确定用例。 确定角色。 描述用例和角色之间的关系。 保存模型。 演示：确定 InfoSuper 银行需求和创建用例图 (续) 在这一单元中，您学习了： 业务建模和系统建模分别构造系统的行为模型和功能模型。因此，它能够使您发现当前系统存在的问题，并了解目标系统的需求。 在开发系统时，确定项目干系人并了解他们的需要非常重要。 需求管理是指使您能够系统化地管理软件开发过程中涌现的需求的活动。 需求管理包含各种活动，例如需求收集、需求分析和协商、需求规范和需求验证。 小结 Slide ?#? of 29 Ver. 1.0 使用 UML 的面向对象分析和设计 2 告诉学生当你们承担了软件项目的开发任务时你们应利用项目提供的所有需求来作初步计划。如果不能明确理解现有流程的需求，将会导致设计新软件系统时进行重复劳动。 接着，解释新软件系统定义中的各个阶段。 3 解释分析问题后建立的问题陈述的成分。解释分析问题时使用的两类建模技术。 4 当讨论业务建模概念时，要强调区分业务角色和业务执行人的因素。业务角色启动或触发业务场景中的事件。业务执行人包含在事件或流程中。在解释医