软件需求分析-需求开发-需求定义与需求捕获

C4需求定义

一、任务

确定项目的宏观需求，就是定义项目的业务需求，明确项目的目标和范围
1.需求定义的时机
原则上应该是在项目立项时完成。
清晰的项目目标和范围定义，能够引导需求工作顺利进行
2.需求定义的理念
问题、机会
对于IS系统而言，要么是解决问题的，要么是创造机会的，首先应明确你要解决的问题是什么，要把握的机会是什么。
需求定义的过程（GPOA）:
~目标（Goal）通过内部寻根或外部溯源的方法新疆整个项目要解决的问题或机会罗列出来。如“报废率太高”
~问题（Problem）：这对目标层面的问题进行分析，找到导致该问题产生的根源问题，然后罗列。如“订单不准确”、“运输损耗”等
~可选方案（Option）：针对每个问题列出可能的解决方案
~建议方案（Answer）最后从各种可选方案中选出比较合理，对解决问题贡献度更高的方案

二、五步法进行问题分析

1.在问题定义上达成共识
问题定义就是理解真实世界中的问题和用户需求，然后提出满足这些多方面的解决方案的过程。把问题拿出来，得到所有人的共识。
问题定义的技巧
~转换
~本源
2.分析问题背后的问题
1）鱼骨图-定性
2）帕累托图-定量
3.确定相关人员和用户
4.定义解决方案的界限
范围是设计的事、物，边界是人与系统的职责边界。
5.确定加在解决方案上的约束

三、需求定义的产物与要素

1.产物
根据项目类型的不同，需求定义的产物大致可以分为POS（Project Overview Specify，项目综述）和Vision（愿景）两大类。
Vision文档更加重视市场潜在机会的分析，因此甚至会加入诸如SWOT等市场分析的内容。
2.要素
~目标

应满足SMART原则：
具体的（Specific）
可度量的（Measurable）
可达到的（Attainable）
和其他目标具有相关性（Relevant）
有明确的的截止期限（Time-based）

具体写作时，应从目标、业务优势、度量指标、合理性、可行性和可达成性方面编写。
~范围
~相关人员和用户
~相关事实与假定

四、定义需求范围

1.划分主题域
在分解系统时，应按照业务的脉络来划分
2.使用构件图
构件是系统设计的一个模块化部分，隐藏了内部实现，对外提供一组外部接口（用小圆圈表示）。
构件与接口之间的关系：实现关系，使用关系

案例分析（看书）
3.确定主题域范围
~上下文关系图绘制要点：

首先用一个矩形表示系统，写上系统的名称，将整个系统看做一个黑盒子；
然后找到该系统的所有Customer（客户），考虑将这些Customer会发起什么事件，这些事件会引发Worker（内部工作人员）的什么工作，将这些序列逐一表示出来；
最后再看看系统的每个Worker还有没有一些主动发起的事件

先考虑Customer再考虑Worker。
案例分析（看书）

4.标识业务事件与报表
~业务事件解析

• 业务事件是业务流程的出发点，标识处业务事件能够帮助我们识别出业务流程，而业务流程是为了响应业务事件而触发的一系列业务活动，它通常是由不同部门、不同岗位协作完成的。因此业务流程的信息掌握在中层管理人员手里。

• 业务活动则是从属于一个特定的业务流程，是一个人的活动。因此一个业务流程应该由一个或多个业务活动组成。

• 业务步骤是完成是完成某个业务活动所需要的具体步骤，因此业务活动和业务步骤的信息都是掌握在操作人员手里的，属于细节信息。

• 业务事件的类型
  可以分为外部事件和内部事件

   外部事件：来自系统外部的事件，也就是系统参与者发起的
   内部事件：系统内部触发的
  

每种事件类型又可以分成两种：
外部事件：

Customer发起：由主题域外的客户发起的
Worker发起：由主题域内的客户发起的

内部事件：

时间事件：由于达到某一时刻所发生的事件
状态事件：由于到达某一状态所发生的事件

案例分析（看书）

5.生成需求大纲

总结：
需求定义第一步：划分主题域
需求定义第二步：确定主题域范围
需求定义第三部：标识业务事件与报表

C5需求捕获

