需求部分复习

Charlie
  2023-12-31 20:12 2023-12-31 20:12 创建   2024-07-05 12:55:04 2024-07-05 12:55:04 更新    
  • 需求获取（30分）
    • 需求获取上半段（20分）
      • 确定项目前景与范围（10分） – 目标模型
      • 涉众分析（10分） – 涉众识别之ADM模型、涉众评估之Power-Interest、Power-Attitude模型
      • 涉众共赢之Stakeholder-Issue模型
    • 需求获取下半段（10分）
      • 面谈、原型、观察三大获取手段的联系与区别
      • 面谈问题的设计
  • 需求分析（10分）
    • 需求分析根本任务与活动
    • 基于UML软件建模的需求细化 – 概念类图、顺序图、状态图
  • 需求规格说明
  • 需求验证与管理（10分）
    • 需求验证基本活动
    • 需求管理任务与活动
    • 需求变更控制过程、组织与注意事项

1. 需求分类

  1. 功能需求
    • 业务需求：系统建立的战略出发点，高层次目标，描述解决方案和系统特性。
    • 用户需求：用户对系统能完成的具体任务的期望，描述系统能帮用户做什么。
    • 系统需求：用户对系统行为的期望，一系列系统行为能帮助用户完成任务，满足业务需求。
  2. 性能需求：速度，容量，吞吐量，负载，实时性
  3. 质量需求：功能性，可移植性，可维护性，效率，可用性，可靠性
  4. 对外接口：软硬件接口，用户界面，通信接口
  5. 约束：系统开发及运行的环境，问题域内的相关标准，商业准则，法律法规，社会性因素
  6. 其他：安装需求，培训需求，数据内容，数据信息

2. 需求获取

2.1. 上半场

确定获取的内容主题

2.1.1. 确定项目前景与范围 – 目标模型

  • 目标模型的关系

    1. 精化(Refinement)关系
      • AND：一系列子目标紧密结合完成大目标，关系画黑圈
      • OR：任一子目标都是目标的替代方案，关系画白圈
    2. 阻碍(Obstruction)关系
      • 可以继续and,or
    3. 支持与冲突(Support/Conflict)关系
      • Support链接表示一个目标对其他目标的支持促进作用，支持关系可以被处理为OR精化关系
      • Conflict链接表示一个目标的实现对其他目标的实现有阻碍作用。在关系上画X

  • 目标模型做法

    1. 首先提出问题，对问题进行分析，然后提出业务需求，业务需求就是我们的高层目标。可以分为软目标和硬目标。软用云朵，硬用方块。
    2. 高层次目标可以分解为低层次目标。低层次目标用and或者or精化，子目标展开到单一事务时终止。
      • and：用一个集中的黑圈
      • or：每一个目标指向父目标的白圈。表示多种可以相互替代的“候选办法”
    3. 对每个高层次目标进行分析了以后，高层次目标也可以连接在一起。考虑已有目标之间的支持与冲突关系

  • 目标有以下几种形式

    • avoid 避免
    • achieve 实现
    • Cease 终止
    • maintain 维持
    • optimize 优化
      • min
      • max

image.png

2.1.2. 涉众分析

  • 涉众stakeholder：所有能够影响软件系统的实现，或者会被实现后的软件系统所影响的，关键个人和团体

  • 过程

    1. 涉众识别
    2. 涉众描述
    3. 涉众评估
    4. 涉众代表选择

  • 涉众评估之Power-Interest、Power-Attitude模型

    • 优先级评估
    • 风险评估
      • 基于涉众特征与态度化解涉众风险策略

  • 基于特征化解举例：亲子兴趣班

    • 大人与小朋友一起参与：环境设定者（客户）-> 参与者（用户）
    • 良好的产品体验打造亲子品牌：被影响者（潜在用户/客户） -> 参与者

  • 基于态度化解举例：电子竞技产业

    • 与地方政府文化产业发展相结合：强反对者 -> 强支持者
    • 成功的赛事运营与未成年人游戏时长限制：弱反对者 -> 弱支持者

