系统架构设计师(第二版)学习笔记----需求工程

【原文链接】系统架构设计师(第二版)学习笔记----需求工程

文章目录

  • 一、需求定义
    • 1.1 需求包含的内容
    • 1.2 软件需求的3个不同层次
    • 1.3 需求工程的阶段
    • 1.4 需求管理的主要内容
  • 二、需求获取
    • 2.1 需求获取的基本步骤
    • 2.2 需求获取方法
    • 2.3 需求讨论会参与人员
    • 2.4 专题讨论会的优点
  • 三、需求变更
    • 3.1 需求变更管理过程
    • 3.2 需求变更策略
    • 3.3 变更控制委员会(CCB)的组成
    • 3.4 CCB操作步骤
    • 3.5 需求追踪的两种方式

一、需求定义

1.1 需求包含的内容

  • 用户解决问题或达到目标所需条件或权能
  • 系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或权能。
  • 一种反映上面所述条件或权能的文档说明

1.2 软件需求的3个不同层次

  • 业务需求
  • 用户需求
  • 功能需求

1.3 需求工程的阶段

  • 需求获取
  • 需求分析
  • 形成需求规格
  • 需求确认与验证
  • 需求管理

1.4 需求管理的主要内容

  • 控制对需求基线的变动
  • 保持项目计划与需求一致
  • 控制单个需求和需求文档的版本情况
  • 管理需求和联系链,或管理单个需求和其他项目科交付产品之间的依赖关系
  • 跟踪基线中的需求状态

二、需求获取

2.1 需求获取的基本步骤

  • 开发高层的业务模型
  • 定义项目范围和高层需求
  • 识别用户角色和用户代表
  • 获取具体的需求
  • 确定目标系统的业务工作流
  • 需求整理与总结

2.2 需求获取方法

  • 用户面谈
  • 需求专题讨论会
  • 问卷调查
  • 现场观察
  • 原型化方法
  • 头脑风暴法

2.3 需求讨论会参与人员

  • 主持人
  • 用户
  • 技术人员
  • 项目组人员

2.4 专题讨论会的优点

  • 协助建立一支高效的团队,围绕项目成功的目标
  • 所有的风险承担人都畅所欲言
  • 促进风险承担人和开发团队之间达成共识
  • 揭露和解决哪些妨碍项目成功的行政问题
  • 能够很快地产生初步的系统定义
  • 可以有效解决不同涉众主键的需求冲突

三、需求变更

3.1 需求变更管理过程

  • 问题分析和变更描述
  • 变更分析和成本计算
  • 变更实现
    系统架构设计师(第二版)学习笔记----需求工程_第1张图片

3.2 需求变更策略

  • 所有需求变更必须遵循变更控制过程
  • 对于未获得批准的变更,不应该做设计和实现工作
  • 变更应该由项目变更控制委员会决定实现哪些变更
  • 项目风险承担者应该能够了解变更的内容
  • 绝不能从项目配置库中删除或者修改变更请求的原始文档
  • 每一个集成的需求变更必须能跟踪到一个经核准的变更请求,以保持水平可追踪性

3.3 变更控制委员会(CCB)的组成

  • 产品或计划管理部门
  • 项目管理部门
  • 开发部门
  • 测试或质量保证部门
  • 市场部或客户代表
  • 制作用户文档的部门
  • 技术支持部门
  • 帮助桌面或用户支持热线部门
  • 配置管理部门

3.4 CCB操作步骤

  • 指定决策
  • 交流情况
  • 重新协商约定

3.5 需求追踪的两种方式

  • 正向跟踪
  • 逆向跟踪

你可能感兴趣的:(软考高级----系统架构设计师,系统架构,学习,笔记)