需求说明分析

1. 甄别需求

描述“是什么”，即需要解决的问题，组成需求说明的核心内容。需求说明定义了软件产品需要做什么，但不是“如何做”。很显然，需求说明的内容远不止“是什么”，还会包含“是谁”， 阐明了针对哪些干系人和“为什么”，将需求范围的界定合理化。然而，目标仍然是为了详细说明“是什么”，以及任何应该支持最终目标的问题的答案。

是谁——分辨出角色

干系人是指与软件利益攸关，又不能直接参与软件的构建过程的任何个人或群体。
在简单世界中，只会有一个干系人，他就是软件项目的发起人。在真实世界里很少发生这种情况，一般情况下，会有若干个干系人，他们的需求常常彼此冲突。这就是让所有干系人都参与的原因，也是必须分辨出各个干系人所代表的角色对软件功能影响的原因。
通过收集、合并干系人的“愿求”，将关注点从解决方案的属性转移到干系人的“愿求”上来，产生更多有价值的对话。也就是专注于需要什么，而不是如何实现它。

是什么 —— 明确一个可以分享的愿景

用几个词语描述软件产品需要实现的愿景。这个简短的、一行字的概况应该给所有人提供了关于一个软件产品最终必须是什么样子的共同的理解。一个清楚的愿景为整个开发周期提供了决策和承担责任的依据。
为了创建一个明确的一行字摘要，可以遵循高斯和温伯格推广的启发式命名规范。
“首先提议一个名字，接下来提供这个名字不十分恰当的三个原因，然后提议用另一个名字来解决这些问题。”重复这三个步骤，直到找到一个有用的描述。

为什么——识别共同目标

一个有意义的共同目标的概述，它清晰地从干系人的视角阐明了为什么产品、功能有存在的必要。
虽然开发团队知道如何构建软件，但很少有人对软件领域懂得很多，更少的人甚至不知道他们“为什么”要做以及要做什么。“为什么”意味着驱动他们行动的动机，共同目标证明了软件存在的必要。“为什么”会帮组开发团队理解干系人的动机，是软件的共同目标清晰明了。

2. 使用用户故事表达“愿求”

一个用户故事是用一段简短的、表达一部分可演示的功能的日常用语来描述的。一个用户故事不应该有难懂的技术术语，它需要能够被程序员和干系人都理解。在描述愿望是，它更多的是在描述如何被使用，而不是看起来什么样子，或者将如何被实现。

通过角色和利益来挖掘愿望

一个经典的格式描述：作为<用户>，我想要<愿望>，这样我就可以<收益>。
一种角色必须有唯一的名字将它与其他用户故事区别开。把任何能帮助将一种角色与其他角色区分出来的有用信息都写下来。
角色模型的目的是为了挖掘可能丢失的用户故事，通过角色给用户故事排序，每个干系人的愿望都被强调了。
与之类似的，另一种挖掘可能丢失的用户故事的技术是把重点放在语气收益上。这种技术使用不同的模板来写用户故事，将<利益>朝前挪，以示强调。
为了<收益>，作为一个<用户>，我想要<愿望>。

用故事版的方式阐明用户故事的需求

没有直观地描述用户体验，很难捕捉到需求的要点。从用户使用界面的角度来说明需求，能够帮组我们将无法描述的假设转换成明确地信息。每一个用户故事都可以使用故事板来加强理解。
最简单的故事板制作技术是纸原型法，可以是创建草图，甚至是随手涂鸦，画出用户界面的一次性原型。原型模拟了所有的交互。使用这个原型同干系人沟通时，可以快速得到他们的反馈，知道哪些是有效的，哪些是无效的。
收集完关于用户界面的想法后，需要将纸原型转换为低保真的电脑版故事板。这个故事板可以被当成是用户故事的可视化图解，由团队分享。
不要使用软件工具试图使用户界面跟最终产品一致，因为高保真工具要求对细节进行精密的、详细的说明，这是很花时间的，也不是在收集需求阶段的要求。
推荐软件：

• Balsamiq Mockups
• MockPlus

3. 使用场景确认用户故事

一个场景是一种转换演示，并从干系人的角度展示了因果关系。场景包含先决条件、一个行动和结果。先决条件是软件采取行动之前的当前状态；行动是指完成场景所描述的行为的事务；结果是指行动的后果。
一个场景无非是引起状态装换的行动。所有说明用户故事的场景合起来构成常规的状态机。详细说明一个问题的最大好处之一就是作为一个有限状态机，你可以完善问题的逻辑，也就是说，如果你能枚举状态的先决条件和结果，以及行动，那么描述出一个用户故事就是很简单地为每个节点创建场景。
要注意，一个场景应该只有一个行动。触发单个的行动对于保证状态转换的简单些是至关重要的。一个场景可以使用多个先决条件并且有多个结果。

用标准形式表达场景

有两种脚本技术，可以用来表达场景，同时也提供了创建自动化验证的基础。一种是被称为继承测试框架 (FIT: Framework of Integrated Test)的技术，另一种是被称为行为驱动开发(BDD)的已知——当……时——那么的句型结构。

使用FIT表格编码场景脚本

使用表格编写场景是一种简单有效的技术，这种技术的核心是FIT表格。这种表格利用纵列从左到右直观地表达了你能够在一个场景里找到的先决条件和结果。
行动: BuyMonthlyPass

消费者	车票	价格
学生	月票	￥76
老人	月票	￥87
标准	月票	￥126

先决条件 结果

使用已知——当……时——那么句型编写场景脚本

这个实践的核心是，已知——当……时——那么的句型结构，使用Gherkin语法，组织干系人的期望行为的描述。它限定每个场景只能有一次转换。
已知——当……时——那么的句型结构表达如下：
已知 一个先决条件
和 另一个先决条件
当 一个行为发生时
那么 会有一个结果和另一个结果
已知——当……时——那么句型比FIT表格更详细。

用例与用户故事

用例和用户故事是相似的，因为它们都是组织需求的方式。它们的不同之处在于它们的组织目的不同。
用例组织需求，形成用户如何与系统相关和使用系统的叙述。因此，他们关注用户目标以及与系统的交互如何满足这些目标。
用户故事（和类似的东西，通常被称为特性）为了计划的目的把需求分成块。故事被明确地分解，直到它们可以作为发布计划过程的一部分被估计为止。因为这些需求的使用是不同的，所以对于好的用例和用户故事的启发式方法将有所不同。
两者之间有着复杂的关联故事通常更细粒度，因为它们必须在一个迭代中完全可构建。一个小的用例可能完全对应于一个故事；但是一个故事可能是一个用例中的一个或多个场景，或者是一个用例中的一个或多个步骤。一个故事甚至可能不会出现在用例描述中，比如在弹出列表中添加一个新的资产折旧方法。