软件需求分析——需求工程过程

Posted _瞳孔

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了软件需求分析——需求工程过程相关的知识,希望对你有一定的参考价值。

如果有兴趣了解更多相关内容,可以来我的个人网站看看:瞳孔空间

一:相关概念

需求工程过程的目的:介绍为软件加强型系统中的复杂软件设计的需求工程过程,涉及

  • 抽取需求
  • 分析需求
  • 验证需求
  • 管理需求

主要关注点:需求工程中要做些什么

过程:一组活动的有序集合

  • 具有结构性:一组有组织的活动
  • 具有目的性:将输入转换成输出
  • 作用:
    • 结构性帮助处理复杂问题
    • 过程定义帮助问题求解知识的重用

为什么要定义过程

  • 组织和控制过程的进展,达到可控可预测的目的
    • 活动的管理
    • 执行活动的人员的管理
    • 活动完成质量的管理
  • 发现活动进行的问题并在发现问题之后能够改进过程

系统工程过程:

  1. 系统需求工程:整体系统的需求,相对高层的需求,关键约康
  2. 体系结构设计:系统分解为相对独立的子系统
  3. 需求划分:需求划分到这些子系统上,决定那些需求由软件实现
  4. 软件需求工程:高层软件需求分解到细一些的软件组件的需求
  5. 子系统开发:硬件和软件子系统平行设计和实现
  6. 系统集成:硬件和软件子系统集成为一体
  7. 系统验证:对照需求验证系统

过程改进:

  • 目标:
    • 质量改进
    • 日程缩减
    • 资源缩减
  • 主要涉及的问题
    • 过程成熟度
    • 需求过程的成熟度模型
      • 初始级:经验式需求工程,常常出现需求的问题
      • 可重复级:标准化需求工程;较少的需求问题
      • 定义级:定义明确的基于最好的实践的过程,恰倒好处的过程改进

过程的作用:

  • 规定需求工程要进行的活动
  • 定义活动的输入/输出
  • 管理和控制需求工程进程
  • 明确岗位的职责和任务(过程和角色挂钩)
  • 通过过程控制保证需求的质量

二:需求工程的输入和输出

需求工程的输入

  • 存在系统的信息:要被替换的系统或者目标系统将与之交互的系统的功能
  • 需求相关者的需要:系统的需求相关者在什么方面需要目标系统来支持他们的工作
  • 组织标准:组织中涉及系统开发实践和质量管理等方面的标准
  • 规章条例:适用于系统的诸如健康和安全条例等外部规定
  • 领域信息:关于系统的应用领域的一般信息

需求工程的输出

  • 一致同意的需求:关于系统需求的描述,这个描述对需求相关者来说是可理解的,并且已经得到他们的同意
  • 系统的规格说明:在某些情况下可被实现的系统功能的更详细的规格说明
  • 系统模型:一组从不同方面描述系统的模型,比如,数据流模型、过程模型、等等

三:需求工程过程模型

过程模型:过程的简化描述

过程模型的类型

  • 粗粒度模型:活动的大致的序列、给出活动的上下文、显示过程的输入和输出
  • 细粒度模型:特定过程的细化模型、用于理解和改进存在的过程
  • 角色-活动模型:刻画参与过程的不同角色,以及他们进行的活动
  • 实体-关系模型:显示过程的输入、输出、中间结果、以及它们之间的关系,用于质量管理系统,作为过程活动的补充

粗粒度纯线性模型:

粗粒度线形迭代模型:

螺旋式模型:

角色-活动模型:

四:需求抽取和分析

抽取分析和协商螺旋:

需求抽取过程的关键活动

  • 设定目标:组织和业务目标
  • 获取背景知识:应用领域知识
  • 组织知识:将获取的知识组织起来
  • 采集需求相关者的需求:咨询需求相关者

需求抽取的四个维度:

需求的来源:

  • 客户(实际的或潜在的)
  • 任何原有的解系统及其文档
  • 原有系统的用户
  • 新系统的潜在用户
  • 应用领域专家
  • 相关的技术标准和法规

需求抽取的机制:

  • 交谈法
  • 问卷法
  • 任务观察
  • 头脑风暴
  • 联合应用开发
  • 用例和场景

需求分析过程:

  • 目标:发现初步需求中的冲突
  • 主要活动:
    • 必要性检查
    • 一致性和完整性检查
    • 可行性检查

需求协商过程:

  • 目标:确定能得到一致同意的需求
  • 主要活动:
    • 需求讨论
    • 需求优先化
    • 达成一致意见的需求的确认

