1、多考虑一下“哪些参数该取配置值”
一个很久没联系过我的合作伙伴在QQ上紧急找我，因为我们很多年前开发的一套仓库系统被他找到了新买家，但有个“小”问题需求我帮忙解决。原来系统装好后，各项参数都按新公司配置好了，但打印出来的仓单页眉显示的是其它公司的名称。
好吧，我承认当年做报表时为了快速交货，就将公司名直接写死。原本这个值可以读系统配置参数的。
2、再考虑是否存在“没有票也可以上车”，“超过1.5M的小孩也不需要买全票”的场景？
在需求调研中，我们肯定可以获取到业务的正常流程和规则是怎么样的，并记录在需求分析文档里。但实际业务中往往会出现很多特例，它们不符合业务规则但还得让流程正常走下去。比如上车前要买票，但因为乘客特殊原因没票也可以让他先上车再补票。
又比如公司规定超过X吨的车不允许进闸。但如果系统这样写死，一些有特殊关系的车辆虽然超重但上级要求放它进闸时系统就解决不了了。到时IT人员就要背锅了。
以上都不是重点，重点是“需求调研时，除了要了解正常流程，一些潜规则也得打听到并记录下来。”
3、是否有“必须早到的人突然迟到了，或者经常晚到的突然早到了。”的情况。
虚拟一个正常的业务场景：公司要求A员工拿钥匙，每天先到公司开门。B员工每天在开门后把报纸放在C领导桌上。
如果程序设计时按顺序写死 ：A->B两个人的业务流程，并且强制校验它们的前后关系。那么在 A比 B晚到的情况就执行不了，虽然发生的概率非常小，一旦发生了就会造成系统停滞。
在业务分析中，要思考一下是否会出现顺序颠倒的场景产生，并和业务人员确认业务顺序【万一】颠倒时系统该怎么处理？
案例：
原方案：收到海关放行报文时，系统按照报文内的集装箱号给在堆场的集装箱解海关布控锁。
实际业务中99.99%的箱子可以按上方案实现，但还是有0.01%箱子在收到海关放行报文后才进场。按以上方案无法解布控锁，所以又重新修改方案和代码：
新方案：1、收到海关放行报文时，按照报文内的箱号给在堆场的集装箱解海关布控锁。如果箱不在场时，先将报文写入数据库；
2、集装箱进场时判断数据库中是否存有海关放行报文数据，如果有则箱落场后自动解除海关布控锁，并将该箱的报文数据在数据库中归历史。
3、报文写入数据库X天后，如果还未被使用，则自动归历史。