[图解]用例规约之业务规则不是算法

1
00:00:01,530 --> 00:00:03,090
像这种某某算法之类的

2
00:00:03,100 --> 00:00:04,130
它往往是什么

3
00:00:05,590 --> 00:00:07,440
某种实现的一个选择

4
00:00:08,140 --> 00:00:09,550
它很可能不是需求

5
00:00:10,620 --> 00:00:13,240
你要问他，为什么要用这种算法

6
00:00:14,360 --> 00:00:15,160
不用就会怎么样

7
00:00:15,170 --> 00:00:19,080
很可能背后才是真正的需求

8
00:00:19,350 --> 00:00:23,080
涉众根本不知道你用了什么算法

9
00:00:23,360 --> 00:00:25,230
他也不在意的，比如说，你做一个

10
00:00:25,830 --> 00:00:29,060
让盲人用的一个语音识别的系统

11
00:00:31,140 --> 00:00:32,850
盲人根本不在意你用什么算法

12
00:00:32,860 --> 00:00:37,500
他在意什么，识别率是怎么样的

13
00:00:38,300 --> 00:00:38,660

14
00:00:39,400 --> 00:00:41,010
你用什么算法无所谓的

15
00:00:42,040 --> 00:00:44,570
但是我们从实现者的角度写

16
00:00:45,840 --> 00:00:47,390
使用某某什么算法

17
00:00:47,910 --> 00:00:49,530
以为这个是需求，不是的

18
00:00:50,010 --> 00:00:55,520
涉众根本不在意这个，业务规则

19
00:00:57,610 --> 00:00:59,440
下一个就是质量需求了

20
00:01:00,310 --> 00:01:02,470
包括我们的可用性、可靠性

21
00:01:02,750 --> 00:01:04,530
性能、可支持性

22
00:01:07,090 --> 00:01:08,590
那么，质量需求以前

23
00:01:09,480 --> 00:01:10,910
叫非功能需求

24
00:01:11,740 --> 00:01:15,040
但是非功能需求这个词，就不是那么严谨

25
00:01:15,760 --> 00:01:17,820
所以我就改叫质量需求

26
00:01:20,320 --> 00:01:21,920
那么可用性、可靠性

27
00:01:22,730 --> 00:01:24,510
性能、可支持性这几个里面

28
00:01:24,880 --> 00:01:26,720
像可靠性

29
00:01:27,590 --> 00:01:29,330
可支持性这些的话

30
00:01:29,900 --> 00:01:32,510
往往是跟整个系统相关的

31
00:01:34,560 --> 00:01:36,710
所以不用单独写在某个用例里面

32
00:01:39,180 --> 00:01:41,490
而可用性、性能这些

33
00:01:41,910 --> 00:01:45,000
有一部分确实是跟某个用例相关的

34
00:01:45,010 --> 00:01:51,370
比如说，某一次下单的过程中

35
00:01:54,420 --> 00:01:55,890
身体的移动距离

36
00:01:56,630 --> 00:01:58,760
或手指移动距离不得超过多少

37
00:01:59,170 --> 00:02:03,270
或者说，手指的点击的次数不能超过多少

38
00:02:04,020 --> 00:02:07,310
类似这样，这是可用性的一个需求

39
00:02:08,570 --> 00:02:09,990
还有性能，包括速度

40
00:02:10,510 --> 00:02:12,470
包括容量，刚才我们举例了

41
00:02:12,600 --> 00:02:15,770
从提交到反馈等多久

42
00:02:16,060 --> 00:02:18,630
引起多少人并发，性能

43
00:02:18,640 --> 00:02:28,100
那么写质量需求最关键的点是要能够度量

44
00:02:29,640 --> 00:02:32,430
要以一种能度量的方式把它表达出来

45
00:02:35,060 --> 00:02:36,500
不能光写形容词

46
00:02:36,670 --> 00:02:41,870
比如说，可用性，你说操作要方便

47
00:02:42,840 --> 00:02:44,120
那是废话了

48
00:02:44,960 --> 00:02:46,850
你必须要度量这个方便

49
00:02:47,240 --> 00:02:49,400
你什么叫方便

50
00:02:49,410 --> 00:02:51,900
你给个指标才行

51
00:02:53,080 --> 00:02:57,110
你可能要写，整个下单期间

52
00:02:58,910 --> 00:03:02,890
会员

53
00:03:03,170 --> 00:03:05,330
需要主动的操作

54
00:03:05,500 --> 00:03:06,890
不得超过多少次

55
00:03:07,260 --> 00:03:10,080
类似这样的，或手指移动的距离

56
00:03:10,720 --> 00:03:13,180
或者手腕移动距离不能超过多少

57
00:03:14,690 --> 00:03:16,830
类似这样，度量

58
00:03:19,490 --> 00:03:22,040
不能说我界面要漂亮，那也不行

59
00:03:22,330 --> 00:03:23,240
什么叫漂亮

60
00:03:23,820 --> 00:03:25,210
你得有个度量

61
00:03:29,880 --> 00:03:31,720
包括性能，你更要度量

62
00:03:32,130 --> 00:03:34,090
你说要快，那什么叫快

63
00:03:34,730 --> 00:03:36,610
1秒，5秒，10秒？

