需求获取的挑战

  • 在上下文分析的基础上,需求获取过程开始
  • 需求获取的困难,三种典型表现:
    • 我们所理解,并非用户所需要
    • 发现的越多,未知的越多
    • 用户与开发人员,说不同的语言
  • 用户与开发人员之间的矛盾,表现在:
    • 用户不知道他们要什么,或者知道但不知如何表述
    • 直到开发人员把用户描述的东西拿给他们,用户才知道自己要什么
    • 分析人员认为自己比用户更了解用户需求
    • 每个人都相信其他人有某种政治动机

高层次需求

  • [需求三个层次](软件需求与建模——导论 | Hexo)
  • 需求获取活动的最终目的: 得到软件需求。(从需要入手,将需要细化为特性,然后才能具体到每一项软件需求)
  • 需要可能只需要1句话或几句话描述
  • 特性简明扼要,是需要的体现,又不至于陷入过多的细节
  • 特性可以列出许多条。建议控制在25~50条之间,最多不超过99个
  • 通过控制特性的抽象程度做到
  • 重要的是理解特性后面的需要,否则有风险。
  • 为了更好管理特性,可以为特性增加一些属性
  • 属性可以包括:状态,优先级/益处,工作量,风险,稳定性,目标版本,负责人,原因等。
  • 小结: 需求获取活动,从高层需求入手,逐渐细化。因此需要记录特性,管理特性。

面谈技巧

  • 面谈: 对上下文中发现的涉众,进行面对面交流

  • 在开发一个新的软件时,与客户的面谈是其他方式不可替代的

    一,面谈简介

    • 面谈分为结构化非结构化面谈
      • 结构化 使用预先准备好的提纲或问题
      • 非结构化 不准备提纲,自由交谈。
    • 需求获取中一般采用结构化面谈
    • 面谈时,可以一对一,也可以一对多(小组面谈)。
    • **面谈过程:**确定目标;选择和邀请参与者;确定面谈地点和时间;准备访谈问题。

    二,背景无关面谈提纲

    • 背景无关问题 面谈时,只问与需求本身有关的问题,而不带有任何与可能的解决方案有关的背景
    • 问背景无关问题是为了避免我们已有的背景知识干扰我们对客户问题的发现和理解
    • 通用提纲
      1. 建立客户或用户简档
      2. 评估问题(哪一种[应用类别]问题您还缺少好的解决方案?他们是什么?(不断问“还有吗?”))
      3. 理解使用者环境
      4. 归纳理解(用你自己的话列出客户描述的问题)
      5. 分析员对客户问题的输入
      6. 评估你的解决方案(如果有的话)(概括你建议的解决方案的主要能力)
      7. 评估机会(单位内还有谁需要这个应用?使用这个应用的这类使用者有多少人?您如何评价一个成功的解决方案?)
      8. 评估可靠性、性能和支持需要
      9. 其他需求
      10. 总结
      11. 分析员的总结(面谈后,趁资料还在心中,总结该使用者/客户识别的三个优先级最高的需要或问题)

    三,后续处理

    • 每次面谈后,整理最重要的三个特性。由于不同面谈对象得到的特性有重叠,10次面谈可能产生10~15个特性。

    四,注意事项

    • 面谈时,记住目标和提纲内容,尽量在轻松、自然的氛围下进行;
    • 如果客户兴致很高,谈论一个问题时比较啰嗦,甚至稍稍偏题,也尽量不要打断客户;
    • 面谈时尽量用脑记忆,分出条理,简单做笔记,事后整理成文。不建议电子录音(会造成紧张感)
    • 不能用问卷调查代替面谈。问卷调查的问题和答案(封闭性问题)具有一定的引导性,会影响调查结果。
    • 问卷不适合发现未知的需求
    • 问卷调查只适合在已知有限选项中做抉择时高效、广泛地征求大量涉众的意见。