需求分析的一个不错的FANCY方法

前ThoughtWorks高级业务分析师李默提出的FANCY方法，为创新性的业务分析指明了一个更为清晰的路径：

功能性需求（functional requirement）；

假设（assumption）；

非功能性需求（non-functional requirement）；

约束（constraint）；

线框图（y-wireframe）。

（1）功能性需求

整个需求分析中，首当其冲和最基本的方面就是功能的部分。功能性指的是业务逻辑和流程。需求分析师必须把用户故事拆分成更小颗粒度的包含细节的验收条件，抑或更小的故事卡。为了得到综合和透彻的细节，我们需要遵循5W1H进行故事卡的细化。

在这个阶段，需求分析师应该已经知道了这个用户故事的目标用户以及为什么需要这个故事：

谁（who，目标用户）——用户角色或用户画像；

为什么（why）——业务价值和用户的目标。

我们还应该考虑下面这些方面：

什么时候（when）——前提条件或先决条件；

位置（where）——界面的入口；

什么东西（what）——输入的数据；

什么东西（what）——功能中的业务规则和逻辑；

什么东西（what）——输出物；

如何做（how）——正常路径；

如何做（how）——异常路径和边界情况；

如何做（how）——对其他功能的影响。

（2）假设

掌握用户故事基于的开发的基本假设是很重要的。这些假设通常产生于产品概念试验的开始阶段和需求分析的前期。一些技术的和架构的假设会在团队估算故事卡的时候提出来。当我们团队对于一个问题不能马上得到一个回答时，我们会提出一个假设，然后团队会继续前进。

比如，一个故事卡可以有这样的假设：数据库表已经建好，或者开发之前接口API已经完成或者定义好。注意，一旦一个假设成立，这个假设需要持续地监控和验证。例如，我们可以安排一个调研任务去验证假设，如果假设不成立，这个故事卡需要重新估算，迭代计划也需要进行相应的调整。

一些常见的需要假设的地方是：

基础的技术架构或框架；

第三方API或者应用是否可用；

一些不确定的输入或输出。

（3）非功能性需求

每个项目都应该有一个非功能性需求的检查列表，非功能性需求通常是一些建立在用户故事更高一层的跨功能模块的场景。每个公司内部都应该有一个推荐的非功能性需求检查对照表，如果没有，我建议尽快出一个标准的针对异常处理的规范。

这里还需要强调的是，一些非功能性需求也可以拆分成独立的用户故事卡，安排在后期的某个迭代中。但是，我们在动笔写一个用户故事的时候就应该考虑到相关的非功能性需求，而不是在后来的迭代中才考虑，考虑不及时可能会造成返工的后果。

（4）约束

约束指的是一个用户故事的限制条件和边界，它突出的是这个用户故事不会做的和不能做的功能。例如，我们在这个用户故事中不会做一些关联的功能，这些相关的功能在另外一个用户故事卡中，或者我们在这个用户故事中不会解决某个相关的生产环境的缺陷。这给团队其他人员，比如测试人员，一个清楚的范围维度的指导。

一些典型的约束需要包含以下两个方面。

内部约束——一个用户故事卡应该包含的功能，但是由于一些其他原因，这些功能暂时不会被实现。比如，技术选型的时候出现失误、技术架构不支持等。用户需要使用这个带着局限性的功能，直到利用某一次大型重构的机会，通过改变技术架构解决这个问题。

外部约束——一个用户故事卡应该包含的功能，但是被拆分到另外一个用户故事卡中。用户需要有一个临时的替代方案，或者是体验稍差的方案，直到那个另外的用户故事完成。

（5）线框图

虽然名字是线框图，但是这里我用来表示一个用户故事

中包含的所有与前端或者用户体验相关的内容。

从广义上讲，这部分需要包含以下内容。

用户交互的流程：用户怎样与系统交互。

用户体验设计：确保页面的样式、业务流程、信息架构，还有导航设计合乎规范和逻辑。

设备兼容性：是否有用户会在移动设备中使用。

浏览器的兼容性：还需要支持IE8？为什么？

辅助性：在易用性上考虑多少设计。