SE04需求分析基础.ppt

软件工程 哈尔滨工程大学 SoftwareEngineering 第4章需求分析基础 分析的任务 过程 原则初步需求获取技术需求建模问题抽象 问题分解与多视点分析支持需求分析的快速原型技术需求规格说明与评审 软件需求 用户对目标软件系统在功能 行为 性能 设计约束等方面的期望 第4章需求分析基础 IEEE软件工程标准词汇表 1997年 中定义需求为 1 用户解决问题或达到目标所需的条件或权能 Capability 2 系统或系统部件要满足合同 标准 规范或其它正式规定文档所需具有的条件或权能 3 一种反映上面 1 或 2 所描述的条件或权能的文档说明 准确 完整和规范化的软件需求是软件开发成功的关键 软件项目中40 60 的问题都是在需求阶段埋下的祸根主要障碍 用户对应用问题的理解 描述以及他们对目标软件的需求往往具有片面性 模糊性 甚至不一致性 第4章需求分析基础 不适当的需求过程所引起的一些风险 调研的用户不多 导致产品无法被接受用户需求的增加带来过度的耗费和降低产品的质量模棱两可的需求说明可能导致时间的浪费和返工用户增加一些不必要的特性和开发人员画蛇添足 gold plating 过分简略的需求说明以致遗漏某些关键需求忽略某类用户的需求将导致众多客户的不满不完善的需求说明使得项目计划和跟踪无法准确进行 4 1需求分析的任务与原则 软件需求分析 对应用问题及环境的理解和分析 为问题涉及的信息 功能及系统行为建立模型 将用户需求精确化 完全化 最终形成需求规格说明书分析目标 准确理解用户的要求 进行细致的调查分析 将用户的非形式的要求转化为完整的需求定义 再将需求定义转换为相应的形式化的规格说明 深入描述软件的功能和性能 确定软件的设计约束 软件同其他系统元素的接口细节 定义软件的其他有效性需求 一方面必须全部理解用户的各项要求但又不能全盘接受 另一方面要准确表达被接受的要求 只有经过确切描述的软件需求才能成为软件设计的基础 需求分析的任务 需求分析的任务 就是借助于当前系统的逻辑模型导出目标系统的逻辑模型 解决目标系统的 做什么 的问题 理解需求 表达需求 怎么做 做什么 需求分析的任务 需求分析阶段要解决的问题 是让用户和开发者共同明确将要开发的是一个什么样的系统 主要两个任务 1 通过对问题及其环境的理解 分析和综合 建立分析模型 AnalysisModel 2 在完全地弄清用户对软件系统的确切要求的基础上 用 软件需求规格说明书 SoftwareRequirementSpecification SRS 把用户的需求表达出来 需求分析的任务 建立分析模型由于用户群体的各个用户往往会从不同的角度阐述他们对原始问题的理解和对目标软件的需求 分析模型是描述软件需求的一组模型 一方面用于精确地记录用户对原始问题和目标软件的描述另一方面 它也将帮助分析人员发现用户需求中的不一致性 排除不合理的部分 挖掘潜在的用户需求这种模型往往包含问题及其环境所涉及的信息流 处理功能 用户界面 行为模型及设计约束等 是形成需求说明 进行软件设计与实现的基础 需求分析的任务 编写需求说明应该具有准确性和一致性 它是连接计划时期和开发时期的桥梁 也是软件设计的依据 应该具有清晰性和无二义性 它是沟通用户和系统分析员思想的媒介 双方要用它来表达对于需要计算机解决的问题的共同理解 应该直观 易读和易于修改 应尽量采用标准的图形 表格和简单的符号来表示 使不熟悉计算机的用户也能一目了然 需求分析过程 问题识别 分析与综合 编写文档 分析评审 问题识别 从分析当前系统包含的数据开始例如当前系统使用的账册 卡片和报表 手工处理当前信息的方法与不足 用户需要改进的主要问题及其迫切性等对软件功能的需求和界面的需求为了收集到全面完整的信息 需将客户按使用频率 使用特性 优先及等方面进行分类 每类选择若干用户代表 从代表那里收集他们希望的软件系统功能 用户与系统间的交互和对话方式等需求对质量的要求 包括性能 有效性 可靠性 可用性和设计约束等 提高用户对软件的满足程度如果客户的要求和已有产品很相似 则需要考虑可否复用一些已有的软件组件 分析与综合 需求提炼 分析建模 分析人员应了解问题及环境 应与用户合作清除用户需求的模糊性 岐义性和不一致性 并对相互冲突的需求进行折衷分析人员与用户合作对问题进行分析 综合 结合软件的特点及开发经验 寻求软件需求为用户的问题及准备开发的软件建立模型 从不同的角度 不同的抽象级别精确地说明对问题的理解 对目标软件的需求图形化的分析模型是说明软件需求极好的手段 常用的模型包括数据流图 实体关系图 控制流图 状态转换图 用例图 类对象关系及其行为图文图等 有些软件还需要绘制系统关联图 创建用户接口原型 确定需求优先级别 编写SRS 需求描述 以需求模型为基础 考虑到软件问题的可解性 生成需求规格说明和初步的用户手册 需求规格说明包含对目标软件系统的外部行为的完整描述 需求验证标准以及用户在性能 质量 可维护性等方面的要求 初步用户手册包括用户界面描述以及有关目标软件使用方法的初步构想 文档遵循规范 内容全面 结构清晰 措辞准确 格式严谨将初步用户手册作为分析文档 有助于分析人员从用户角度考虑软件需求 并鼓励用户尽早参予软件开发活动必须使用统一格式的文档进行描述 为了使需求描述具有统一的风格 可以采用已有的且可满足项目需要的模板 如IEEE标准830 1998和GB9385中描述的SRS模板 需求评审 分析人员在用户和软件设计人员的配合下 对自己生成的需求规格说明和初步的用户手册进行评审 确保软件需求的完全性 精确性和一致性 并使用户和软件设计人员对需求规格说明及用户手册的理解达成一致需求规格说明得到用户和软件开发方的确认后 应成为用户方与软件开发方合同的一部分 需求分析流程 需求分析的原则 原则能够表达和理解问题的信息域和功能域能够对问题进行分解和不断细化 建立问题的层次结构需要给出系统的逻辑视图和物理视图方法面向数据流的分析面向数据的分析面向对象的分析需求的四项基本标准 明确 clear 完整 complete 一致 consistent 可测试 testable 4 2初步需求获取技术 访谈与会议深入调查研究联合小组开发原型 访谈与会议 个别访谈或小组会议分析人员应精心准备问题 通过用户对问题的回答 逐步理解用户对目标软件的要求 1 循序渐进首先关心一般性 整体性问题 然后再讨论细节问题 2 客观 公正不应限制用户在回答问题过程中自由发挥 3 总结问题汇总后应能反映软件或其子系统的全貌 能覆盖用户对目标软件或其子系统在功能 行为 性能诸方面的要求 细节问题留待以后解决 深入调查研究 调查研究考察用户软件或其子系统业务流程学习用户的有关业务知识 在用户帮助下了解用户的软件或子系统业务流程 结合软件开发和应用的经验提出新的用户需求注意 开发软件系统不仅是为了模拟手工操作过程 还必须将最好的经济效益 最快的处理速度 最合理的操作流程 最友好的用户界面作为软件的目标 联合小组 建立软件开发方和用户方共同组成的联合小组 小组成员对分析负有相同的责任联合小组要制定自己的工作制度和计划 确定专门的记录员 另设专人负责会议的议程和资料的综合 整理选择易于理解 比较简洁 精确的表示机制作为描述语言 如辅以文字说明的流程图 需求获取一般过程 1 识别系统用户分析客户方的所有用户类型以及潜在的类型 然后根据他们的要求来确定系统的整体目标和系统的工作范围 如有领导使用 则应该有领导查询系统 如果是单机系统 则对安全性可以少考虑 2 用户调研与访谈会议 电话 Email 小组讨论 模拟演示等 每次都要有记录 确定功能需求 非功能需求 响应时间 自动恢复时间 环境限制 设计约束等 3 访谈结果整理 对于用户提出的每个需求都要知道 为什么 并判断这种需求是否有充足的理由 将那种以 如何实现 的表达方式转换为 实现什么 分析由用户需求衍生出的隐含需求 并识别用户没有明确提出来的隐含需求 如工时统计 计算工资 生产系统 工资系统 4 访谈结果呈现 明确标识出那些未确定的需求项 使需求符合系统的整体目标 保证需求项之间的一致性 解决需求项之间可能存在的冲突 出版社管理信息系统调查表 实例分析 家庭保安系统家庭保安市场正以每年40 的速度增长 我们希望建立一种基于微处理器的家庭保安系统 它能够识别异常事件并采取相应的防护措施 这些异常事件包括 非法入侵 火灾 水淹 等等 一旦异常情况被相应的传感器探测出来 系统应自动用电话向监控中心报警 此外 系统应允许户主对其行为实施程序式控制 联合小组首先制定工作制度 经过数次会议讨论 明确问题的范围 问题与环境的关系 并就开发软件产品的必要性达成共识后 小组负责人要求每位参加人列出应用问题及环境中有关的对象 这些对象所实施的操作以及对象间的互相作用 实例分析 控制面板 电话机 监控中心 烟雾报警器 门窗报警器 警报器等对象 用户编程控制 电话拨号 报警等操作要求对对象及操作进行详细描述用户可能提出约束条件 如成本 响应时间优先处理顺序等最后初步分析活动 综合 整理 形成文档 该文档作为后续分析活动的基础 部分需求文档 不包括约束条件和测试标准 如下 家庭保安系统 的软件允许用户在安装时进行系统配置 实施对传感器的监控并通过控制面板与用户进行信息交互 实例分析 配置操作包括 1 指定每一传感器的种类和编号 2 设置开 关机密码 3 指定报警电话号码 4 指定报警延迟和电话重拨延迟时间 以秒为单位 当软件系统接收到传感器发出的数据后 判别是否出现异常事件 如果是 则在指定的延迟时间内拨报警电话号码 拨号操作将按照重拨延迟反复进行 直到电话接通 然后软件系统负责报告时间 地点和异常事件的性质 开机后 软件系统负责显示当前工作状态 接收并处理用户指令 4 3需求建模 建立软件模型是分析活动的关键目标软件系统的模型用来刻划系统所涉及的信息 处理功能及系统运行时的外部行为模型不应涉及软件实现细节 这样会分散分析人员的注意力 限制软件设计人员的聪明才智分析人员应以简洁 准确 清晰的方式 系统地描述软件需求模型 如选择图形符号表示信息流 处理功能及系统行为 利用受限的自然语言给出用户需求描述为了处理大型问题 模型表示机制应具备良好的结构化能力 4 3需求建模 通常由一组模型组成关联模型在需求获取和需求分析的早期 应确定系统的边界 包括区分系统以及系统的环境等 即需求分析的一个活动是定义系统与环境的关联关系 建立简单架构模型的第一步 4 3需求建模 通常由一组模型组成行为模型描述系统的总体行为数据流模型 系统是通过数据驱动状态机模型 系统是通过事件驱动数据模型定义系统处理的数据逻辑形式实体关系图 ERD 描述系统实体间的对应关系 缺乏对系统功能的描述数据流图 DFD ERD结合描述更准确 结构化方法 4 3需求建模 结构化分析方法SA Jackson Warnier orr PAD面向对象模型Jacobson于1994年提出面向对象软件工程 OOSE 方法 其最大特点是面向用例 并在用例描述中引入外部角色 用例贯穿整个开发过程 包括对系统的测试和验证UML 面向对象的建模工具其他方法原型分析法功能列表法 4 3需求建模 最常用的两种分析模型结构化分析模型面向对象分析模型 4 4问题的抽象 分解与多视点分析 抽象 关注一般问题的解决途径 以此指导特殊问题的求解 分析人员应该注意用户描述的抽象级别 统一规划系统行为 避免不一致性 减少分析的工作量 分解 根据问题的规模和复杂性进行分解 并对子问题展开进一步的分析逐级分解 直至子问题的规模降至合适程度在问题分解过程中 要建立子问题之间的相互联系必须遵循子问题内部紧藕合 子问题之间松藕合的原则 视点分解法 视点分解法在分析的初期 整体地把握一个大型问题的软件需求是困难的 需要从各个角度分别对问题进行理解和分析 然后再综合 达到全面理解的目的需求分析视点系统观点用户观点信息观点功能观点行为观点等整理 综合用户描述 应注意用户视点的变化 避免遗漏 4 5支持需求分析的快速原型技术 按照传统的软件开发方法 目标软件要等到木已成舟才能交用户认可 分析 设计及编码积累的各种问题 导致用户对目标软件提出诸多修改 甚至全盘否决 造成人力 物力的巨大浪费 软件开发早期 快速建立目标软件系统原型 让用户对原型进行评估并提出意见 原型几经改进最终确定 它将进化成软件产品 设计和编码人员遵循原型确立的外部特征实现软件产品 如果软件产品含有大量人机交互 可视输出 或者涉及复杂的算法 应采用快速原型技术 支持需求分析的快速原型技术 分析阶段使用快速原型技术与问题本身的复杂度以及可用的开发工具 环境有关 如果问题非常复杂 在当前工具 环境的支持下开发可运行的原型需要投入太多人力或占用太多时间 那么可对某些子问题 尤其是用户界面 使用快速原型技术进行部分分析 某些软件项目 虽不能构造实际可运行的快速原型 但可以采用幻灯片演示等方法 向用户直观描述目标软件系统的外部行为 快速建造原型过程 1 利用需求分析技术 方法 生成简化的需求规格说明 2 对简化的需求规格说明进行检查 修订 生成设计规格说明 为了快速生成原型 只关心软件的总体结构 用户界面和数据设计 而不注重过程内部的控制流 3 在快速原型工具或环境的帮助下 快速生成可运行的软件原型并进行测试 改进 主要工具有 可重用软部件库 用户界面自动生成器等 快速建造原型过程 4 将原型提交用户评估并征求改进意见 5 迭代上述过程 直到用户满意 通过评审的原型应全面 准确地反映用户对目标软件在外部行为方面的需求 可以作为需求规格说明的一部分并成为软件设计和编码的基础 软件原型的分类 探索型 目的是要弄清对目标系统的要求 确定所希望的特性 并探讨多种方案的可行性 实验型 这种原型用于大规模开发和实现之前 考核方案是否合适 规格说明是否可靠 进化型 这种原型的目的不在于改进规格说明 而是将系统建造得易于变化 在改进原型的过程中 逐步将原型进化成最终系统 原型开发模型 原型开发技术 可执行规格说明基于脚本 scenario 的设计自动程序设计专用语言可复用 reusable 的软件简化假设 4 6需求规格说明与评审 产生需求规格说明并进行评审需求规格说明应成为开发过程必须遵循的指导原则 需求规格说明 目标 1 用户通过需求规格说明可初步判定目标软件能否满足需求 设计人员将需求规格说明作为软件设计的基础 2 支持目标软件系统的确认 需求规格说明的各项需求应该是可测试的 3 控制系统进化过程 需求分析完成后 如果用户追加需求 开发人员再次进行需求分析 扩充需求规格说明 进行软件设计等 需求规格说明 功能 行为需求描述系统的输入 输出及相互关系非行为需求描述软件系统工作时应具备的各种属性 如效率 可靠性 安全性 可维护性 可移植性等为使需求规格说明更加简洁 其它内容不应写入 如人员 成本 进度 设计方案 质量控制等 这些内容单独形成文档 需求规格说明 1引言 1 1需求规格说明的目的 1 2软件产品的作用范围 1 3定义 同义词与缩写 1 4参考文献 1 5需求规格说明概览2一般性描述 2 1产品与其环境之间的关 2 2产品功能 2 3用户特征 2 4限制与约束 2 5假设与前提条件 3特殊需求 附录 索引 特殊需求描述 3特殊需求 3 1功能或行为需求 3 1 1功能或行为需求1 3 1 1 1引言 3 1 1 2输入 3 1 1 3处理过程描述 3 1 1 4输出3 1 2功能或行为需求2 3 1 n功能或行为需求n 3 2外部界面需求 3 2 1用户界面 3 2 2硬件界面 3 2 3软件界面 3 3性能需求 3 4设计约束 3 4 1标准化约束 3 4 2硬件约束 3 5属性 3 5 1可用性 3 5 2安全性 3 5 3可维护性 3 5 4可移植性 3 6其它需求 3 6 1数据库需求 3 6 2用户操作需求 3 6 3工作场地需求 需求评审 需求规格说明进入设计阶段之前 必须进行评审 如果发现错误或缺陷 应及时纠正或更改需求分析 模型 需求规格说明 并重新评审 衡量需求规格说明的标准正确性无歧义性完全性可验证性一致性可理解性可修改性可追踪性 需求评审 1 正确性 需求规格说明书的功能 行为 性能描述必须与用户对目标软件产品的期望相吻合 2 无歧义性 需求规格说明的任何语法单位只能有唯一的语义解释 确保无歧义性的一种有效措施是在需求规格说明中使用标准化术语 并对术语的语义进行显式的 统一解释 3 完全性 需求规格说明书不能遗漏任何用户需求 具体地说 目标软件产品的所有功能 行为 性能约束 以及它在所有可能情况下的预期