软件需求提取与分析_第1页
软件需求提取与分析_第2页
软件需求提取与分析_第3页
软件需求提取与分析_第4页
软件需求提取与分析_第5页
已阅读5页,还剩45页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

软件需求提取与分析 主讲 周荣辉 需求分析的重要性 需求分析的目标是为系统设计和实现提供足够的指导和信息支持 如果需求分析不充分 则设计和实现很难进行 如果设计和实现中涉及的内容无法与需求建立对应关系 则显得多余 对论文而言 就是失败之作 软件开发类论文评价的基本标准之一 需求与设计和实现的一致性 即任何需求必须在设计和实现中得到体现 任何设计与实现必须与需求有对应关系 需求分析概述 在传统的软件工程中 需求分析作为软件生存周期的一个阶段 尽管有需求获取和分析的两个任务 这两个任务没有严格地划分时间段 在需求获取过程中要进行分析 在分析过程中要不断地进行调研和完善 需求获取和需求分析的工具都是采用数据流图和数据字典 明确地指出需求分析报告主要用于用户交流 在统一过程和UML提出后 特别是软件迭代开发方法提出后 把需求和分析分成了两个不同的阶段 有时也叫需求获取 或需求捕获 和需求分析 每个阶段有完全不同的目标和任务 包括建模工具和建立的模型都完全不同 需求捕捉阶段主要采用用例模型捕捉功能需求 需求分析阶段主要采用对象模型 建立领域对象间的协作关系 需求获取所建立的模型主要用于与用户交流 需求分析模型是开发组织自己的文档 不用于与用户交流 需求分类 1 功能性需求 系统应该提供什么功能 2 非功能需求 系统的特定特性或约束 软件运行期质量 用户在使用软件过程中对软件质量的要求 包括 易用性 指软件系统容易使用的程度 性能 指软件系统及时提供相应服务的能力 性能包括响应时间 吞吐量 持续高速性 安全性 指软件系统同时兼顾向合法用户提供服务 以及防止非授权使用的能力 持续可用性 指软件长时间无故障运行的能力 如有的系统要求提供7 24小时服务就是持续可用性的要求 可伸缩性 指当用户数量和数据量增加时 软件系统维持高服务质量的能力 互操作性 指本软件系统与其它软件系统交换数据和相互调用服务的难易程度 可靠性 软件系统在一定时间内无故障运行的能力 鲁棒性 也称健壮性 容错性 有时也把持续可用性 鲁棒性也归类为可靠性 软件运行期质量 为保证软件的可维护性而在软件开发过程中应该关注的软件质量属性 有时将其称为隐含质量属性 包括 可扩展性 为适应新需求或需求变化为软件增加功能的能力 有时称为灵活性 可重用性 重用软件系统或其一部分的能力的难易程度 可测试性 对软件测试以证明满足需求规约的难易程度 在实际工作中主要指进行单元测试 插桩测试的难易程度 可维护性 在修改Bug 增加功能 提高质量属性等而定位修改点并适时修改的难易程度 可移植性 将软件系统从一个运行环境转移到另一个运行环境的难易程度 易理解性 设计被开发人员理解的难易程度 任何一个开发期质量属性的满足都可能增加软件开发成本 约束 约束不是行为 是设计或项目的限制条件 强调其限制性 新系统的开发无法回避这些事实或因素 约束主要包括 系统开发的资源约束 如网络环境 操作系统 数据库管理系统 开发工具 硬件等 新系统的开发必须考虑这些资源的有效利用和限制 接口约束 本系统关联的系统是哪些 新系统可能接受其它系统提供的数据作为输入 其输出数据作为其它系统的输入 操作约束 系统操作环境中的管理要求 如身份认证必须通过第三方认证机构的认证 以网络为基础的业务处理 在网络不通的情况下如何处理业务等 政策约束 行业标准 企业标准 法律法规 政府规章等 需求的层次性 组织的不同层次人员对需求不同 通常有三个层次 业务需求 组织要达到的目标 业务目标用户需求 用户使用系统来做什么行为需求 开发人员需要实现什么高管人员希望软件系统能帮助他们达到业务目标 系统实际使用者希望系统提供的能力能辅助他们更好地完成日常业务工作 开发人员为满足用户诸多需求而觉察到的需求 高层管理人员的需求与系统实际使用人员的需求可以起到相互验证和印证的作用 如果不关注 高层管理人员 的要求 系统开发就没有明确的目标 系统的功能将是零散而脆弱的 极易受到变更的冲击 不满足开发人员的要求 软件的开发 维护和移植变得非常困难 需求提取内容 确定业务目标 确定业务范围和业务流程 建立用例模型 建立用例规约 确定非功能需求 确定业务目标 业务目标系统开发中占有非常重要的位置 它明确规定了建立该软件系统的最终目的 业务目标是客户方高层对未来系统的期望 通过确定业务目标可以避免系统解决的问题的层次太低而很快过时 项目业务目标要避免太抽象 太空洞 如 实现XX信息化 一个项目管理系统的业务目标定义为 帮助项目经理更好地控制项目 帮助项目经理更有效地分配资源 帮助项目成员之间更流畅地协作通过细化业务目标 列出一组高度概括的功能性需求 如业务目标 帮助项目经理更好地控制项目 的特性有 任务管理 跟踪进度 查看报表 任务分配和重分配 确定业务范围和业务流程 业务目标的实现需要通过具体的业务领域 有时也称职能域 以及具体的业务及业务流程来体现 使业务目标落实到实处 这将引起企业组织机构的调整和业务流程重组 以满足业务目标的要求 业务 有时也称业务过程 是需要做的相对独立的工作 或任务 业务流程 是完成工作所经历的业务活动及顺序 业务活动 是基本的 不可再分的最小功能单元 通常指一个人在一个地点一个不可间断的时间内可以完成的工作 建立用例模型 所谓用户需求 就是用户希望软件系统能为他做什么 用例图技术是捕捉用户需求最合适的技术 用例名是用户需求最直观 最简便的反映 业务流程分析将捕捉到大部分用例 但不是全部用例 还需要补充一些与管理人员相关 但与具体业务活动不一定直接相关的用例和与信息查询相关的用例 建立用例规约 用例是用户 希望如何做 的行为需求 这里的 如何做 是从用户角度看他们 希望如何做 而不是软件系统是如何做 所以还是属于需求捕捉的内容 用户 希望如何做 是软件系统 如何做 的依据 在用例规约中 将详细定义用户对用例运行期间的质量要求和约束 不一定所有用例都要建立用例规约 有的用例使用 用例简述 就足够了 如果一个用例基本事件流对需求分析人员来说不是很清楚 而且可能涉及到非功能要求 就需要用 用例规约 来详细描述 确定非功能需求 通过对用例规约的分析和总结 归纳出系统的非功能需求 特别是用户对系统运行期的质量需求和约束 用例规约是系统运行期质量需求和约束的主要来源 一般来说 开发期质量属性需求主要来自系统开发人员和维护人员 通过成为隐含的非功能需求 要善于抓住对用户来说至关重要的非功能需求 这种非功能需求往往决定系统的命运 如特殊的性能问题 特殊的安全性问题 典型的运行机制问题 若存在与其它系统的交互 互操作性是必须考虑的 特定的约束对系统的制约是架构设计必须考虑的问题 需求建模方法 需求提取的建模包括业务建模和用例建模 业务建模是确定项目对应的业务领域所包含的业务和业务流程 并用所选择的业务流程描述工具进行描述 用例建模是以用例为基本单位来描述用户的功能需求 与用例模型相关的概念包括 参与者 用例 场景 需求建模 参与者 直接与系统交互的外部事物所扮演的角色 参与者对系统而言是外部的 参与者直接与系统交互 直接使用系统来支持其业务 强调参与者所扮演的角色 而不是特定的人或事物 时间可以作为参与者 通常用时间发生器来表示 参与者主要指系统业务功能的使用者 系统管理员不是这种意义的参与者 因为他不是使用系统功能完成与单位业务有关的工作 他使用系统的辅助功能实现对特定的人及其角色的管理 使参与者在自己角色范围内使用系统 每个参与者使用一个具有业务意义的名称命名 需求获取的首要任务就是识别主要参与者 识别参与者是需求提取的首要任务 谁是系统的客户 他们需要系统做什么 他们希望在什么时候 什么地点做 这些都是系统设计要考虑的重要因素 需求建模 用例 用例是参与者想要系统做的事情 具体表现为用户如何使用系统来达到其目标的一组情节 例如在超市 处理销售 的用例描述为 一个顾客携带欲采购的商品到达收费口 收银员使用系统输入商品信息 系统给出商品的清单和累加值 顾客交款 收银员输入支付信息 系统对付款信息进行计算 更新库存信息 并给出余额信息 系统打印购物清单 顾客得到收据 然后携带商品离开 只有对用例表现出的情节进行真实 完整 准确地描述 才能捕捉到对系统需求有价值的东西 需求建模 用例的粒度 指导原则1 在进行需求获取时 应专注于 基本业务过程 EBP 级别的用例 基本业务过程 由一个人在某个时间某个地点执行的一项任务 这个任务是对某一个业务事件的反应 而且可以增加可度量的业务价值 并且能够保持数据状态的一致 用例没有层次结构的概念 即用例就是系统参与者要系统帮助干的一件不可细分的事情 不存在把一个用例分解成粒度更小的用例 EBP级别的用例就是用户对系统的业务功能需求 在进行需求获取时 应主要关注EBP级别的主要用例 通常称他们为基本用例 比基本用例粒度小的用例可能完不成 可度量的业务价值 的一件事情 比基本用例粒度大的用例可能需要多个参与者去完成或多个时间段去完成 用例的命名必须具有明显的业务领域特征 需求建模 用例与目标 参与者都有自己的目标 并使用系统来帮助自己实现目标 一个EBP级别上的用例通常被称为一个用户目标级别上的用例 以强调用例应该帮助系统的用户实现自己的目标 这里强调 用户目标级别 不是企业目标 组织目标 系统目标 防盗 是企业级目标 不是用户级目标 因此不是一个EBP 向系统证明身份并被验证 也不是一个EBP 因为它没有增加可见的或可以度量的业务价值 登录 是一个次要目标 是为其它有用的事情服务的 如 我今天登录了20次 不会留下任何有价值的东西 用户管理 是系统目标 不是用户级目标 需求建模 可观察的返回值 每个用例的实例产生了对特定参与者而言可观察的返回值 可观察的返回值实际上是告诉参与者是否实现了其业务价值 如果一个用例不会告诉参与者任何东西 对参与者来说 它没有任何价值 这肯定不是参与者的目标要求 需求建模 场景 场景 参与者与系统之间的一系列特定的活动和交互 通常称为 用例的实例 场景是使用系统的一个特定情节或用例的一条执行路径 一个用例就是一个描述参与者使用系统来达到目标的一组相关的成功场景和失败场景的集合 例如 客户在超市选择购买的商品后到收银台验货和付款中 收银员扫描仪录入商品数据 顾客交款 收银员退余款 打印购物清单 是一个场景 同样 收银员扫描仪录入商品数据 顾客交卡 收银员刷卡 打印购物清单 也是一个场景 收银员扫描仪录入商品数据 顾客交卡 收银员刷卡 卡中钱不足时 顾客交款 收银员退余款 打印购物清单 还是一个场景 场景可分为主要场景和次要场景 一个用例只有一个主要场景 但可以包含多个次要场景 每个场景表示参与者达到其目标的一个情节 在主要场景中 如果与某一步所希望的事件不同 就会引出一个次要场景 需求建模方法 识别主要参与者 系统主要参与者就是系统的业务用户 在这里 我们反复强调 业务用户 因为开发一个软件系统的目的就是为他们的业务工作服务的 这是系统的价值所在 在识别系统主要参与者时的首要工作就是列出所有系统最终用户 任何人 只要他需要使用系统来行使自己的 职责 哪怕只有一小点 职责 他就是系统的主要参与者 主要参与者不是具体人 而是抽象的职能名 但也不能太抽象了 以致无法辨认他们的脚色 有的主要参与者的大部分业务工作都可能需要系统支持 如学校的 教务管理员 有的主要参与者可能很少使用系统 如各个 审批 人员 当别人把所有工作都作了 他只需 审核 一下就行了 在识别主要参与者的过程中 最容易把这些大量的干 审核 或 审批 的主要参与者忽略掉 因为他使用系统的时间很少 就认为他不是主要参与者 需求建模方法 识别系统业务 一个业务 有时呈业务过程 指一件有始有终要干的事 多个业务之间可能没有明显的界限 需要对业务领域有深入的了解和丰富的经验积累 如教学管理的业务科分为 教学计划管理教学安排选课管理考试管理成绩提交成绩更正每个业务都有一个持续的时间区间 可能有多个人相互协作 有多个业务活动按照一定顺序和规则进行 用例建模方法 业务流程建模 每个业务都有一个持续的时间区间 通过多人相互协作 使多个业务活动按照一定顺序和规则进行 由此构成了完整的业务流程 其中的每一个业务活动的完成都对应着一个用户目标 实现这些目标的软件功能都可以抽象为一个EBP级别的用例 业务流程分析是最关键的需求分析 是系统功能需求的主要来源 可以捕捉80 的功能需求 遵循的基本原则 每个业务活动只有一个人在特定的地点和特定的时间完成 无论再小的事情 如果要多个人完成 或必须在多个时间完成 或可能 必须 在多个地点完成 就要分解成多个业务活动 业务流程描述工具 活动图 椭圆 活动 分叉 并发转移汇合 并发后的交汇 分支 条件转移合并 开始状态 可选结束状态 可选 业务流程描述工具 活动图 泳道 把一个活动图的矩形框垂直分成若干个区域 每个区域为一个泳道 对应着一个业务参与者 将参与者参与的活动画在该矩形区域内 带有泳道的活动图被认为是业务建模的最优秀的方法和工具 业务流程描述工具 活动图实例 提交成绩更改申请 提交成绩更改意见 更改 更改确认 更改确认 成绩更改 成绩更改查阅 Y N 成绩更改业务流程 需求建模方法 建立基本用例模型 如果活动图中每个活动只限于一个泳道 在一个地点一个时间内可以完成 则一个活动就是一个EBP级的用例 所谓基本用例指一个EBP级别的用例 基本用例模型指由基本用例构成的系统功能模型 在基本用例模型中 除了参与者与用例之间的关联关系外 用例之间是相互独立的 这种独立性是用例完整性的体现 基本用例模型中的参与者就是系统权限管理中的角色 基本用例模型中的用例是系统权限分配的基本对象 参与者与基本用例的关联关系就是系统中角色与资源 功能模块 之间的映射关系 所以 基本用例模型是系统角色与权限管理设计的依据 每个用例是系统实现的基本功能单元 需求建模方法 基本用例模型 用例图 用例图 以用例为基础的系统功能模型的图式表示 是用例模型的抽象描述 用例图包括参与者 角色 系统边界 用例 参与者与用例的关联关系 系统边界用矩形框表示 通过矩形框的边线明确划分系统内和系统外 用例用椭圆表示 椭圆内放用例名 用例放在矩形框内 表示是系统内部元素 参与者用 稻草人 图符表示 参与者放在矩形框外 表示参与者是与系统有关的外部元素 是系统的直接使用者 系统名放在矩形框内顶部 需求建模方法 基本用例模型 用例图例 提交成绩更改申请 提交成绩更改意见 成绩更改查阅 更改确认 成绩更改 学生 教务员 教师 系主任 院长 需求建模方法 基本用例模型 用例规约 一个用例在功能上具有完整性 首先 从系统的角度而言 每个用例都必须从输入开始 直到产生结果输出给参与者 否则就不成其为一个用例 其二 用例刻画系统的功能需求 但它不是简单地记录功能需求 而是要完整地描述系统功能 包括用例执行的步骤 执行过程中可能产生的诸多变化情况 错误情况和异常情况 所以 用例图只是系统功能的抽象描述 还必须通过用例规格说明进行详细描述 才能充分反映用例所包含的内涵 需求建模方法 用例关联 用例可以相互关联 用关系来描述用例之间的关联 关系只是一种组织机制 用于改善用例的交流和理解 减少文本的重复说明 在用例建模中 为了使用例更简洁 在用例模型中引入了两种关系 包含关系 include 也称使用关系 uses 扩展关系 extend 需求建模方法 用例关联 包含关系 包含关系 include或use 指一个用例包含另一个用例 被包含的用例通常是包含用例的一部分 即是包含用例对应的功能需求的子功能 在用例模型中 如果发现某些用例具有部分相似的行为 则可以把这部分相似的行为抽取出来单独作为一个 抽象用例 供它们使用 由此构成了用例之间的 包含 关系 必须强调被包含用例一定是包含用例的一部分 具体体现在 如果包含用例被执行 被包含用例一定被执行 指导原则 当两个或两个以上独立的用例中有重复的内容而要想避免这种重复时 可以应用包含关系 在上例中 教师 提交成绩更改意见 和主管责任人 更改确认 都要先 查询成绩更改单 所以可以把 查询成绩更改单 作为两个基本用例的被包含用例 需求建模方法 用例关联 扩展关系 每个基本用例 都有一个基本的成功场景 除此之外 可能还有其它成功场景 对其它成功场景 可以用一个扩展用例来描述 扩展关系指一个用例的某个行为可能被另一个用例扩展 如顾客在超市购买商品 一般用现金支付 但还有其他支付 如储蓄卡 代购卷支付 可以把 现金支付 作为 基本 行为 把其他每种支付作为一个 特殊 行为 在用例建模中 把这种 特殊 行为作为扩展用例 被扩展的用例本身是完整的 扩展用例只是在遇到对应特殊情况时才可能被调用执行 指导原则 对插入基用例的条件或可选行为建模 如 提交成绩更改申请 过程中 可以增加 保存申请草稿 和 读取申请草稿 可以显得更灵活一些 需求建模方法 优化后的用例建模 提交成绩更改申请 提交成绩更改意见 成绩更改查阅 更改确认 成绩更改 学生 教务员 教师 系主任 院长 保存申请草稿 读取申请草稿 查询成绩更改单 Include extend 领域建模 基本任务 分析的基础是用例模型 最重要的是用例规格说明 分析的基本任务是从用例规格说明中提取出重要的业务领域概念 建立领域模型 领域模型是系统分析师对待开发系统所属领域的理解 是对用例模型中所涉及的对象及其关系的抽象 因此 领域模型不是与用户交流的工具 而是对领域抽象的工具 因为领域用户只能提出要求系统做什么 基本上不知道 也不懂得计算机领域有关对象的概念 业务流程图和用例模型才是与用户交流的工具 领域建模 领域模型 领域是待建软件系统所面对的特定的业务领域 领域模型是对实际业务领域的抽象 它 穿透 用户想要的功能的表象 专注于分析业务领域本身 发掘重要的 最为稳固的业务领域概念 并建立业务领域概念之间的关系 在领域建模中 一个被管理领域对象就是一个概念类 即一个概念类就是观察问题的一个视点 事物或者对象 领域模型是意义显著的领域概念和词汇的一个可视化表示 也称为概念模型 领域对象模型 领域建模是面向对象分析的核心工作 特别声明 领域模型中只涉及领域概念 表示的概念是特定领域 问题域 的概念 如订单 发票 提货单 而不是订单关系表 提货关系表 接口 方法等 不涉及与系统实现相关的任何计算机术语 领域模型不会因系统功能变化而变化 领域建模 领域模型的表示 建立领域模型时 通常用类图和状态图来描述 在UML中 领域模型可以用不定义操作 领域建模 领域概念的识别 领域概念的明显特点是问题领域中的专门名词 领域词汇 例如在线拍卖系统的词汇表为 拍卖 一种销售方式 将拍卖项卖给竞拍价格最高者 拍卖活动 一次拍卖的组织 拍卖项 拍卖的物品的统称 起拍价 一开始的竞拍最低价成交价 拍卖结束时刻的最高竞拍价 买家 参与竞买者 卖家 提供货物 并以拍卖方式出售货物者 成交 以符合拍卖活动规则的方式 拍卖项的所有权从卖家过让为竞拍价格最高的买家 买家按成交价支付 词汇表中的词汇不一定都是领域模型中的类名称 但一定包含了所有类名称 拍卖活动 拍卖项 买家 喊出 成交价的买家 卖家 一些词汇描述了对象之间关联 如 成交 或者对象的关键属性 如 起拍价 成交价 领域建模 拍卖领域模型 领域建模 领域概念类的识别 产品订购单 领域概念类的识别 领域概念类 产品订购单 属性包括 编号 填单日期 要求发货日期 实际发货日期订购车辆 订单的一行描述了一个订购的车辆 属性包括 编号 其它特征 数量 表格中 型号 驾驶室 后桥 车厢 柴油机 轮胎等称为产品的配置 但又是一种产品 有它们自身的属性 表格中只填它们的标识码 其中 型号 不是一个简单代码 而是代表一种车型 所以 型号 用概念类 车型 更容易理解一些 订货单位 订货单位负责人 销售部 业务员 评审人 汇款单等都是与订单相关的概念 领域建模 产品订购领域模型 规格说明概念类 用领域概念类描述对象可能存在的问题 对象信息因对象存在而存在 因对象删除而消失 如车型信息 车辆配置信息 实际上 车辆信息在车辆没有销售之前已经存在了 可用规格说明概念类来描述这些信息 这类概念类只有属性 没有行为能力 在图书

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论