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

Posted 2022-12-10 _瞳孔

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

一：相关概念

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

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

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

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

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

为什么要定义过程

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

系统工程过程：

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

过程改进：

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

过程的作用：

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

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

需求工程的输入

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

需求工程的输出

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

三：需求工程过程模型

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

过程模型的类型

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

粗粒度纯线性模型：

粗粒度线形迭代模型：

螺旋式模型：

角色-活动模型：

四：需求抽取和分析

抽取分析和协商螺旋：

需求抽取过程的关键活动

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

需求抽取的四个维度：

需求的来源：

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

需求抽取的机制：

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

需求分析过程：

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

需求协商过程：

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

五：需求验证

需求验证过程

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

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

需求审查：

组织审查的注意事项：

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

审查指南：

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

选择审查人：

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

将审查结构化：

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

五：小结

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