五:需求验证

需求验证过程

  • 需求分析
    • 需求抽取阶段的“粗”需求
    • 通常非形式化非结构化的表示
    • 不完整、存在不一致
    • 解决“我们得到了正确的需求吗?”
  • 需求验证
    • 检查需求文档,完整的系统需求
    • 明显的不完整和不一致已经去掉
    • 文档的表述符合规范
    • 解决“我们是否把需求搞对了?”

需求验证过程:输入与输出

需求审查:

组织审查的注意事项:

  • 规模
    • “足够的人,使得相关的经验都有”
    • 最少:3 (4如果写的人在的话)
    • 最多:7(如果领导没有经验的话,可以少一些)
  • 期限
    • 不要超过2个小时
    • 如果太长了注意力会漂移
  • 输出
    • 所有的审查员必须同意这个结果
    • 所有的发现都应该写下来
  • 范围
    • 关注于一小部分的设计,而不是整个事情
  • 时间表
    • 一旦作者完成了一件产品就开始检查它
    • 不要太早:产品还没有准备好———发现作者已经意识到的问题
    • 不要太晚:产量已经在使用———错误要改就要花费很大的代价
  • 目的:记住最大的好处是来自于固定这个过程,采集数据以帮助你下次不要犯同样的错误

审查指南:

  • 在审查之前
    • 将形式的审查安排进项目规划中
    • 训练所有的审查人
    • 保证所有的出席人都要提前准备
  • 在审查期间
    • 审查产品,而不是它的作者,使意见是构造性的、专业的、以及和任务相关的
    • 严格按照日程进行,领导必须防止拖延
    • 限制辩论和反驳,记录下问题留着以后讨论,只识别问题,当时不要去试图解决它
    • 全要写下来
  • 在审查之后
    • 审查这个审查过程

选择审查人:

  • 可能的候选人
    • 审查方面的专业人员(比如,QA人员)
    • 来自与作者同一个开发小组的人
    • 因为有专业经验而被邀请的人
    • 对产品有兴趣的人
    • 有什么东西可以贡献的访问人员
    • 来自组织中其它部门的人
  • 要排除的人
    • 负责审查作者本人的任何人(比如,产品线经理)
    • 任何已经知道与其他审阅者有个人冲突的人
    • 任何没有资格来做这件事的人
    • 所有的管理人员
    • 任何其出现会带来兴趣上的矛盾的人

将审查结构化:

  • 能够将审查结构化为不同的形式
    • 经验的:依赖于审查人的经验
    • 检查表:
      • 使用一个关于问题/观点的检查表
      • 检查表被裁剪为文档的形式
    • 主动审查(基于观点的阅读)
      • 每个审查者从一个特定的目的来阅读,使用专门的问卷
      • 不同的审查者有效地采用不同的观点
  • 这些不同是有含义的,比如,研究指明:
    • 主动审查比经验的和检查表方法能发现更多的错误
    • 在经验式和检查表方法之间没有明显的不同
    • 会议式审查可能会是多余的

五:小结

  • 需求工程过程是一组活动的结构化序列,它产生用来说明待开发系统的需求文档。需求工程过程涉及需求抽取、需求分析和协商、和需求验证等活动。
  • 需求工程过程模型是从某个特定的角度出发构建的简化过程描述。
  • 需求抽取涉及对包含应用领域、要解决的问题、组织的需要和约束、以及系统相关者需要的辅助功能等在内的所有问题的理解。可以采用的技术包括面谈法、问卷法、情景法、软系统方法、原型法等。
  • 当出现需求重叠和冲突时需要进行需求协商。
  • 需求抽取、分析和协商是相互交织在一起的过程,在需求被所有需求相关者接受前,可能需要多次的重复。
  • 需求验证关注于检查需求文档的最终草案以发现其中的错误。最常用的需求验证方式是需求审查,检查表在组织需求验证过程中是一种有用的方式。原型法是需求验证的另一种有效的方法。
  • 需求变化是不可避免的,因而要求有有效的需求管理机制来管理这些变化。可追踪性信息记录了需求与需求的来源之间,需求之间,需求和系统设计之间等的依赖关系,这些依赖关系对变化影响分析至关重要。

以上是关于软件需求分析——需求工程过程的主要内容,如果未能解决你的问题,请参考以下文章

《需求工程-软件建模与分析之读书笔记之三》

软件工程复习2——软件需求分析

《软件需求十步走》阅读笔记三

软件需求分析——需求工程过程

软件工程 图书管理系统需求分析

软件工程过程 第4章 瀑布模型应用实例