菜牙(1076***349) 14:32:08
现在又这么个场景， 比如：　用户查询其购买货物的历史记录统计这个用例。　比如显示　这个时间范围内总共多少钱，　每天平均多少，　每天几笔，　以及具体的明细。　现在一个问题就出来了，　如果是直接计算这些数据会比较慢。设计的时候，　会考虑性能的问题。　此时一个思路就是　比如　提前进行跑ｂａｔｃｈ或者某种方式汇总。　
菜牙(1076***349) 14:32:38
请问一下，　这个提前计算，我是把它当做一个新的用例还是，　识别为当前　查询用例的一部分。
菜牙(1076***349) 14:33:30
我现在把其识别为新的用例是否正确？
菜牙(1076***349) 14:34:40
这个计算：　在有的系统中１天算计算１次汇总，有的要５分钟一次。
潘加宇(3504847) 14:41:31
首先，这可能不是需求，涉众在意的只是查询速度要快。如何做到的，是系统的设计。如果涉众要求非得这样不可，这个是另一个用例里的步骤。可能是:时间--定时汇总，也可能是别的某个用例里面顺便做的一个步骤。
潘加宇(3504847) 14:42:05
可以先复习一下软件方法第六章
菜牙(1076***349) 14:42:56
是的。　所以，　这个有时比较纠结。　
菜牙(1076***349) 14:46:15
如果 按照潘老师的意思是， 可以在用例描述中加上一个系统行为步骤叫做 系统预处理数据？
菜牙(1076***349) 14:47:18
问题点是， 前期的需求分析时用例中是不会描述这类为了性能而加的步骤。
坐井观天(30570046) 14:48:03
我理解，这个和需求分析关系不大。
潘加宇(3504847) 14:49:31
不存在''为性能而加的步骤''
菜牙(1076***349) 14:50:20
比如： 用例的步骤： 1. 用户 查询数据
菜牙(1076***349) 14:50:22
xxx
菜牙(1076***349) 14:50:31
2. 系统查询结果显示
菜牙(1076***349) 14:52:19
那个预处理的行为如果作为 用例实现的一部分？ 就意味着这个用例的 查询者， 会发起提前处理数据。
菜牙(1076***349) 14:52:41
关键这个提前处理的发起者是 系统或者说某个定时器。
潘加宇(3504847) 14:53:32
需求如果是''3秒以内返回历史记录''，你说的这个问题就是设计。需求如果是''时间--统计历史记录''（可能性不大），性能需求就没有了。
潘加宇(3504847) 14:53:57
这个问题先回答到这里，先认真阅读第六章和之前的答疑记录需求部分再继续问