第二部分 软件需求.ppt

  1. 1、本文档共35页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
第二部分 软件需求

第二部分 软件需求 主要内容 RUP中的需求流程 用例模型 术语表 补充规约 检查点 案例实践 RUP规程中的需求 需求工作流 相关需求制品 案例学习:课程注册系统 浏览课程注册系统的问题陈述文档 第二部分 软件需求 主要内容 RUP中的需求流程 用例模型 术语表 补充规约 检查点 案例实践 什么是用例模型 用例模型是以用例和参与者的形式描述系统的功能需求的模型 用例方法的优点 交流 标识 验证 建立用例模型 使用用例的方法来描述系统的功能需求的过程就是用例建模 步骤 确定参与者 确定用例 描述用例规约 检查用例模型 确定参与者 通过提问发现系统参与者 使用系统主要功能的人是谁 系统要从哪些人或系统获取数据 系统为哪些人或系统提供数据 系统会与哪些其它系统相关联 系统由谁维护和管理 参与者示例 学生——注册课程 教授——选择课程来教 注册员——维护教授和学生的信息 财务系统——从注册系统获得学生的费用情况 课程目录系统——维护课程信息 确定用例 通过提问发现系统用例 参与者为什么要使用该系统 参与者是否会在系统中创建、修改、删除、访问、存储数据;又是如何来完成这些操作的 参与者是否会将外部的某些事件通知给该系统 系统是否会将内部的某些事件通知该参与者 用例示例 无论是学生,教授还是注册员都需要登陆到系统 学生需要使用系统来注册课程,也能查看自己的成绩 教授需要使用系统来选择课程,也能记录学生的成绩 注册员必须维护学生、教授的信息,并在适当时候关闭注册系统 当选择课程的过程完成后,收费系统必须获得收费信息 学生和教授选择课程,需要启动课程目录系统 可以生成以下用例: 登陆系统;注册课程;查看成绩;选择课程任教;提交成绩;维护教授信息;维护学生信息;关闭注册 用例规约 名称 简要说明 事件流 关系 活动图 用例图 特殊需求 前置条件 后置条件 其它图 描述用例 —— 事件流 事件流描述对话的细节,包括 一条基本流 几条备选流 常规的异体 单数的案例 异常流 处理出错情况 什么是场景 场景是用例的实例 事件流的格式 基本流 用数字编号标明步骤的先后顺序 概括每一步的主要内容 备选流 起点:该备选流从事件流的哪一步开始 条件:什么条件会触发该备选流 动作:系统在该备选流下会采取什么动作 恢复:该备选流结束后,用例如何继续执行 登录系统的事件流 基本事件流 1.当学生/教授/登记员要求登录该课程注册系统时,系统要 求输入其用户名及密码 2. 学生/教授/登记员输入其用户名及密码 3. 系统进行用户名和密码的验证 A1:无效的用户名 A2:密码错误 4.学生/教授/登记员登录系统,进行其它操作 备选事件流 A1:无效的用户名 1.系统显示用户名错误 2.返回基本事件流第1步 A2:密码错误 1.系统显示密码错误 2.返回基本事件流第1步 描述用例 —— 活动图 登录系统的用例规约 简要说明: 学生在进行课程注册前必须先登录该系统;教授也需要先登录才能进行选择课程等操作;登记员也必须登录后才能进行有关信息的维护 事件流: 略 特殊需求: 无 前置条件: 学生/教授/登记员有正确的用户名和密码 后置条件: 成功登录后,学生/教授/登记员可分别进行相应权限内的操作;如果登录失败则不能进行任何操作 案例学习:用例规约 浏览关于注册课程用例的用例规约 (后续的分析设计都与该用例有关) 第二部分 软件需求 主要内容 RUP中的需求流程 用例模型 术语表 补充规约 检查点 案例实践 术语表 案例学习:术语表 浏览课程注册需求文档提供的术语表 第二部分 软件需求 主要内容 RUP中的需求流程 用例模型 术语表 补充规约 检查点 案例实践 补充规约 功能性 可用性 可靠性 性能 可支持性 设计约束 补充规约示例 浏览课程注册需求文档提供的补充规约 第二部分 软件需求 主要内容 RUP中的需求流程 用例模型 术语表 补充规约 检查点 案例实践 检查点:需求分析:用例模型 用例模型是否易于理解 通过用例模型能否对系统的功能和它们的关系有清楚的认识 所有功能需求是否都已经满足 模型中是否有多余的行为 模型是否需要分成为包 检查点:需求分析:参与者 是否确定了所有的参与者 每个参与者是否至少与一个用例有关 参与者是否需要合并或分解 一个用例中是否有两个参与者起同样的作用 用例是否有能使所有人都理解的直观的名字 检查点:需求分析:用例 每个用例是否至少和一个参与者 有关 每个用例是否都是独立的 是否存在用例有相似的行为或事 件流 用例是否有唯一并且直观的名字 所有人对用例的名字和描述是否 有一致的理解 检查点:需求分析:用例规约

文档评论(0)

wyjy + 关注
实名认证
内容提供者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档