02 · 需求分析 · 规则表
「看情况加签」写不成需求
需求分析师把已入选一期的规则写成如果、那么、不允许。他不决定商业优先级，两万元门槛不是他定的。
| 如果 | 那么 | 不允许 |
|---|---|---|
| 两万元以下，且在预算内 | 部门经理通过即结束 | 发起人自己把财务总监加进来 |
| 两万元及以上，或超预算 | 部门经理之后必须到财务 | 跳过财务直接结束 |
| 已付款才发现附件错 | 作废并红冲，另起一单 | 直接改已付款单据的金额 |
| 声称紧急、附件后补 | 先占预算，三个工作日内补上，否则冻结该人新单 | 没有到期日的「后补」 |
需求分析师把事实收成只能有一种读法的句子
业务分析师带回矛盾，产品经理决定哪些矛盾进一期。需求分析师只处理已经入选的部分，把它们写成开发能实现、测试能判定、业务能复核的句子。岗位特点是对模糊词过敏。灵活、智能、尽量、看情况、适当、相关人员，都会被退回。这些词在会上能让所有人点头，在系统里没有对应的判断。谁有权在运行时解释「看情况」，谁就成为系统外的审批人，单据就会回到微信。
他不决定商业优先级。两万元这个门槛是财务和产品一起定的，不是分析师觉得合理。他要保证门槛一旦写上，就没有第二条口头门槛。他也不是原型设计师。句子没写完时，他不会让原型先把按钮摆上去。按钮会让客户以为规则已经存在。
一条规则要能被打成失败用例
达希的需求条目固定成三列：如果、那么、不允许。如果写触发条件，含金额、状态、时间和角色。那么写系统必须留下的结果，含状态迁到哪里、谁的待办出现、哪本账变动。不允许写最容易被做成「方便」的捷径。三列缺一列，测试只能说看起来正常。例如「大额要加签」缺了金额和角色，开发会做成一个可选的抄送人，业务会认为那就是加签，验收时两边都觉得对方没理解。
例外必须写到期。紧急后补如果没有三个工作日和冻结，后补就变成永久。已付款的单据如果允许改金额，会计轨迹就断了。这些不允许不是分析师在为难客户，是他从过去单据里看见过的真实改法。没有历史单据的规则，他会标明「尚未用旧单验证」，不把猜测写成验收标准。
四十张报销单怎样收成上面那张表
一家贸易公司说审批比较灵活。业务分析师拿回四十张已结束的报销。需求分析师按金额和路径分类，而不是按讲述分类。两万元以下的单，绝大多数在部门经理处结束，财务只在超预算时出现。两万元以上的单，有三张被发起人临时把财务总监拉进群，其中一张最后没有财务意见也付款了。已付款后改金额的有两张，财务后来用红字另做了一笔，但原单金额还是错的。后补附件的单有六张，两张到月结还没补。
表因此写成四行，而不是「按公司制度灵活加签」。上线后没有人再在群里问这笔该不该加签：金额和预算能算出来，路径只有一条。发起人仍可以备注「请总监看看」，但备注不会改变流程，也不会让单据在总监未处理时结束。测试用四行各做一条通过和一条不允许。不允许那条失败，就不放行。
句子清楚之后才交给原型设计师。如果原型评审时业务说「有时还是要加签」，分析师把「有时」退回产品和财务，不在原型上加一个自由选人的控件来代表尚未决定的规则。