[BA][案例分享][教培行业]如何用IT的语言解释业务需求-系统判断新生/新客户

本文链接：https://blog.csdn.net/happyegg/article/details/107377515

1. 前言

需求分析师（或）产品经理，作为业务与技术的桥梁，需要和所有的项目/产品干系人沟通，确保大家对功能的认知在同一个维度上。之前处理比较多的是如何用业务的语言向客户解释系统的逻辑，但这个例子却是相反，是用IT的语言解释业务需求的合理性，好了，下面案例分析开始：

2. 需求模型背景

整个需求其实非常大，这里简化一下需求模型：

系统业务背景：校外教育培训机构的教务管理软件
功能点：判断一个学生是否是一个新生

2.1 需求模型

判断条件1：这个学生首次来机构报名上课，计算为新生
判断条件2：这个学生在机构上过课，但是半年前已经结课（结课条件：课程已经上完，该生在课程的钱也用完）
不是新生的，都是老生

2.2 IT设计模型

根据需求模型，IT设计的判断条件如下：

这个学生在系统里从来没有过完款合同
这个学生在系统里有完款的合同，但是最近半年内没有上课记录，并且该完款合同资金已用完
满足条件1或2，这个学生都算新生，不满足这两个条件的，都算老生

3 实际情况中发现的问题

根据IT设计模型中，正常的学生报名，判断新生老生，正常的案例都已经验证过没有问题。

但客户反馈了几个案例，说是这几个学生换班转课之后，又被系统判定为新生，这是怎么一回事呢？

经测试查证，发现这几个学生，在报读了A课程之后，没有上过任何课，就在系统上把A课程给退了，然后报了B课程。系统根据逻辑，180天内无课消，历史合同资金为0，就把这个学生判断为新生了。

4 测试对需求的理解

测试小妹妹在嘟囔了：“需求文档上不是定了180天内无课消，历史合同资金用完，再报读就算新生嘛，这几个案例完全满足啊”

5 解释原因背景

我对测试小妹妹说：“如果我们作为IT的人，把一个需求，看成一个冷冰冰的逻辑关系，而不去了解事情背后的原因，那我们是无法成长的。”（【画外音】为什么很多人说IT男/IT女很难沟通呢，我估计就是常年仅关心需求逻辑，而不去关心需求背后的含义）

见测试小妹妹不是很明白，我用现实中的真实案例来做解说：

无人车的案例：
我记得特斯拉的无人车之前在美国发生过一个案例，就是一两私家车，无法在天气晴朗的情况下中辨认白色货车，全速撞上货车。
相关报道：特斯拉无人车酿死亡车祸
我这里大胆猜测一下，假设需求是需要辨认周围的物体，如果是物体则不能装上去。那换成技术设计是什么呢？技术不可能简单的写：

If (前面物体 == true) then {
   停车
}

因为摄像头捕捉到的都是图片，要从图片中分辨车，马路，路边的草，斑马线，下水道盖子，就需要用到图片分析，那图片分析会不会根据色差来划分物体？比如色差大过多少，算一个物体（臆想的，如果实际技术不是这样判断，请告知详细）。用这个案例来说，可能技术的列举是辨认黑色，蓝色，绿色等有颜色的物体，但唯独和晴朗天气或周围物体颜色很接近的白色车便辨认为非物体（比如地上的指示白线？），然后开发，测试也按照技术需求的颜色都过了一遍，测试案例通过，皆大欢喜。但这不能代表实际需求就是这样，结果导致了悲剧发生。

另一个例子是前段时间发生的波音737MAX8的坠毁事件，网络文章很多，自行百度即可。事后的分析中，说到了波音给飞机加上了一个仰角控制系统，使飞机机头自动下坠的夺命系统MACS。如果这个系统出现故障，电脑会认为飞机失速，于是激活MCAS，强行将机头下压。这个可能确实是需求这么写的，但需求设计也有可能是错的，结果导致了飞机的坠毁。

举例了上述两个例子，我跟测试小妹妹说，为什么说一个开发团队，不是说一个厉害的项目经理，一个厉害的需求分析师，厉害的架构师和程序员，就一定能开发出完美的应用的。我们要充分理解：