写在前面

最近一直在带着几个小伙伴共读《软件需求最佳实践》这本书。

说起这本书就不得不说说这本书的作者徐锋老师。
我是早前参加过徐锋老师的需求分析课程，当时就觉得收获特别大。
特别是我那个时候做了好几年BA，但是所有的知识点都是片段形式的，就是属于刚刚把零散的点连成线的状态。通过那次培训，我隐约的指导怎么把我的知识和经验连成面，形成体系了。
课程结束后，我不仅在公司内部多次分享过本次课程，还在线上做过两次分享。

后来就买了《软件需求最佳实践》这本书研读。
《软件需求最佳实践》这本书今年我是第三次阅读了，不得不说每次阅读都会有新的感触。

第一次读的时候因为听过徐锋老师的课，所以看的时候感触特别深。那个时候刚好公司开始准备将需求这件事情“正规化”，也就是要形成自己的组织套路，制定大量的流程和模板，我就以此为基础开展工作。

第二次读的时候，主要针对UML的部分做了仔细的阅读。这本书虽然不是专门讲UML的，但是比起一些专门的UML的书更容易理解，也许是因为徐锋老师本人就比较擅长打比方做隐喻吧。特别是对于类图、构件图这类不常用的图的讲解，很有意思。后期在工作中，我也尽量将这些方法应用进去。读到第二遍，我渐渐明晰了重要的其实并不在于方法本身，而是在于方法的思维方式。

这次是共读，因为有不少小伙伴会在群里要模板，问转行或者新人学习方法，但是又觉得自己读这类书坚持不下来。这本书是作为我的BA书单推荐的第二本书，而且比较适合解决有点需求的概念，但是只有零散的点，没有连成线和面的情况。

今天就这第三次的阅读做一个总结。

SERU

● S：Subject Area的首字母，它表示子问题域；这是“信息工程”中的概念，核心的思想就是根据业务区划来分解系统，使系统的各个部分在业务上保持相对独立，降低耦合性。
● U：Use Case的首字母，也就是用例，这是RUP之父Ivar博士发明的一种需求技术，它是迄今为止应用最广泛的技术之一；在笔者的实践中，发现它是封装需求的最好手段，可以作为需求组织的最小单位：一个业务活动（B类用例）、一个具体的报表项（R类用例）、一个具体的接口（I类用例）。
● E：Event的首字母，表示事件（对于信息系统而言就是业务事件），它是流程的起点，最早源于实时系统的需求分析，后来被结构化分析方法之父DeMarco引入到业务软件的分析中；通过业务事件的标识，就能够找到流程，通过流程就可以有效地将不同的场景串接在一起，起到承上启下的关键一环，它覆盖了OLTP（联机事务处理）部分的需求。
● R：Report的首字母，表示查询、分析、统计，用来覆盖MIS（管理信息系统）部分的需求；通过寻找管控点（也就是从意图出发），以确定报表类型，然后再细化到具体报表项。

需求分析过程

首先通过对中高层客户的访谈确定需求的方向和思路，通过构件图等确定项目的范围。
然后通过对中层客户的访谈和调研明确目前的业务现状，进行场景用例、流程等方面的分析。
最后通过对操作层用户的访谈和调研，确定需求细节查漏补缺。

需求管理

首先需要明确需求基线“逐项列举的在应用程序的某个特定版本中提交的特征和需求的集合”。
对项目过程中的需求变更进行管理，更需要加强的是对变更的分析。
在管理的过程中，还需要对需求进行追踪：从用户原始需求向前跟踪到软件需求，从软件需求向前跟踪到下游工作产品；从下游工作产品向后回溯到软件需求，从软件需求向后回溯到用户原始需求；以及软件需求到软件需求的跟踪。

写在最后：

针对需求方面的书籍，我在推荐的时候一般会问你现在的程度。
如果你现在连点都没有的话，我会建议你去读《软件需求2》，先知道什么是软件需求，过程是什么，建立概念。
如果你现在已经有一些初步的概念，也实践了一段时间，却总是觉得自己的能力提高有限，很多时候回背锅、掉坑里。有的时候这锅和坑来自于客户，有的时候来自于开发人员等等，那么我就会建议你读这本书。
虽然实践很重要，但是我还是那句话：

看书的过程就是让你在行万里路的时候多个交通工具或者是一双好穿的鞋子，而不是用的爬行或者很难穿的鞋子徒步。

小婧是一名行走在产品路上的资深业务分析师（BA），如果想与我同行，就请关注我吧！