最近在做一个项目的应标，看着满眼的项目技术规范书，我是一脸的茫然，满脑子的浆糊。为何这么说呢，首先我对业务不熟悉，其次我对相关的技术系统也不熟悉。那么面对这样的一份工作，顿时觉得自己之前的知识积累是多么的贫瘠。我该如何去根据技术规范书理解需求，进行需求沟通一事呢？如何理解透需求成了我所关心的重点，我是查找了各方面资料以辅助理解或是咨询他人。
怎么破，怎么破？
我在网上查到这样一句话：“无论是什么公司什么业务的需求，练好这个武功心法“四层五步五清法”，可以从宏观上以及部分微观上理解用户的需求。”
如何理解透需求还是要从需求分析开始，上周去了北京某运营商软件研究院进行了项目的需求沟通，虽然主要是为了对标拆标，但是也根据学习到的路子做了一些简单的总结。
对于需求分析或者需求管理人员，需要弄清楚这四个层次，一般目前我只要理解到每个层次的大概就可以了。此次我的关注重点是在前面的两个层次上。
具体实现的话只能交给研发了。
如图所示理解：
第一层职能层：梳理各部门的职能。
一个系统如果涉及到很多部门，那么梳理各部门的职能能帮助我们去理解他们提出需求的原因，甚至通过了解各部门的职能反过头去质疑其他部门提出的需求。
第二层业务层：梳理业务。
没有人会去做一个系统，对于企业开发系统就是想将公司的业务放在系统上去做。不同类型的企业或不同部门，业务是不一样的，业务的复杂程度决定了系统的复杂程度，若一个复杂的业务能够被梳理的逻辑清晰条理清晰，系统也不会很复杂，但前提是你很懂很懂业务。
当一个业务小白如何快速的理解业务，可以搜集业务相关的名词解释，弄懂这些名词算四分之一理解业务。每种业务都会有其特定的术语，比如在客服行业，你需要知道什么是接入、什么是外呼等等，你需要理解透每一个业务以及业务与业务的差别，比如呼入与外呼的差别在哪？
第三层数据层：梳理信息。
这需要需求分析人员懂一些技术才能梳理清楚，对需求分析人员很高要求的一个层次。对于系统的底层数据，需要梳理数据与数据的流向，数据与数据的逻辑关系，这些都梳理清楚以后，对于现在的开发或是以后的迭代都能起到很大的作用。
这个层次是我目前的弱项了，但是对于哪些数据是自有平台产生，哪些数据是外围接口提供，这个是这次项目的重点把握的。
第四层：梳理支撑环境。
业务需求以及数据都弄清楚以后，还需要考虑非功能性的需求，比如系统的硬件环境和软件环境是什么，用谷歌浏览器还是IE浏览器等。
对于这一部分我倒不是很熟悉，但是对于某运营商的天宫平台为部署基础，这一点是必须明确的，也是需要对于开发人员阐明的。
以上是四层五步法的四层，如何去实现上面的四层，做到以下“五步”：
1、根据组织结构梳理职能域，比如机构／部门的职能，各岗位的工作职责
2、根据职能域梳理业务元素，包括业务术语、名词解释等
3、根据业务元素梳理业务活动，如业务流程、业务环节、状态、信息等
4、根据业务活动梳理业务等内外联系，如业务协作、信息流向
5、描绘业务架构、信息架构，如用户分类、业务分类、信息分类
四层和五步做到以后，问自己几个问题，看看是否真正的理解需求：
业务对象清楚了没有？系统的用户以及各功能模块的用户是谁是否清楚。
业务流程清楚了没有？各环节的处理人以及处理动作是否清楚。
业务场景清楚了没有？每个需求的业务场景是否弄清楚，所有需求的业务场景是否能连接在一起，在脑海中完整的形成一个故事。
业务事项数量清楚了没有？一共有多少个需求，一共有多少种角色，一共有多少张报表，一共有多少个前置条件……
跨部门的业务关系清楚了没有？这个部门与那个部门的关系以及产生的哪些业务往来是否清楚。
四层五步五清法都做到以后，你可以把一个需求故事的大纲弄明白，再加上具体细节的需求分析，把细节填充在需求故事的大纲里面，一个完整的故事就出来了。
需求人员如果能把一个需求故事从头到晚每一处都讲清楚，在需求的把控上大体上不会出错，要知道需求要是错了，后果是很严重的。
上述是学习的方法借鉴并运用，期待同行的你也能这样去做。
每个项目的目的不同，所以侧重点也会不同，对于需求的理解，可以根据目的去完成，例如我本次的目的是应标，会落实到POC用例演示上，好吧，POC评分用例才是最终的目的。
总的来说一句话：只字不差的阅读技术规范书，带着问题去理解，联系上下文去梳理，一遍不行就多遍，没一次的深入都会有变化，有更深的理解。
网友评论