共读《掌握需求过程》P5 需求沟通（16~17章）

共读.jpg

第十六章 沟通需求

在开发世界的一头，你有业务；在另外一头，你有开发者和技术员。
他们已经为这项业务做了一些工作。
对需求的要求是：它们传递的方式必须让收到信息的人正确去读它、理解它、利用它。
“沟通需求”并不是必须要将需求写成规格说明书，但是它们必须规范到一定的程度，让所有涉及的利益相关者都能看清楚，并且同意你对需求的理解。
让需求正确，不是让开发变得更加官僚主义，而是让它更加有效。

1 将潜在需求变成书面需求

在网罗需求或制作原型时，发现的需求并不总是准确的，因为它们只是关于需求的想法或意图，有时候是模糊的半成型的。
而你得到的需求规格说明是产品构建合同的基础。
因此，它必须包含清晰、完整、可测试的要求，说明必须构建什么。
为了做到这一点，我们利用了规格说明书模板和需求项框架。
模板是一个拿来就可以用的需求规格说明编写指南或检查清单。
需求项框架是针对单独一项需求的容器，我们称之为“原子需求”。

2知识与规格说明书

在开始编写需求，并将它们汇集成需求规格书之前，值得花一些时间来考虑需求过程中积累起来的知识，比如下图的需求知识模型。

共读《掌握需求过程》P5 需求沟通（16~17章）

建议大部分的信息都可以包含在规格说明中。
知识模型中的累与其他类关联，这些关联表示的工作关系，未来模型的信息提供了额外的意义。可以将这些知识模型看作是收集管理和追踪的需求信息的一种抽象表示。
现在由你决定如何格式化并保存这些知识。
你决定使用怎样的自动化过程和手动过程，组合来记录和追踪这些内容。
你也应该考虑哪类的知识的哪些部分放在哪些文档中公布。

3 需求规格说明书模板

需求规格说明书模板是“站在巨人的肩膀上”完成的。
本书的作者从那些成功构建的产品的需求规格说明中，借用了一些有用的元素，把这些最好的元素打包成一份可复用的模板。
这个模板可以作为你的需求规格的基础，这样你也“站在了巨人的肩膀上”。

共读《掌握需求过程》P5 需求沟通（16~17章） 共读《掌握需求过程》P5 需求沟通（16~17章）
模板包括了五大部分内容：

• 第一部分是项目驱动。这些因素首先导致了项目的发生驱动。包括了项目的目标，为什么你会参与该项目的需求收集，以及谁想要这个产品。
• 接下来是项目限制条件。它们将限制条件的需求和结果，限制条件在项目启动阶段写进规格说明，但可能有一些机制能够更早地确定它们。
• 接下来是产品的需求。功能需求和非功能需求，每一项需求都以一定的详细程度进行描述，这样产品的构建者就能精确地知道要构建什么来满足业务需要，要测试什么，来确保交付的产品满足其需求。
• 最后一部分是项目问题。这些不是产品的需求，而是如果产品要件变成现实就必须要面对的问题。模板的这一部分也包括了“后续版本需求”，其中保存那些不打算在产品的首次发布中实现的需求，如果你采用迭代开发技术，“后续版本需求”类似于开发列表。

4 发现原子需求

原始功能需求和非功能需求应该写的更正式采用一致的结构，我们称之为“原子需求”。
因为他们不需要分解。
他们确实包含一些属性，就像真正的原子，包含一些亚原子粒子。
但作为一个单元来处理更有用，这些属性构成了完整的原子需求，最好是看成需求项框架，比如我们之前提到过的白雪卡。

共读《掌握需求过程》P5 需求沟通（16~17章）

5 汇编需求规格说明

与其说需求规格说明书写出来的，不如说是汇编的。
顾客需求模板和白雪卡提供了方便的指导，说明了汇编哪些内容才能得到完整的需求规格说明书。
模板指出了需求规格说明书要包含的主题，白雪卡表明了每项源自需求需要包含的内容。

共读《掌握需求过程》P5 需求沟通（16~17章）

6 自动化的需求工具

如果项目中有多位需求分析师，你会发现随着工作的推进和需求数量的增加，自动化自动化的工具会带来好处。
工具只是为你记录需求。
在你决定使用某个工具之前，请将需求知识模型也可用的工具进行比较，该工具能帮你记录哪些知识，不同类知识之间的关系如何记录，该工具能帮你维护哪些关系。
要知道你不太可能找到一个工具，能处理你的知识需求知识模型的方方面面。
但你肯定能找到一个尽可能接近的。
四处看看，你肯定会找到适合记录供需求的工具组合。

7 项目问题

项目问题是需求活动中发现的一些关注点。
我们在需求规格说明书中加入项目问题是担心如果不这样做，就会遗漏它们。
但是如果你的组织机构已经有了过程或合适的文档来记录这些信息，就不要将这些信息加到需求规格说明中。

本章小结

