在需求分析中就可以避免的那些错误4

这篇可能偏向设计问题，但有些项目文档需求和设计是揉合在一起的。

 

1、调研业务最高的并发量

    现在有很多应用处理小规模数据非常正常，但处理大数据就出错，或者处理非常缓慢看起来象死机了。

    原因都是因为设计开发和测试时都没有考虑到最大业务量。所以在需求文档中必须写明某项业务的最大量是多少，便于优化设计方案。

    举几个例子：

   1）、船公司和码头交互装卸的集装箱都是通过文本格式的电子报文来进行的，比如舱单报文。十几年前的造船技术和现在相差很大。现在船的运载量大了，能装上万个集装箱子的船出现了，电子报文的行数也增加了。原来一个舱单报文可能只有几百行上千行，但现在可能会有上万行。原来程序可能只要几秒钟就能解析和导入一个报文，但现在上万行的报文要几十分钟，用户无法接受如此慢的速度。

           所以做行业软件需求分析，尽量考虑到行业的未来五年或十年发展潜力，尽量避免很多功能因为数据量增加了而无法正常工作。

 

   2）经过测试我们发现有个接口只能接收300个以下的集装箱信息，超过300个箱就会报ORACLE数据库错误。最后才发现是因为SQL语句过长的原因。程序员在设计时将写入300条箱信息的任务写了一个SQL拼接语句，而当这个SQL语句长度超过4000个字符时就无法执行，因为数据库限制。（优化方案：分批写入）

      所以在需求和测试用例编写时一定要考虑到最大的可能数据量。

 

2、需要判断是否一个任务被重复执行

     举个例子：有个定时发送数据的计划任务，使用了几年后经常出现同样的数据发送多次的问题。

    最后找到的问题原因是：该任务每3分钟执行一次，但有时数据量大，3分钟内无法完成，在下一个时间片执行时又重新将还在发送的数据重新发送了一遍。

    这个例子也是因为没考虑到数据量和执行时间问题，小数据系统正常，但量一大就出错了。

    优化方案：增加判断某个时间片的数据是否在处理中？如果正在处理就对下一个发送任务进行延时处理。

 

3、避免取数时产生恶性循环

     这个问题也是因为性能或异常引起的。

      举个同样的例子：有个定时发送数据的计划任务，用着用着就无法工作了。

     最后找到的问题原因是：该任务有一次因为系统资源不足没有正常执行，下一次发送时需要一起发送这2个时间片内产生的数据，需要的系统资源更大还是执行失败，第三个发送点需要发送三个时间片的数据……。这个就恶性循环了，对系统的资源要求越来越多，更加无法实现。

    这其实是一个设计BUG。测试用例中也没有这个场景。本质上还是需求分析没考虑到这种异常场景。

    优化方案：取数据时设计最大步长，比如最大跨度5分钟，上次执行完成时间和当前时间超过5分钟，那么取数据步长只用（上次执行完成时间  -------上次执行完成时间+5分钟）避免因一次失败导致取时间跨度越来越大。