他们用业务用例图来表示是这样的：
通过业务用例图，我们能更清楚地看到业务中人、事、物之间的关系，也能注意到某些事件可能存在跨多个部门的情况。遇到这种情况时，需要我们在需求设计时需要额外注意。
步骤2：确定关键角色
2.1 为什么这么做
通过上一个步骤我们已经把业务中所有的人事物都整理出来了，但这并不代表着我们要对所有的人都进行调研。
如果碰巧我们负责的系统牵涉部门较多，涉及人员也较多的情况下，往往时间和精力都不允许我们对每位用户都进行访谈。
最好的方法是我们找到业务流程中的关键角色，仅对关键角色进行访谈。
提前整理出关键角色，也能够让我们对自己的系统目标有更清晰的认知，避免被一些杂乱的需求和业务流程扰乱了思路。
2.2 怎么落地
如何确定关键角色？
在确定关键角色之前，首先需要我们确定系统边界。
系统边界可以简单理解为：系统提供哪些功能？使用角色是哪些人？
如果你的系统没有明确的目标，那你就永远无法定义使用你的系统最关键的人群有哪些。
就好比我们写一篇文章，如果我们写的文章没有一个明确的目标，那么我们永远也无法知道谁会愿意点开文章查看，谁会愿意将文章全部看完。
这里还是继续以充值卡的业务为例子：
刚才我们已经主要梳理出了我们业务中包含的所有人、事、物，这时候我们定位充值卡系统主要提供——充值卡配置、充值卡购买/退款、充值卡售卖、订单管理、用户消耗记录、充值卡业绩看板的功能：
那么我们可以从业务用例图中筛选出，主要使用这些功能模块的人群有——销售、销售组长、财务、用户。
通过系统的边界，我们就能确定充值卡业务的关键角色是销售、销售组长、财务、用户。
薪酬专员虽然在我们业务流中也有被梳理出来，但是这次系统实现的功能和薪酬专员不会直接相关，所以薪酬专员不算是业务主角。访谈时主要针对确定下来的角色进行访谈就好了。
步骤3：调研关键角色
3.1 为什么这么做
怎样的调研才能让我们更准确地获取到用户需求？
答案就是我们要以用户视角去调研关键角色。
如果不以用户视角出发会怎么样呢？下面听我讲个小故事：
想象一下，我们生活在自行车刚被发明出来的时代。
今天我们刚领了工资，走入一家超市，想给自己买一辆自行车，这时候导购人员非常热情的招呼了你，并向你这么描述这辆自行车：“这辆自行车是个交通工具，它由刹车系统和传动系统组成…”
相信我们听到这句话一定会一脸懵，不知道自行车是做什么的，对我们有什么用处。
但如果导购人员换了种方式和你介绍：“自行车可以通过踩动脚踏来让自行车快速前进，让你更快到达目的地。当我们手捏着刹车，就可以使自行车停下来。”
这种介绍方式，是不是瞬间清晰了很多？
同样的例子换成我们将要搭建的系统。系统还没有被搭建起来，谁也不知道系统会长什么样子。如果我们在业务调研的期间就先入为主的以计算机的视角去描述系统，可能最后得到的结果和业务想要的结果会出现偏差。
3.2 怎么落地
那么我们怎样去以用户视角做调研呢？其实非常简单，在访谈的过程中，我们可以重点询问调研对象这四个问题：
- 您对系统有什么期望？
- 您打算在系统中做什么事情?
- 您做这件事情的目的是什么？
- 你就希望这件事情做完后有什么样的结果？
这4个问题本质上的思路就是询问对方希望系统能帮助解决什么问题，理由是什么，和他希望最终能达成什么目的。
理由和目的能帮助我们判断使用者操作某个动作是否是一定要在系统实现的，这个动作最终是不是能带来价值的。
下面以充值卡业务来举例，因为文章篇幅原因，这里我只展示销售组长的访谈记录前半部分，但是每个人的访谈记录的思路都是一样的。
我们在做访谈的时候不一定要照搬上面的4个问题，记住最底层我们需要了解到的信息是对方希望系统能帮助解决什么问题，理由是什么，和他希望最终能达成什么目的。
访谈对象：销售组长
问：关于充值卡业务，您对系统的期望是什么？(希望系统能帮助解决什么问题)
答：我希望系统能展示清楚充值卡的消耗明细，用户知道自己花了多少，剩余多少。我们内部也要知道。然后我希望能清楚地展示每位销售他售卖的充值卡金额，和他售卖的这些充值卡消耗情况。
问：我了解了。那充值卡的相关功能搭建起来后，您首先得能看到用户的消耗明细，然后和您组内销售售卖的充值卡消耗明细。还有其他的吗？(希望系统能帮助解决什么问题)
答：还有营收计算。我们现在每个部门的充值卡业绩分开来了，这个要统计清楚。
问：好的。下面我想针对这些点展开细聊。我想先请问一下，咱们知道用户充值卡消耗明细的目的是什么吗？我们负责销售的同时，还要负责后续的消耗吗？（理由是什么）
答：不负责的，一个是充值卡还有钱的用户，消费可能更大。我们想先挖掘这些用户。还有用户也会找我们对消费明细，我们也要答上来。
问：明白了。充值卡的消耗明细主要还是希望帮助您达成挖掘用户的目的对吗？对数这个工作虽然有，但应该不是主要工作内容。（达成什么目的）
答：没错的。我希望针对充值卡剩余金额，能分类展示。剩余较多且快到期的，我们可以优先挖掘。剩余较少的，可以慢点再挖掘。
问：您刚才提到需要知道销售售卖的充值卡消耗情况。咱们工作中还是得对自己售卖的充值卡是否消耗了负责对吗？（理由是什么）
答：算是。这个不影响我们的绩效也没有KPI，只是财务会催促我们。
问：那这个功能的主要目的您是希望给您一个展示，提早知道消耗情况？（达成什么目的）
答：是的。（通过这里我们可以判断，其实销售组长只是想知道消耗情况，好配合财务部门的工作，这个需求的价值是不如第一个需求的价值大的。）
…
…
（这里的访谈内容和上面的内容比较相似，限于文章篇幅略过）
…
…
问：非常感谢您今天抽出时间来参与访谈。
答：不客气的，您有问题再问我。
通过访谈，我们又能进一步整理出每一位角色对系统的需求。这些需求我们也可以通过用例图来表示：
1）用户：用户可以购买充值卡、在购买的时候可以选择充值卡付款、同时可以查看自己的消耗金额、剩余金额。（经过访谈，了解到销售不希望用户对充值卡可以退款这个事情感知太强，所以相比一开始的业务用例，我们的系统用例则删除掉了用户可以退款的用例。）
2）销售：销售可以自行生成充值卡订单，可以查看自己的售卖记录，同时可以帮助用户发起充值卡退款。
3）财务：经过访谈，了解到财务要进行退款审核、查看和导出订单、同时需要收到异常消耗的警报。
4）销售组长：经过访谈，了解到销售组长要查看用户消耗记录，充值卡销售情况和要在营销活动期间能根据本组的情况进行一定程度的充值卡套餐配置。
