今天按照需求实例化的五步法来重新修订之前的实例化案例，编写过程中，对需求实例化又有一些新的的理解。 在此之前我们所谓的“需求实例化”其实只是五步法中的“列功能”。而正常的“五步法”其实包括了:定系统，找用户，问目的，画场景，列功能。 ● 从定系统开始，去真正理解我们的系统边界，寻找在对外提供的用户系统中，我们和其他子系统的交互界面是什么。 ● 当系统边界定下来后，用户也就清楚了，对于一个大的系统产品来说，可能存在外部用户和内部用户。这一步，对于一些互联网的创新型产品，通过引入用户画像等用户挖掘的探索，就也有可能给这个产品创造一些竞争力。 ● 问目的，是我们通常忽略的，我们往往拿到的外部专业网给出的解决方案，而不是关于用户真正需要的是什么。在这个步骤中，往前走一步，理清用户真正需要的是什么，从问题域出发，反而可能会有突破性的收获。 ● 画场景，这部分是去理解不同的用户角色在什么样的场景下去使用这个功能，比如，用户是用手工操作？还是和代码去做对接，不同的应用场景，需要考虑的侧重点会不一样。这里，自然还可能涉及到一些特殊场景的识别。比如:安装和升级场景，多时区夏令时 等。 ● 列功能，需要提供满足不同用户在不同场景下的需要，我们基于现有的系统需要进行哪些功能的改造，可能涉及到对已有功能的修改，或提供新的功能。侧重点是这些功能应该如何验收。对于复杂系统来说，尤其需要考虑在改造已有功能的过程中的波及影响。 总结起来说，需求五步法就是一个具体的，可落地实践的需求分析工具，它提供了一个套路，让我们更全面更系统的对一个用户需求进行分析。通过这个分析过程，BA主导，频道与将各个利益相关的角色进行沟通和交流。输出物可作为开发编码和测试设计的入口。 往前走一步:基于需求五步法的需求实例化实践还可以很好的和MFQ进行结合，用于解决复杂系统复杂功能的质量保证，两者的结合会达到事半功倍的效果。这个五步法和三段论是啥关系呢？

一、入门Devops系列，带你从头了解DevOps这一部分的内容都无法访问了

我所在的项目就是这样的问题，什么东西都要的很急，回顾过来，返工严重。这个模型从团队自身角度去分析问题，很有建设性。

太棒了，我感受到了学习的快乐。

哇，做的真漂亮！狠狠的学习一下

优秀啊，不了解敏捷文化时还会对站会的形式主义抵触，现在明白了其中的价值，真香！