软件工程—10—获得功能性需求2009.ppt

软件工程 第十一章 获取功能性需求 一、功能性需求 功能性需求 是用来描述系统能够提供哪些功能来解决用户提出的问题。 已经学习过的技术 结构化的功能模型 以数据流程图为核心，描述数据在流动加工过程中的变化，抽取功能模型。 面向对象的功能模型 强调人们日常描述问题的习惯和形式。 分析者总是利用情景或经历来描述用户和软件系统之间的交互方式，从而获取需求。 一、用例模型 用例的概念 一组用例的实例，其中每个实例都是系统执行的一系列活动，这些活动产生了对某个参与者而言可观察的返回结果。 用例描述了在不同条件下，系统对某一项目相关人员的请求所作出的响应，是系统中各相关人员之间就系统行为所达成的契约。 根据参与者作出的请求和请求涉及的条件，系统将执行不同的行为序列，每一行为序列被称之为一个场景。 一个用例是多个不同场景的集合。 1.用例的描述形式 用例实例 通过万维网购买股票 基本流程： 1、购买者选择通过万维网来购买股票 2、系统从用户那里得到所用站点的名称。 3、系统与该站点建立网络连接，并保持控制权 4、购买者在该站点上浏览并购买股票。 5、系统截取站点的响应信息，并更新购买者的记录 6、系统向用户显示更新后的记录情况 分支流程： 2a. 购买者要使用一个系统不支持的站点： 2a1.系统从购买者那里获取新建议，转向取消系统支持的用例。 3a. 在设置过程中，网络发生故障： 3a1.系统向购买者报告错误，并建议他退回到第一步 3a2.购买者或者退出用例，或者重新再试。 4a. 计算机系统崩溃，或在交易过程中被关掉 4a1.（这时我们该怎么办？） 4b. web站点没有及时认可此次购买活动，而是把它推迟处理： 4b1.系统把这次推迟事件记入日志，设置一个时钟，定期向购买者询问结果 含义 用例是一个自包含的单元 用例必须由参与者发起并监控 用例必须完成一个特定目标 用例应该使系统保持在稳定状态 用例是黑盒风格 需求并不是在项目一开始就很明确，往往是随着项目的推进，逐渐细化。 人的认知往往具有层次的特性。从粗到细、从一般到特殊。采用不同的层次来描述，适于认知的过程。 例子 用例的层次 高层次目标—概要级用例 低层次目标—用户级用例 用例模型 是所有书面用例的集合 是系统功能性和环境的模型 用例模型中可包括UML用例图，以显示用例和参与者的名称及其关系 用例的可视化描述 2.用例之间的关系 用例之间的联系 3.参与者 概念 也可称为执行者。 是任何具有行为的人或事物。 参与者和用例通信并且期待它的反馈——一个有价值或可觉察的结果。 参与者的类型有三种 主要参与者 具有用户目标，并通过使用当前系统的服务完成。例如，收银员。他们是发现驱动用例的用户目标。 协助参与者 为当前系统提供服务。例如，自动付费授权服务。协助参与者通常是计算机系统，但也可以是组织或人。通过协助参与者可以明确外部接口和协议。 幕后参与者 在用例行为中具有影响或利益，但不是主要或协助参与者。例如政府税收机关。幕后参与者的确定确保确定并满足所有必要的重要事务。如果不明确地对幕后参与者进行命名，则有时很容易忽略其影响或利益。 4.用例的描述方法 三种常用形式 摘要 简介的一段式概要，通常用于主成功场景 非正式 非正式的段落格式。用几个段落覆盖非正式场景 详述 详细编写所有步骤及各种变化，同时具有补充部分，如前置条件和成功保障。 用例是文本形式的。 详述形式的用例模板内容 二、由事件表向用例的转化 将事件表按照参与者分组 对事件进行归类，命名具有群集趋向的事件 这些事件的共同点是什么？ 这些事件有相同的最终目标吗？倘若有，目标是什么？ 采用用例图描述分析的结果 用例产生的过程 列出事件清单 将MSMS项目事件表进行分组 整理后的用例图 对用例的描述 摘要式描述 非正式形式的样例项目用例 详述形式的样例项目用例 练习：将RP项目事件表进行分组（原始表） 对事件按照参与者分组后的事件表 三、用例编写的准则 显示执行者的意图，而不是动作 修改前 顾客使用ID和密码进入系统 系统验证顾客身份 顾客提供姓名 顾客提供地址 顾客提供电话号码 顾客选取商品 顾客确定购买商品数量 系统验证是否为老顾客 系统打开库存系统的连接 系统通过库存系统请求当前库存量 库存系统返回当前库存量 系统验证购买商品的数量是否足够 修改后 顾客使用ID、密码进入系统 系统验证顾客身份 顾客提供姓名、地址、电话号码 系统验证顾客是否为老顾客 顾客选择购买商品及相关数量 系统有库存系统验证购买商品是否有足够库存 …… 从俯视的角度编写用例 修改前 系统读取ATM卡和PIN号码，并从账号余额中扣除一定数量 修改后 用户插入ATM卡并输入PIN号码 系统从