image.png

  • Power-interest图：优先级评估
    1. 参与者：系统的实际使用者，对系统最终成功有较大影响力，收到系统较大影响，优先级最高。
    2. 环境设定者：很少使用系统，但是由于政治、经济等因素对系统有比较大的影响，优先级次之，最常见的是政府和管理者。
    3. 被影响者：可能是系统直接使用者，也可能是因为系统出现被剥夺了部分利益的输家，受影响大，能影响少，优先级一般低于环境设定者，但是特殊情况下也可能高于环境设定者。
    4. 观众：不受影响，也不影响，优先级最低，比如环境专家和市场力量。
  • Power/Attitude图：风险评估
    1. 强反对者是需要重点分析的。
    2. 涉众的关注点和兴趣去向也是重要内容，一般环境设定者是项目高风险因素。
    3. 对于高风险的涉众类别，要尽可能澄清各个涉众类别的角色和职责，发现项目对他们的依赖和假设条件，分析实际情况与预期不一致时可能出现的风险，并提前化解。
  • 化解涉众风险
    1. 一方面提高环境设定者对系统的关注，转化为参与者
    2. 一方面消除强反对者的反对原因，变为强支持者
    3. 给予被影响者一些发表和实现自身意见的权利，缓解忧虑

2.1.3. 涉众共赢之Stakeholder-Issue模型

列出系统所有的受众，明确描述他们的兴趣和对系统的期望，发现背后的共同问题Issue。如果某个涉众类别对一个Issue存在兴趣，那这个关系就是一个Stakeholder-Issue关系。

共赢分析：

  1. 某个Stakeholder-Issue关系上所寄予的期望与项目的业务需求无法保持一致，那么它关联的涉众就在该Issue的问题上和项目整体目标存在冲突
    • 涉众和项目负责人相互调整折中
    • 重新评估项目的可行性
  2. Stakeholder/Issue关系图中某个Issue所关联的不同关系标识有互相冲突的期望，那么就意味着它所关联的涉众在该Issue上存在需求冲突
    • 分析各个冲突方成为赢家的条件
    • 适当的调整，化解冲突
    • 分析项目在该Issue上的目标、约束和可选方案，并提供给冲突方进行权衡，促进他们之间协商解决

image.png

2.2. 下半场

设计具体的应用环境和场景条件，由用户根据细节业务的执行来描述问题、表达期望

2.2.1. 面谈、原型、观察三大获取手段的联系与区别

  • 联系：这三大获取需求的手段相互补充，联合起来完善一个产品的需求获取，使得获得的需求尽可能不出错，减少项目的开发风险。
  • 区别：
    1. 面谈：如果涉众对产品的需求理解比较透彻、认为自身需求具有可行性、能够清晰地说明自身的需求，则可以通过面谈的方式，通过与这些涉众的交流，直接获取他们对产品的需求
    2. 原型：如果涉众对产品的需求理解、对自身需求的可行性、对其需求的表达充满不确定性，或是需求工程师在理解用户需求上有困难、怀疑需求的可行性，抑或是面对创新型产品这类需求充满不确定性的产品需求分析时，需要通过原型法，消除不确定性，降低风险，应对模糊与变更。
    3. 观察：如果事件具有突现、局部、暂时、涉身、开放、模糊的情景性时，用户可能无法主动告知相关信息，此时需要结合事件发生的具体环境才能理解，就必须采用采样观察、民族志等观察方法，来应对复杂协同等问题；观察的特点是不打扰用户的正常工作。

2.2.2. 面谈问题的设计

问题类型：

  1. 开放式问题：回答不受限制
  2. 封闭式问题：（受限制）程序性提示
  3. 探究式问题
    • 为什么？
    • 你能举个例子吗？
    • 你能详细描述一下吗？
  4. 诱导性问题 （不好）
    • “你和其他经理一样，都同意把财产管理计算机化，是吗”
  5. 双筒问题 （不好）
    • “每天你通常会做什么决策，你是怎样做的”
    • 过于宽泛，要回答的东西特别多
  6. 元问题
    • 我的问题看起来相关吗？
    • 你的回答正式吗？
    • 你是回答这些问题的最佳人选吗？
    • 我问了太多的问题吗？
    • 我还应该见什么人？
  7. 程序性提示