无论何时，如果需求分析是有所发现，就写下需求或部分需求。
并非所有的需求都是同时完成的。
正确的编写需求是很重要的。
一组好的需求能得到数倍的回报：
构建工作更精确，维护成本更低，完成的产品更准确地反映了客户的需要和想法。

小婧的小结：

需求规格说明其实一直都是我们BA最关注的内容。
虽然很多的互联网项目因为迭代周期短，不会形成大篇幅很正式的需求规格说明书（SRS），但是不论你是用什么方式进行记录，比如在原型上记录，或者采用白雪卡，或者采用用户故事。我觉得你需要“汇编需求规格说明”，也就是将你的产品中的所有需求及相关属性进行汇编。
这个是一项非常重要的组织过程资产，为后期的开发、测试、维护、使用、优化都提供了依据。

---

第十七章 需求完整性

在需求过程的某个阶段，你需要发布全部或部分需求规格说明。
因为其他人如开发者、测试者、市场人员及供应商需要它。
待发布的需求规格说明不一定包括全部需求。
在发布之前，需要确保相对于它的目的它是完整的。
这里使用术语“规格说明”来表示你拥有的任何形式的需求组合，不一定是正式的书面规格需求说明书，甚至不一定是正式的。
复查需求规格说明是否完整，可以考虑如下内容：

• 确定是否遗漏了需求
• 排列需求优先级，这样构建者能理解需求的重要性和紧急性
• 检查需求之间的冲突，这会阻碍一项或多项其他需求的实现
• 预估构建的成本，物评估项目所面临的风险复查的过程是迭代式的，寻找问题或遗漏，修正问题，这可能意味着引入新问题。
  需要让这个过程迭代一次或两次，确保规格说明书中没有漏洞。

1 审查

有一种相当有效的规格说明审查方式，它是一个正式的过程，称为Fagan审查，具体步骤如下：

• 审查过程开始时，有一名协调人确定要审查的材料和审查者
• 审查者收到被审查的文档的概要，他们大概有一天的时间来研究这些材料
• 审查会议限制在两个小时以内，利用以前发现的问题的检查清单来分析文档
• 如果发现新错误，不在清单上的错误，就会更新清单
• 作者对文档进行返工协调人，确保所有的错误已经消除，如有必要协调人会安排跟进的审查

2 发现遗漏的需求

功能需求应该足够完成每个用例的工作。
为了检查这一点，假设你就是这个产品，把每个产品用例推演一遍。
如果做了需求要求的所有事情，是否能够得到用力的成果，用户是否满意地认为产品会完成他们的工作要求。
寻找产品必须处理的异常情况，复查场景。
针对每一步确定是否可能产生异常，或者是否有异常组织用户到达这一步。
针对非功能需求类型检查每个产品用例，是否具备了它需要的和合适该类用例的所有非功能需求。

3 发现所有业务用例

针对每个业务事件，你确定业务的响应，并确定相应的哪些部分需要由产品来完成。
建议你每次收集一个产品用例的需求，持续到涵盖所有业务事件为止。

4 排l需求优先级

确定优先级很复杂，因为他们涉及不同的因素，而且这些因素彼此之间常常产生冲突。
另外由于不同的利益相关者可能有不同的目的，对优先级达成一致意见可能比较困难。
虽然困难，这项工作迟早要做，越早越好，越早排队优先级就越容易。
每项需求都应该包含：顾客满意度和顾客不满意度评分。
这些评分帮助顾客考虑单向需求的相对价值，并对它们排列优先级。
影响优先级的因素有：

• 实现的成本
• 对顾客或客户的价值
• 产品所需的时间是技术实现的容易程度
• 业务或组织机构实现的容易程度
• 对业务的好处
• 遵守法律的要求

何时确定优先级？
一旦存在两项任务即可作出选择。
让需求知识变得越可视，就越有机会进行不盲目的选择，并帮助他人进行选择。
不断排列优先级的一部分，原因是期望值管理。
利益相关者常常假定术语“需求“，意味着这些功能肯定会实现。
需求实际上是一些期望和愿望，需要清楚地了解他们，以决定是否实现它们。
如果你在项目过程中一直不断地排列优先级，人们就能够接受这种折中，而不会感觉到欺骗。
排列优先级让利益相关者准备好接受一个事实，也就是你不能实现所有的需求。

小婧的小结：

需求的遗漏一直是一个大难题。
而需求的遗漏也是造成需求变更的一个非常常见的原因。
有的时候是BA觉得这“显而易见”，不需要进行描述。却没有想到会产生二义性。
我认为复查等方式是非常有必要的。
特别是找别人来复查。
当大家开始针对一段需求的描述进行讨论时，二义性就产生了。
我们必须保证需求是清晰、明确、可测试、完整，才能保证产品的正确性。
另外，关于需求的优先级我觉得有多种评分方式。
现在简单的高中低已经完全没有办法满足我们日益复杂的产品的需要了。

小婧是一名行走在产品路上的资深业务分析师（BA），如果想与我同行，就请关注我吧！