相信很多吃货都有过这样的经历，在饭店觉得一样菜很好吃，回家按照菜谱做不出想要的味道，而且有时候会有正版小龙女和淘宝9块9包邮小龙女那么大的差距。有一段时间我就特别喜欢吃拔丝红薯，按照菜谱标准做法怎么也不成功，后来想了两个办法，先在网上查“成功人士”的“秘籍”，然后让老妈手把手教，做出来的菜不敢说是正版，但也可以是高仿品了！
对于一个吃货，不能亲手做出美食是一件头疼的事，对于一个资历较浅的需求分析人员，即使有《软件需求分析》这本菜谱，照样不能当大厨！还好偶遇《软件需求最佳实践——SERU过程框架原理与应用》这本秘籍，先做个好帮厨吧。
这本书有两个特点，其一，书中没有大量的理论和教条，有很多案例和场景，而且这些场景在我以往的工作中大部分都遇到过，好多场景中呈现的问题曾让我，甚至是我在的团队痛苦不堪。其二，书中不仅介绍了做需求工作的很多方法，而且还用大量的案例分析启发读者如何思考和面对这些困难，看到这些问题的本质。
如何确保需求的完整性？其本质就是要让用户更好的参与到完整性评价中，采用“业务导向”的组织结构，这样用户才能给出更好的建议。
两份《家装方案设计书》：一份目录中是“客厅”、“厨房”“卫生间”……，另外一份目录是“水路”、“电路”、“家具”……
上述场景并不陌生，以前是不是也干过拿着电路方案“逼”用户提意见的事情呢！
谁才是知道用户最需要什么功能的人呢？我们为这个问题曾经争论不休，用户、开发人员、产品经理个说其词，其实应该是软件本身。试着回忆一下，有多少软件上线后很多功能是闲置不用的，这对于产品优化有很大的帮助。
如何应对沟通失真？这是个老生常谈的问题，一般都会说利用文档，提高文档质量等等，说的没错，可就是没效果。很有效的偏方就是及时复述，这个方法可以广泛的应用到用户访谈、需求评审、SRS验证等场合中。
需求分析是需求工程中最为核心的工作，需求建模是主要的手段，面对“分析”如此抽象的词，从何处入手？总的来说是先分解，再提炼。按照不同的线索，如业务流程、程序结构、业务场景进行分解，然后再自底向上提炼，如提炼每个业务事件中的类。这个过程根据沟通需要再选择合适的模型。
就拿最熟悉的用例图来讲，之前对用例图理解不深刻，大部分是“新建**”“修改**”等操作，其实根本没有做到分析，而是将系统动作进行了罗列。
应用“业务动词”命名法可以解决上述问题。
需求人员是否应该用高保真的原型将界面确定下来？这个问题我参加呢讨论不止三次，其实需求人员应该提供的是设计依据而非设计结果，而且界面原型也不是解决方案，只能说是约束和建议，重点在于实现用例事件流的交互过程，讲述每个界面满足的用户意图。确切的说应该在交互过程上多下功夫。而非界面的元素个数、位置、大小等信息。
书中有几句特别喜欢的话与大家分享：
业务场景是需求之魂
需求建模的过程远比建模的结果更重要
对于需求分析员而言，正真的专业主意是基于业务利益（解决问题、创造机会、提高管控力等）的沟通。
对问题进行了正确的定义，意味着成功解决了一半
善于打比方是提高跨专业沟通效果的好方法
这本书确实很实用，我还关注了作者徐锋的微博 fjxufend，有兴趣的朋友可以关注一下。
