1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
|
1
00:00:00,220 --> 00:00:02,120
So at this point, we have talked quite a bit about
2
00:00:02,120 --> 00:00:03,800
requirements engineering, but we haven't
3
00:00:03,800 --> 00:00:06,450
really discussed what are requirements exactly.
4
00:00:06,450 --> 00:00:08,880
So what is a requirement? To define that I am going
5
00:00:08,880 --> 00:00:11,860
to use this diagram which is a classical one. So you might
6
00:00:11,860 --> 00:00:14,980
have seen it before. So, discussing this diagram allows me to
7
00:00:14,980 --> 00:00:18,720
point out a few interesting things about requirements and define them
8
00:00:18,720 --> 00:00:21,660
in a better way. At a high level this diagram contains
9
00:00:21,660 --> 00:00:24,780
two main parts, the domain of the machine, which is the hardware,
10
00:00:24,780 --> 00:00:27,670
operating system, libraries and so on, on which the
11
00:00:27,670 --> 00:00:30,860
software will run. And the domain of the application, which
12
00:00:30,860 --> 00:00:33,510
is a world in which the software will operate.
13
00:00:33,510 --> 00:00:36,690
And the machine domain is characterized by computers, which are
14
00:00:36,690 --> 00:00:39,980
the hardware devices, and programs, which is the software
15
00:00:39,980 --> 00:00:43,430
that runs on these devices. The application domain, conversely, is
16
00:00:43,430 --> 00:00:47,370
characterized by domain properties, which are things that are true
17
00:00:47,370 --> 00:00:50,330
of the world anyways, whether I'm building my system or
18
00:00:50,330 --> 00:00:53,510
not, and requirements, which are things in the world we
19
00:00:53,510 --> 00:00:56,220
would like to achieve by delivering the system that we are
20
00:00:56,220 --> 00:00:59,400
building. Basically, to put it in a different way, the former,
21
00:00:59,400 --> 00:01:02,950
the domain properties, represents the assumptions that we make on the
22
00:01:02,950 --> 00:01:06,740
domain. And the latter, the requirements, are the actual requirements
23
00:01:06,740 --> 00:01:09,660
that we aim to collect. So we have something here, right,
24
00:01:09,660 --> 00:01:13,380
at the intersection of this application domain and this machine domain.
25
00:01:13,380 --> 00:01:15,570
And what is that? And this is what we normally call
26
00:01:15,570 --> 00:01:19,225
the specification, which is a description, often a formal description,
27
00:01:19,225 --> 00:01:22,120
of what the system that we are building should do to
28
00:01:22,120 --> 00:01:25,520
meet the requirements. So this is a bridge between these two
29
00:01:25,520 --> 00:01:29,380
domains. And as the graphical depiction shows, the specification is written
30
00:01:29,380 --> 00:01:33,220
in terms of shared phenomena. Things that are observable in both
31
00:01:33,220 --> 00:01:35,980
the machine domain and the application domain. And just to make
32
00:01:35,980 --> 00:01:37,540
things a little more concrete, I want to give you a
33
00:01:37,540 --> 00:01:41,180
couple of examples of what these phenomena, these shared phenomena, are.
34
00:01:41,180 --> 00:01:43,350
And we can think about two main kinds of phenomena.
35
00:01:43,350 --> 00:01:46,080
The first one are events in the real world that the
36
00:01:46,080 --> 00:01:50,140
machine can directly sense. For example, a button being pushed or
37
00:01:50,140 --> 00:01:53,910
a sensor being activated. These are events that happen here, but
38
00:01:53,910 --> 00:01:56,500
that the machine can detect. So they're events that can
39
00:01:56,500 --> 00:01:59,650
be used to define the specification. And the second type of
40
00:01:59,650 --> 00:02:02,890
phenomena are actions in the real world that the machine can
41
00:02:02,890 --> 00:02:06,380
directly cause. For example, an image appearing on a screen or
42
00:02:06,380 --> 00:02:09,300
a device being turned on and off. Again, this is something
43
00:02:09,300 --> 00:02:12,460
that the machine can make happen and then can have manifestation in
44
00:02:12,460 --> 00:02:15,520
the real world. And again this is therefore something on which
45
00:02:15,520 --> 00:02:17,720
the specification can predicate, something that
46
00:02:17,720 --> 00:02:19,750
we can describe in our specification.
47
00:02:19,750 --> 00:02:22,860
And this is sort of a philosophical discussion, but even if
48
00:02:22,860 --> 00:02:26,210
you don't care about the philosophical discussion, the one take away point
49
00:02:26,210 --> 00:02:28,800
that I would like for you to get from this discussion is
50
00:02:28,800 --> 00:02:31,392
the fact that when writing a specification you have to be aware
51
00:02:31,392 --> 00:02:34,860
of the fact that you're talking about shared phenomena. Events in the real
52
00:02:34,860 --> 00:02:39,100
world that the machine can sense and actions in the real world that the
53
00:02:39,100 --> 00:02:43,048
machine can cause. So this is what the specification is about, a bridge between
54
00:02:43,048 --> 00:02:44,760
these two worlds that define what the
55
00:02:44,760 --> 00:02:47,170
system should do to satisfy the requirements.
|