64
00:03:37,770 --> 00:03:40,360
要度量，质量需求

65
00:03:48,600 --> 00:03:50,670
最后一个是设计约束

66
00:03:51,600 --> 00:03:53,020
实现这个系统的时候

67
00:03:53,620 --> 00:03:55,660
必须要遵守的一些约束

68
00:03:56,560 --> 00:03:59,300
包括界面的样式

69
00:04:00,090 --> 00:04:03,530
我们前面讲到路径步骤的时候

70
00:04:03,540 --> 00:04:05,770
我们说界面也可以成为需求

71
00:04:05,780 --> 00:04:09,770
为什么，当涉众说不这样不行的时候

72
00:04:11,310 --> 00:04:12,310
来自涉众的

73
00:04:12,770 --> 00:04:13,940
涉众说不这样不行

74
00:04:14,610 --> 00:04:15,400
这个就是需求

75
00:04:19,120 --> 00:04:20,480
包括报表样式

76
00:04:21,260 --> 00:04:22,520
包括平台等等

77
00:04:24,390 --> 00:04:25,690
注意必须来自涉众

78
00:04:26,680 --> 00:04:28,940
不是来自开发团队的选择

79
00:04:30,240 --> 00:04:31,250
是涉众的需要

80
00:04:31,740 --> 00:04:35,870
他们公司目前用了oracle了

81
00:04:36,330 --> 00:04:38,640
所以我们新系统也要用oracle

82
00:04:39,080 --> 00:04:40,870
这样可以减少成本

83
00:04:42,570 --> 00:04:46,150
来自涉众，不是来自我们开发团队的

84
00:04:52,120 --> 00:04:53,510
如果来自开发团队的

85
00:04:54,110 --> 00:04:56,150
那就不叫设计约束了

86
00:04:56,160 --> 00:04:57,190
那就叫设计了

87
00:04:57,200 --> 00:04:58,790
比如说，经常有人写

88
00:04:59,330 --> 00:05:02,360
系统应采用什么什么架构搭建

89
00:05:03,270 --> 00:05:05,770
涉众根本不知道有什么架构什么架构

90
00:05:05,780 --> 00:05:06,250

91
00:05:06,710 --> 00:05:08,630
那是我们开发人员自己知道的

92
00:05:08,640 --> 00:05:12,290
那就把它删掉

93
00:05:12,800 --> 00:05:14,000
然后可以问为什么

94
00:05:15,010 --> 00:05:16,390
如果不用这个架构

95
00:05:16,400 --> 00:05:17,810
可能会有什么后果

96
00:05:19,980 --> 00:05:23,760
不用这个可能使得

97
00:05:23,770 --> 00:05:25,600
我们分布在

98
00:05:25,870 --> 00:05:29,940
全国各地的不同的子公司

99
00:05:30,900 --> 00:05:33,390
不同的下属单位都要用的

100
00:05:34,570 --> 00:05:35,490
不用这个架构

101
00:05:35,660 --> 00:05:39,700
做不到分布式的使用，这个才是需求

102
00:05:41,330 --> 00:05:42,250
只要你能够实现

103
00:05:43,550 --> 00:05:45,090
你用什么架构无所谓

104
00:05:45,100 --> 00:05:46,540
涉众也不在意

105
00:05:48,760 --> 00:05:49,200
删掉

106
00:05:49,210 --> 00:05:56,610
然后问为什么，比如说，录单界面应该分三个页面

107
00:05:56,980 --> 00:05:57,490
为什么

108
00:05:58,420 --> 00:05:59,500
为什么这样设计

109
00:06:01,300 --> 00:06:02,110
不这样会怎么样

110
00:06:03,240 --> 00:06:04,050
不这样的话

111
00:06:04,060 --> 00:06:07,330
可能反馈录单页面的时候就慢

112
00:06:07,340 --> 00:06:08,930
因为加载数据比较多

113
00:06:10,260 --> 00:06:11,520
这个才是问题

114
00:06:13,510 --> 00:06:17,380
系统要在几秒内显示这个录单的界面

115
00:06:19,050 --> 00:06:20,730
至于你怎么做到无所谓的

116
00:06:20,740 --> 00:06:23,800
你是分三页还是一页、两页无所谓的

117
00:06:25,290 --> 00:06:27,440
涉众不在意想，实际上，涉众巴不得怎么样

118
00:06:28,970 --> 00:06:30,490
你一页就出来

119
00:06:31,270 --> 00:06:32,980
之前之所以分三页是因为什么

120
00:06:32,990 --> 00:06:36,130
你资源不足

121
00:06:37,410 --> 00:06:38,400
没办法

122
00:06:38,410 --> 00:06:39,760
一下子加载这么大

123
00:06:40,290 --> 00:06:41,540
假设你资源够了

124
00:06:41,950 --> 00:06:45,570
啪，一下出来，有什么不可以的

125
00:06:45,580 --> 00:06:47,140
涉众更高兴

126
00:06:48,420 --> 00:06:50,970
不要把你自己实现的选择

127
00:06:50,980 --> 00:06:53,840
和涉众真正在意的

128
00:06:53,850 --> 00:06:55,110
把它混在一起