一个系统开发的成败，好的需求是必要条件，这一点毋庸置疑。
经过n年的争斗，大部分人还是不得不承认，文档是需求最好的载体，我们离不了它。请不要说代码是最好的文档，且不说这么多年了敢拍胸脯说代码特别好，特别可读的项目有几个？开发的同学起码不要指望业务人员精通你的编码，其实也不要指望测试人员，也没理由指望，因为术业有专攻。
但是没有需求文档又不行，如何能够有同时满足下面所有条件的文档呢？
1.保证所有项目干系人和交付团队的成员都对需求要交付那些东西有一致性的理解。（大家满意）
2.有准确、完整的需求避免由模棱两可和功能缺失造成的无谓返工。（开发，测试，项目经理满意）
3.有用来衡量某项工作是否已经完成的客观标准。（测试满意，项目经理满意）
4.在短时间交付的前提下满足上述要求。（大家满意）
5.文档能够被及时修改，及时使用，易于维护。（大家满意）
6.文档编写成本低，其它变更成本低。（大家满意）
这里面好多貌似都是矛盾的，比如1和6。文档能同时满足准确，易维护，随写随用这3个特性么？《实例化需求》这本书给出了肯定的答案：实例化需求 也就是将需求变为可以执行的验收测试用例，也就是书里说的活文档。如果满足可执行的条件，需求肯定是定义清晰的；跟持续集成联系起来后，代码实现马上可以被验证；如果修改了活文档也就等于同时修改了测试需求与测试用例，代码实现没有及时修改的话，马上就会以测试失败的形式报警，这样一致性可以得到保证。再仔细分析还有好处若干，这简直是一石n鸟皆大欢喜的革命！ 有这种好事？
书中给出了N个成功案例，并且是指名道姓的，不信你可以google它们甚至人肉出它们的联系方式去问问。真是一张让饥饿的IT人垂涎欲滴的大饼。真的有这么神奇么？书已经翻完了一遍，里面给出了很多实战的例子，的确相当有启发，但是很多地方也有很多疑问。今后一定要找机会尝试一下，不过在此之前还是先再读两遍，把里边的一些细节吃透再实践。后续会争取把一些书里的关键点和我不懂的地方贴出来。