面谈前期以开放式问题为主，后期以封闭式问题为主

image.png
image.png

3. 需求分析

3.1. 根本任务

  1. 建立分析模型，达成开发者和用户对需求的共同理解
    • 将复杂的系统分解成为简单的部分以及它们之间的联系，确定本质特征
    • 和用户达成对信息内容的共同理解
    • 分析的活动主要包括识别、定义和结构化，它的目的是获取某个可以转换为知识的事物的信息
  2. 依据共同理解，发挥创造性，建立解决方案
    • 将一个问题分解成独立的、更简单和易于管理的子问题来帮助寻找解决方案
    • 创建解决方案的过程是创造性的
    • 帮助开发者建立问题的定义，并确定被定义的事物之间的逻辑关系
    • 这些逻辑关系可以形成信息的推理，进而可以被用来验证解决方案的正确性。

3.2. 需求分析活动

image.png

  • 需求细化：防止开发者各自假设造成的不一致
  • 确定需求优先级：
    • 累积投票
    • 区域划分：重要性，紧急性，惩罚性，成本，风险
  • 需求协商：开发人员内部，明确冲突的因素、解决空间和解决方案

image.png

4. 需求验证与管理

需求验证是专指在需求规格说明完成之后，对需求规格说明文档进行的验证活动

4.1. 需求验证基本活动

  • 验证流程：

image.png

  • 需求验证方法
    1. 评审
    2. 原型与模拟
    3. 开发测试用例
    4. 用户手册编制
    5. 利用跟踪关系
    6. 自动化分析

4.2. 需求管理任务与活动

  • 任务：
    1. 维护需求基线
    2. 实现需求跟踪
    3. 控制变更
  • 活动：
    1. 交流涉众需要什么；
    2. 驱动设计和实现工作；
    3. 测试和验证最终产品；
    4. 辅助项目管理
    5. 将需求应用、实施到解决方案；
    6. 将需求分配到子系统；
    7. 控制变更；
    8. 控制迭代式开发中的变化；

image.png

4.3. 需求变更控制过程

以可控、一致的方式进行需求基线中需求的变更处理，包括对变化的评估、协调、批准或拒绝、实现和验证。

  1. 提请者：提出需求变更
  2. 接收者：接受需求变更
  3. 评估者：进行变更评估，产生需求变更表单
  4. 变更控制委员会：变更决策，决定变更/拒绝变更
  5. 修改者：执行变更
  6. 验证者：验证变更

image.png

4.4. 需求变更组织

变更控制委员会（CCB）:评价需求的变更，做出批准或者拒绝变化的决定，并确保已批准变化的实现。

人员可能来自：项目或程序管理部门； 产品管理或者需求分析部门； 开发部门； 测试或者质量保障部门；配置管理部门

4.5. 需求变更注意事项

  1. 认识到变更的必要性，并为之制定计划
  2. 维护需求基线，审计变更记录
  3. 管理范围蔓延
  4. 灵活应对变更请求
  5. 使用辅助工具
  • 标题: 需求部分复习
  • 作者: Charlie
  • 创建于 : 2023-12-31 20:12:00
  • 更新于 : 2024-07-05 12:55:04
  • 链接: https://chillcharlie357.github.io/posts/e27123b2/
  • 版权声明: 本文章采用 CC BY-NC-SA 4.0 进行许可。
评论
此页目录
需求部分复习
  1. 1. 需求分类
  2. 2. 需求获取
    1. 2.1. 上半场
      1. 2.1.1. 确定项目前景与范围 – 目标模型
      2. 2.1.2. 涉众分析
      3. 2.1.3. 涉众共赢之Stakeholder-Issue模型
    2. 2.2. 下半场
      1. 2.2.1. 面谈、原型、观察三大获取手段的联系与区别
      2. 2.2.2. 面谈问题的设计
  3. 3. 需求分析
    1. 3.1. 根本任务
    2. 3.2. 需求分析活动
  4. 4. 需求验证与管理
    1. 4.1. 需求验证基本活动
    2. 4.2. 需求管理任务与活动
    3. 4.3. 需求变更控制过程
    4. 4.4. 需求变更组织
    5. 4.5. 需求变更注意事项