需求分析方法论：如何理解透需求？
如果把IT比做一个江湖，无论是什么公司什么业务的需求，练好这个武功心法“四层五步五清法”，可以从宏观上以及部分微观上理解用户的需求。
需求分析的步骤
从事需求分析以来，不管是自己参与的或是完全由自己一个人需求调研的，也有过大大小小项目需求调研的经历。这周去了深圳某券商进行了为期一周的需求调研，需求调研完成之后，其实总结下来有些套路可以使用。
如果把IT比做一个江湖，无论是什么公司什么业务的需求，练好这个武功心法“四层五步五清法”，可以从宏观上以及部分微观上理解用户的需求。之所以说是部分微观，是因为具体的需求，还得具体的分析，但练好这个武功心法，在需求分析的宏观上可以说没有问题。
对于需求分析人员从宏观上做需求调研的时候，需要弄清楚这四个层次（对于一般的需求分析人员弄清楚前面两个层次也是可以的）。
四层：
第一层职能层：梳理各部门的职能。
一个系统如果涉及到很多部门，那么梳理各部门的职能能帮助我们去理解他们提出需求的原因，甚至通过了解各部门的职能反过头去质疑其他部门提出的需求。
举一个很简单的例子，某券商的风控部牵头要建设信用风险管理系统，为实现监管的“同一客户，同一业务，统一管理”，风控部将其他业务部门也纳入到系统中来，在需求调研阶段，某业务部门提出在实现一个报表查询到时候，需要部门与部门的权限隔离，即固收部的看固收部的持仓数据，其他部门在看同一张报表的时候看不了固收部的持仓数据。
咋一听这个需求提的很合理，但是风控部的职能是从公司整体上控制风险并防范风险，风控部可以看所有业务部门的数据。
用户提需求的时候只是出于自身考虑，并没有想到其他部门，所以当需求涉及多个部门的时候，需求分析人员在需求调研阶段把各部门的职能弄清楚。
2. 第二层业务层：梳理业务。
没有人会无缘无故去购买一个系统，对于企业而言购买系统就是想将公司的业务放在系统上去做。不同类型的企业或不同部门，业务是不一样的，业务的复杂程度决定了系统的复杂程度，若一个复杂的业务能够被梳理的逻辑清晰条理清晰，系统也不会很复杂，但前提是你很懂很懂业务。
当一个业务小白如何快速的理解业务，可以搜集业务相关的名词解释，弄懂这些名词算四分之一理解业务。每种业务都会有其特定的术语，比如在物流行业，你需要知道什么是货代、邮路、头程、预报等等，在金融行业，你需要知道什么是股票质押、债券投资、融资融券、资管计划，除此还不够，你需要理解透每一个业务以及业务与业务的差别，比如股票质押与融资融券的差别在哪？
3. 第三层数据层：梳理信息。
这需要需求分析人员懂一些技术才能梳理清楚，对需求分析人员很高要求的一个层次。对于系统的底层数据，需要梳理数据与数据的流向，数据与数据的逻辑关系，这些都梳理清楚以后，对于现在的开发或是以后的迭代都能起到很大的作用。
4. 第四层：梳理支撑环境。
业务需求以及数据都弄清楚以后，还需要考虑非功能性的需求，比如系统的硬件环境和软件环境是什么，用谷歌浏览器还是IE浏览器等。
以上是四层五步法的四层，如何去实现上面的四层，做到以下“五步”：
- 根据组织结构梳理职能域，比如机构／部门的职能，各岗位的工作职责
- 根据职能域梳理业务元素，包括业务术语、名词解释等
- 根据业务元素梳理业务活动，如业务流程、业务环节、状态、信息等
- 根据业务活动梳理业务等内外联系，如业务协作、信息流向
- 描绘业务架构、信息架构，如用户分类、业务分类、信息分类
四层和五步做到以后，问自己几个问题，看看是否真正的理解需求：
- 业务对象清楚了没有？系统的用户以及各功能模块的用户是谁是否清楚。
- 业务流程清楚了没有？各环节的处理人以及处理动作是否清楚。
- 业务场景清楚了没有？每个需求的业务场景是否弄清楚，所有需求的业务场景是否能连接在一起，在脑海中完整的形成一个故事。
- 业务事项数量清楚了没有？一共有多少个需求，一共有多少种角色，一共有多少张报表，一共有多少个前置条件……
- 跨部门的业务关系清楚了没有？这个部门与那个部门的关系以及产生的哪些业务往来是否清楚。
四层五步五清法都做到以后，你可以把一个需求故事的大纲弄明白，再加上具体细节的需求分析（请查看之前的文章有写如何去分析不同类型的需求），把细节填充在需求故事的大纲里面，一个完整的故事就出来了。
需求分析人员能把一个需求故事从头到晚每一处都讲清楚，在需求的把控上大体上不会出错，要知道需求要是错了，后果是很严重的。
作者：Vi-Vi-Fu，微博@风将信至，杭州某金融软件公司需求分析师，负责过证券公司信用风险管理项目的需求分析。
关键字：产品经理, 需求分析, 业务, 需求
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
