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
把它混在一起