软件工程11获得功能性需求.ppt

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