Part 2(4-8).ppt

CH 4 项目初始阶段 特点 初试阶段信息并不充足 还没有项目的准备 需要尽快确定后续的工作 目标： 预见项目的范围、构想和业务案例 确定项目是否值得继续研究 工件（Artifacts）和文档 后续有用的工件 需要在后续迭代过程中进一步细化的工件 初始阶段的工件样例 构想和业务案例 用例模型 补充规范 术语表 风险列表和风险管理计划 原形和概念验证 迭代计划 阶段计划和软件开发计划 开发案例 CH 5 需求 瀑布法的需求 在设计前弄清需求 统一过程的需求 逐步细化的需求 允许需求的变化 需求分析的活动 活动和工件 FURPS+需求类型 FURPS 功能性(Functional) 可用性(Usablity) 可靠性(Rliability) 性能(Performance) 可支持性(Supportability) + 辅助需求 实现(Implementation) 接口(Interface) 操作(Operation) 包装(Packaging) 授权(Legal) 功能需求和非功能性需求 功能需求使用用例模型和系统特性表描述 非功能性需求可以使用系统的补充规范描述 CH 6 用例模型 用例模型（Use Case Model）是描述系统功能和环境的模型 用例是最好的理解和描述需求的办法 用例：使用系统时的情况 抛开人机界面分析系统的功能需求 用例分析 参与者：具有行为能力的人或者计算机系统。（于系统打交道的事物）。 场景：参与者与系统进行的交互活动。 成功场景 失败场景 分析场景（用例分析） 怎么才能为用户实现他们的目标，为用户提供可观察的返回值。 避免罗列功能清单 黑箱用例和系统职责 系统应该做什么，而不是应该怎么做。 用例的类型和格式 简洁用例 概要性的成功场景的文字描述。（例） 详述用例 详述用例的各个步骤和其中的变化，包括前置条件、扩展流程、变化情况、成功保障等。（例） 临时用例 临时的描述部分场景。 基本业务过程（EBP） EBP规则 以一个基本业务过程为单位来确定用例，就是基本业务过程级别的用例。 过高级别的定义无法清除的描述目标。 过低级别的定义不便于描述用户的真实意图和总体目标。 发现参与者、目标和用例 选择系统边界 找出参与者和目标 定义用例 选择系统边界 系统边界的不同，可能的参与者是不同的。 参与者actor 主要参与者 使用系统服务满足自己目标的。 寻求主要参与者是为了寻找目标，它驱动用例。 例如：收银员 次要参与者 为系统提供服务。 次要参与者可以说明外部接口。 例如：自动支付服务 后台参与者 对用例感兴趣的 为使系统能够满足所有需要。 例如：税务官员 定义用例 简洁书写形式 不去考虑用户界面 专注考虑用户意图 用例图 UML的用例图（use case diagram）用于表示用例和参与者之间的关系。 用例分析的主要结果是用例的文本，而不是用例图。 用例图可以起到对用例的直观引导作用。 POS系统的部分用例图 用例图的书写格式 用例图的书写（参与者） 用例的扩展 用例的包含 用例驱动的开发计划 统一过程（UP）中用例驱动的开发方式 开发团队以完成一个或几个用例为目标。 系统用例和业务用例 系统用例是系统环境中的参与者及其目标 业务建模中使用业务用例 例如：收银员（系统）、顾客（业务）、供应商（业务） 初始阶段不需要写出所有用例 CH 7 其他需求 补充规范 跨越多个用例的规范性描述 其他种类的需求（非功能性） P63 7.2 7.3 构想 项目计划(背景、定位、市场、系统特性、约束条件） P68 7.4 7.5 术语表 数据字典。原数据的说明和定义 CH 8 从初始到细化 初始阶段完成了什么 依据不同项目的主要需求 命名了大多数的参与者、目标和用例 用简短格式书写了大多数用例 风险需求（技术、进度、市场） 概念验证（关键风险技术可行性） 系统架构的构想 细化的工作计划 开发计划 规范 文档书写规范：格式、发布手段等。 开发计划 迭代过程 开发计划 POS系统的迭代计划 需求分析工具RequestePro 需求分析工具RequestePro * *