Software-Engineering-UML-Notes

Appearance

AI总结

笔记总结与重点分析 ​

笔记总结 ​

本笔记系统阐述了需求获取的核心概念与实施方法，重点分析了需求获取过程中的非平凡性、主要活动构成、信息内容来源、常用方法工具及实践注意事项。内容覆盖获取活动的五个基本部分（内容/来源/方法/执行/结果），详细列举了涉众类型、硬数据分类、获取方法体系（传统/集体/认知/上下文），并强调了项目范围控制、用户参与度保障等实践要点。

重点/易考点分析 (名词解释) ​

什么是默认（Tacit）知识现象？ ​

用户和开发人员的背景不同导致知识理解困难，用户存在难以明确表述的隐性知识。

潜在（Latency）知识指什么？ ​

用户存在认知困境，无法明确表达自身需求的知识状态。

解系统包括哪些内容？ ​

所有为用户创建解系统必须的信息，包括需求（用户的观点、看法、目标或问题）和问题域特性（需注意系统环境与约束）。

涉众包括哪些部分？ ​

用户、客户、领域专家、市场人员、销售人员等其他用户替代源。

硬数据包含哪些类型？ ​

登记表格、单据、报表等定量文档；备忘录、日志等定性文档。

需求获取的集体方法有哪些？ ​

头脑风暴(Brainstorming)、专题讨论会(Workshop)、JAD。

基于上下文的获取方法包括哪些？ ​

观察、民族志(Ethnography)、话语分析(Conversation Analysis)。

导出用例的定义是什么？ ​

通过其他用例的结合可以推导出的新用例。

获取笔录（Elicitation Notes）包含哪些形式？ ​

文字记录、录音、摄像等各种形式，记录用户需求、问题域知识和约束。

项目范围失控的表现有哪些？ ​

边界定义不清/错误、未控制已建立的项目边界，导致需求不完备或冗余。 （我还没有掌握有关知识，此回答为大模型自动生成）

需求获取概述 ​

需求获取的非平凡性 ​

  • 用户和开发人员的背景不同，立场不同
    • 首先是知识理解的困难。
    • 默认（Tacit）知识现象
  • 普通用户缺乏概括性、综合性的表述能力
  • 用户存在认知困境
    • 潜在（Latency）知识
  • 用户越俎代庖
    • 用户提出的不是需求，而是解决方案
    • 用户固执的坚持某些特征和功能
  • 缺乏用户参与

需求获取的子活动 ​

  • 研究应用背景，建立初始的知识框架；
  • 根据获取的需要，采用必要的获取方法和技巧；
  • 先行确定获取的内容和主题，设定场景；
  • 分析用户的高（深）层目标，理解用户的意图；
  • 进行涉众分析，针对涉众的特点开展工作。

需求获取的活动过程 ​

需求获取的活动过程

需求获取的几个部分 ​

  1. 确定获取信息的内容
  2. 确定待获取信息的来源
  3. 确定应采用的获取方法
  4. 执行获取
  5. 获取的结果

获取的内容 ​

  • 在项目的范围之内
  • 所有为用户创建解系统必须的信息
    • 需求
      • 通常体现为用户的观点、看法、目标或者问题
    • 问题域特性
      • 需要注意的是不要忽略系统的环境和约束
  • 获取的内容不是一次得到的，而是逐步积累的

获取的来源 ​

  • 涉众
    • 用户
    • 客户
    • 领域专家
    • 市场人员、销售人员等其他用户替代源
  • 相关产品
    • 原有系统
    • 竞争产品
    • 协作产品（和解系统存在接口的其他软件系统）
  • 硬数据
    • 登记表格、单据、报表等定量文档
    • 备忘录、日志等定性文档
  • 重要文档
    • 原有系统的规格说明
    • 竞争产品的规格说明
    • 协作产品的规格说明
    • 客户的需求文档（委托开发的规格说明、招标书）
  • 相关技术标准和法规
    • 相关法律、法规及规章制度
    • 行业规范、行业标准

获取的方法 ​

  • 传统方法
    • 面谈、问卷调查、硬数据分析、文档检查、需求剥离等
  • 集体获取方法
    • 头脑风暴(Brainstorming)
    • 专题讨论会(Workshop)
    • JAD
  • 原型
  • 认知方法
    • 任务分析(Task Analysis)
    • 协议分析(Protocol Analysis)
  • 基于上下文的方法
    • 观察
    • 民族志(Ethnography)
    • 话语分析(Conversation Analysis)

获取的过程 ​

注意事项 ​

  • 在整体上制定组织方案
    • 确定系统的边界，建立上下文图或系统用例图
  • 维护项目的前景和范围
  • 引导和控制获取过程
  • 接受需求的不稳定性
  • 控制探索性工作

防止需求遗漏 ​

  • 务必让所有的涉众都表达出自己的意见。
  • 不要以抽象和模糊的需求作为结束。对抽象和模糊的需求，要进行细化，让真正的需求显露出来。
  • 使用多种方法表达需求信息。利用不同的分析技术为相同的需求进行建模，通过分析不同的关注点，考察需求是否完整。
  • 注意检查边界值和布尔逻辑。

结束获取活动判断条件 ​

  • 用户想不出更多的用例；
  • 用户想出的新用例都是导出用例（通过其他用例的结合可以推导出该用例）；
  • 用户只是在重复已经讨论过的问题；
  • 新提出的特性、需求等都在项目范围之外；
  • 新提出的需求优先级都很低；
  • 用户提出的新功能都属于后继版本，而非当前版本

获取的结果 ​

  • 肯定会产生获取笔录（Elicitation Notes）
    • 用户需求、问题域知识和约束
    • 可能具有组织差、冗余、遗漏、自相矛盾等诸多问题
    • 可以包括文字记录、录音、摄像等各种形式
  • 可能会产生两份定义明确的正式文档
    • 项目前景和范围文档
    • 用例文档

需求获取的实践调查情况 ​

实践中的需求获取活动主要关注以下几个问题 ​

  • 项目目标
    • 项目成功的十大影响因素之一
  • 项目范围
  • 用户参与
  • 交流问题
  • 获取方法的使用

项目范围 ​

  • 项目的边界定义不清晰，或者根本就没有定义项目的边界；
  • 定义的项目边界错误，使得最终的需求不完备或者冗余；
  • 没有控制已建立的项目边界，使得项目范围失控

涉众/用户参与不足 ​

  • 没有能够有效的选择参与项目的用户
  • 认识不足
  • 用户抵制
  • 没有明确的用户
  • 管理上的障碍

交流问题 ​

  • 最大的问题就是理解偏差
  • 常用的交流方式
    • 非正式的电话交谈
    • 正式的电话交谈（例如客户热线或者远程电话会议）
    • 邮件
    • web反馈表
    • 文档
    • 面对面的交流（例如JAD会议、原型等）
  • 面对面的交流方式是最有效，也是最受欢迎的
  • 直接交流途径优于间接交流途径

获取方法的使用 ​

  • 面谈、原型
    • 存在选择问题
  • 五个方面的选择依据
    • 需求的目的
    • 知识的类型
    • 知识内化的特性要求
    • 可观察的现象
    • 约束