软件工程 一体化案例分析教程（四）第4章 需求 Requirements（杜育根）.pptVIP

 软件工程一体化案例分析教程（四） 杜育根 本PPT教材： 杜育根. 软件工程教程：IBM RUP方法实践[M]. 北京：机械工业出版社，2013 第4 章 需求Requirements 4.1 需求概述 需求的定义 需求建模的作用 “系统必须符合的条件或具备的能力” FURPS+ 模型 [GRA92] 功能性 可用性 可靠性 性能 可支持性 设计约束 实施需求 接口需求 物理需求 FURPS+ 中的“+” FURPS 需求的重要性 4.1.1 功能性需求 Functional requirements 4.1.2 非功能性需求Non-functional requirements 非功能性 需求 质量 约束 4.2 需求工作流程 分析问题 1 管理变更需求 需求工作流程图 4.2.1 分析问题Analysis the Problem 参与分析问题的项目成员通过组织协调，应用一定的经验和技巧，与 项目各种各样的涉众进行讨论、沟通，找出隐藏在问题之后的问题。 4.2.2 理解涉众需求Understand Stakeholder Needs 目的：从主要的项目涉众中获取他们关于期望得到或设想的产 品的信息，来理解他们的真实需要。 表4-1 RequisitePro 工具的一组特性及对应需求属性 4.2.3 定义系统Define the System 4.2.4 管理系统范围Manage the Scope of the System 4.2.5 精化系统定义Refine the System Definition 目的：进一步精化需求，以对系统定义的理解达成共识。 4.2.6 管理变更需求Manage Changing Requirements 4.3 需求关键任务 需求关键任务流图 4.3.1 引发涉众请求Elicit Stakeholder Requests 4.3.2 开发愿景Develop Vision 4.3.3 查找执行者和用例Find Actors and Use Cases 识别执行者 执行者分主执行者和辅助执行者 时间作为执行者 （a）时间作为执行者 （c）两者结合的方法 （b）与用例交互的执行者接受用例的输出 案例分析：学院门户网站的Actor 案例分析：教务学分查询系统的Actor 识别系统用例 如何查找用例？ 案例分析：学院门户网站的用例 案例分析：学院门户网站的用例（续） 学院门户网站中业务用户的用例 学院门户网站中所有用户的公共用例 案例分析：教务学分查询系统的用例 Email提醒方面的用例 学分管理方面的用例 4.3.4 划分用例优先级Prioritize Use Cases 表4-2 多种设定需求优先级的规模 表4-3 用例或需求特性级别的相关属性打分 属性打分表 4.3.5 结构化用例模型Structure the Use-Case Model 1.建立用例间的包含关系（Include-Relationship） 学院门户网站用例中的包含关系 2.建立用例间的扩展关系（Extend-Relationship） 教务学分查询系统用例中的扩展关系 表4-4 包含和扩展关系的关键差异 学院门户网站用例中的泛化关系 3.建立用例间的泛化关系generalization-relationship 4.建立执行者间的泛化关系 执行者会有通用的特征，这是应该使用执行者泛化关系来构建模型， 写一个执行者泛化关系的简单说明，并将它们包含在用例图中以便 进一步阐述。 执行者之间的泛化 5.将用例模型内容组织到包中 如果用例模型中具有大量元素，则可考虑将用例组织到用例包 中。用例包是用例、执行者、关系、图和其它包的集合，用于 通过将用例模型分成更小的部分来结构化用例模型。 案例分析：学院门户网站的用例包 （a）管理用户用例包图 案例分析：学院门户网站的用例包（续） （b）管理角色用例包图 案例分析：学院门户网站的用例包（续） （c）查看模块及子系统用例包图 案例分析：学院门户网站的用例包（续） （d）系统访问用例包图 案例分析：教务学分查询系统的用例包 （a）学分管理用例包 案例分析：教务学分查询系统的用例包（续） （b）Email管理用例包 4.3.6 详细描述用例 正常过程(normal course) 有一种场景被视为用例的正常过程(normal course)，也叫作 主过程（main course）、基本过程，正常流，或“满意路径” (happy path)等等。 可选过程(alternative course)。 在用例中的正常场景外的其 它场景可以描述为可选过程。 可选过程也可促进成功地完 成任务，但它们代表了任务 的细节或用于完成任务的途 径的变化