如何将业务需求转化成软件需求

如题小编认为会将业务需求转化成产品功能这是产品经理的硬核技能之一，这是产品经理的价值所在。大到设计一个从无到有的产品，小到已有产品的一个小功能的设计。就好比是具备一种翻译能力，产品经理需要明白业务需求想要的是什么？然后转身设计出解决方案即产品功能来满足业务的需求。

关于业务需求，早些年在徐锋老师著作的《软件需求最佳实践》一书中有过定义书中描述到业务需求是反映企业/组织对软件系统的高层次目标要求，它通常是企业/组织的高层管理人员提出，它是软件系统建设的目标，这个目标体系两个方面：

1.问题，解决企业/组织运作过程中的问题，例如工作效率低、客户流失率高、销量低、管理手段粗放等。

2.机会，抓住外部环境变化所带来的机会，以便企业带来新的发展，例如数字化转型、智慧城市、工程全过程管理等。

关于软件需求同样书中也给了定义，“业务知识+问题列表+其他因素，其中业务知识包含业务事件、业务实体、业务规则，问题列表是指用户在工作中遇到的困难与障碍，这是软件开发时需要解决的问题，其他因素指设计约束和非功能需求。

其实在业务需求与软件需求之间还有一个层次的需求，即用户需求，它是我们需求获取的产物。也就是说当我们接收到一个业务需求后，我们要对使用软件需求的用户做访谈，需要梳理出用户的使用场景，也就是通过用户需求的梳理来进一步细化业务需求。然后将用户需求转化成产品功能。

业务需求转化成软件需求的实现路径：

需求定义是确定项目的宏观需求，定义项目的业务需求，明确目标和范围。

前文中提到业务需求是系统建设的目标，要么是解决问题、要么是创造机会，所以需求定义的第一步就是内部寻根或外部溯源。

需求定义的产物是需求大纲，类似项目建议书。制作过程采用目标—问题—可选方案—建议方案4个步骤。这其中分析问题是关键，因为对问题正确定义了就意味着解决了一半。分析问题时建议大家可以采用鱼骨图。下图为分析问题的过程示例。

通过分析问题域找到问题引发的原因，产品经理可以判断哪些是可以通过信息系统解决，从而可以更加科学的确定系统定位。

问题分析清楚后，需要对相关人员和用户进行分析，针对系统类的需求，会接触3个层级的人，分别是操作层、中层管理者、高层管理者，这3类人有不同的需求，需要分别摸清楚他们想通过系统分别解决什么问题，同时要思考重点关注谁的问题，会使项目有利推进。他们之中谁是用户，谁是直接使用产品的人。与这些利益相关方谈需求的时候需要把握边界，否则需求会像雪球一样越滚越大，最后以失控收场。因为用户永远会希望花同样的钱，获得尽可能多的功能，当你问他们更希望解决哪个问题时，他的回答是都希望解决。所以定义需求范围又是一个很重要的工作。这是需求定义的第二步。

明确系统要处理的主题域，针对每个主题域绘制上下文关系图，进而确定每个主题域的范围。

当上下文关系弄清楚后，需求定义第三步是将主题域的内容以业务事件列表和报表列表表示出来。

业务事件是业务流程的触发点，找出业务事件可以帮助产品经理识别出业务流程，它通常是由不同的部门、不同岗位协作完成的。通过业务事件可以分析出可能用到的报表，需求定义的阶段需要识别出报表的类型以及为什么需要这些报表，需要什么报表类型需要通过访谈一一确认。

分析到这里，最后就可以输出需求大纲，至此需求定义结束，后面进入需求获取与分析建模，下一期为您分享如何进行需求获取及分析建模。

本期（总计第20篇）分享完毕！