需求捕获是需求开发中的第一个活动。要点在于计划性和科学性。
计划性体现于对捕获对象、问题、时间的计划
科学性则表现在如何有效的选择何时的捕获方法

一、需求捕获的策略

需求捕获的过程是人与人打交道的过程
1.需求捕获应该是主动的
强调需求分析人员在整各过程中应该充分发挥主动性，属于撒谎捕鱼而不是休闲钓鱼等鱼上钩。
2.需求捕获应该是聚焦的
即在进行需求捕获（通俗的说就是与客户进行需求询问的时候）应该尽量以具体的问题或者需求进行询问和捕获，而不是用发散性的问题。这样会避免需求重点的偏颇。
链接：https://pan.baidu.com/s/1TQFn7nGc1id3va9R-ivcbw
提取码：yr4h
3.破解需求的冰山模型
用户的需求就是一个冰山，有很大一部分信息是隐藏在海平面之下的。
冰山可以分为三层：

意识到的需求：海平面上的部分，通常是一些困扰用户的问题、用户自己能够设想得到的功能。需求分析人员如果仅仅知道这层信息，那么其他下面的需求就会以需求变更的形式出现。
无意识的需求：它是用户的实际工作场景，开发人员如果能够对这些场景做到“感同身受”，就可以大大减少需求变更的数量。具体方法就是需求分析人员加强对业务知识的捕获。
未梦想的需求：需求分析人员在对问题域充分理解的基础上，选择合适的技术方案，才可以创造出用户为梦想到的功能。

4.破解阻碍需求不好的心理现象

• 言过其实心理
• 越俎代庖心理
• 非正事心理
• 抗拒心理
• 推卸责任心理

5.不要忽视对变更可能的捕获

• 最严谨的方法是对历史项目、当前项目的变更进行分析、归类。

• 最实用的方法是开发人员做一次访谈，了解他们最惧怕哪些方面的变更，哪些变更会导致较高的工作量。

• 最笨的方法是“前车之鉴，后事之师”，在整个软件开发过程中，不断总结哪类的变更比较多，在后续的捕获互动中引起重视。
  6.需求协商

• 揭示解决方案后面的问题
  问题与解决方案之间通常是一对多的关系，因此在需求捕获时要善于使用？，为什么要实现这个功能找到真正的需求

• 共赢性谈判
  需求协商是一种谈判，一种共赢性的谈判。需要双方剥开立场，寻求利益诉求。
  共赢性谈判的技巧就在于抛开立场，追求满足大家的利益诉求，而要完成这样的转变，在谈判过程中的核心技巧就在于问出对方的立场。就是间接问出对方预期想要得到的利益所要付出的最低代价是什么。还是一样的问：为什么要实现这个需求？

• 转换技巧
  a.相对重要——>相对次要
  不能孤立的看待需求项，应该将所有的需求视为一个整体
  b.关注点转换
  c.隐喻
  用对方熟悉邻域的事物来解释深奥的问题的手段。

二、需求捕获的主要方法

1.用户访谈

• 被访谈者的类型通常有：高层管理人员、中层管理人员、操作层、技术团队。对高管的访谈结果是对中层管理人员访谈的指导，以此类推。而对技术团队的访谈则是突发的。在需求捕获人员无法确定技术能否实现，实现成本是否过高时进行。
  

• 每次访谈的时间应控制在一个小时之内，时间安排应如下图
  在访谈时应视情况将主体问题域即兴问题进行穿插

• 记录工作——建议采用“笔记+录音”的组合方式

• 访谈中的沟通技巧
  a.制作访谈问卷并事先发给被访谈者
  b.把握语言结果——问问题，听取回答，然后反馈理解
  c.有效结合不同的问题类型——判断题、选择题、简答题
  d.善于安排问题顺序——金字塔结构、漏斗结构、菱形结构

• 用户访谈计划
  包括计划时间、人员、内容
  2.用户调查
  3.文档考古
  4.情节串联板
  在用户界面原型上以业务场景作为主线索，进行交互式过程、流转过程的模拟。
  5.现场观摩
  6.联合开发
  让用户代表、需求分析人员、开发人员一起，以头脑风暴的形式进行需求探讨。

三、记录工具

任务卡片、用户故事、Volere白卡