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
|
1
00:00:00,130 --> 00:00:02,540
But how can we do that? How can we identify the purpose
2
00:00:02,540 --> 00:00:06,080
of the system and collect good requirements? To answer that question, let me
3
00:00:06,080 --> 00:00:07,800
give you another definition of requirements
4
00:00:07,800 --> 00:00:09,590
engineering. And this one is a classical
5
00:00:09,590 --> 00:00:13,010
one, one that summarizes what we discussed so far, and then we can
6
00:00:13,010 --> 00:00:16,180
use as some sort of reference. And it is a little long.
7
00:00:16,180 --> 00:00:18,710
Definitely longer than the one that we saw at the beginning. But it's
8
00:00:18,710 --> 00:00:21,840
an important one and it contains a lot of very relevant points. So,
9
00:00:21,840 --> 00:00:25,210
we're going to go through it and highlight these points. So the definition says,
10
00:00:25,210 --> 00:00:28,970
that the requirements engineering is a set of activities concerned
11
00:00:28,970 --> 00:00:32,990
with identifying and communicating the purpose of a software intensive
12
00:00:32,990 --> 00:00:35,770
system and the context in which it will be used.
13
00:00:35,770 --> 00:00:38,570
And this is exactly what we said at the beginning. But
14
00:00:38,570 --> 00:00:40,940
something we can highlight in here, is the fact that
15
00:00:40,940 --> 00:00:44,210
we're talking about a set of activities. So, what that means
16
00:00:44,210 --> 00:00:46,800
is that requirements engineering is not just a phase or
17
00:00:46,800 --> 00:00:51,050
a stage. It also says that it's about identifying and communicating.
18
00:00:51,050 --> 00:00:53,720
And what that is telling us is that communication is
19
00:00:53,720 --> 00:00:56,670
as important as the analysis. So, it's important to be
20
00:00:56,670 --> 00:00:59,990
able to communicate these requirements not only to collect them.
21
00:00:59,990 --> 00:01:02,018
And we will discuss many reasons why that is the
22
00:01:02,018 --> 00:01:05,880
case. It explicitly talks about purpose. So that allows me
23
00:01:05,880 --> 00:01:10,310
to stress, once more, that quality means fitness-for-purpose. We cannot
24
00:01:10,310 --> 00:01:14,410
say anything about quality unless we understand the purpose. And
25
00:01:14,410 --> 00:01:16,210
the last thing I want to point out in this first
26
00:01:16,210 --> 00:01:18,420
part of the definition is the use of the term
27
00:01:18,420 --> 00:01:21,060
context. This is also something else that we mentioned at
28
00:01:21,060 --> 00:01:24,890
the beginning, that designers, analysts, need to know how and
29
00:01:24,890 --> 00:01:28,015
where the system will be used. Without this information, you
30
00:01:28,015 --> 00:01:30,455
cannot really understand what the system should do and you
31
00:01:30,455 --> 00:01:33,280
cannot really build the system. So now, let's continue and
32
00:01:33,280 --> 00:01:35,755
read the second part of the definition that says, hence.
33
00:01:35,755 --> 00:01:41,550
Requirements engineering acts as the bridge between the real-world needs of
34
00:01:41,550 --> 00:01:45,315
users, customers, and other constituencies affected by a
35
00:01:45,315 --> 00:01:49,440
software system and the capabilities and opportunities afforded
36
00:01:49,440 --> 00:01:52,870
by software-intensive technologies. This is a long sentence,
37
00:01:52,870 --> 00:01:55,030
but also here, we can point out a
38
00:01:55,030 --> 00:01:57,670
few interesting and relevant points. Let me start
39
00:01:57,670 --> 00:02:00,612
by highlighting two parts. Real-world needs, and the
40
00:02:00,612 --> 00:02:04,150
capabilities, and opportunities. So, what are these two
41
00:02:04,150 --> 00:02:07,000
parts telling us? They are telling us that requirements
42
00:02:07,000 --> 00:02:09,949
are partly about what is needed, the real-world needs
43
00:02:09,949 --> 00:02:13,520
of all these stakeholders. But they're also partly about what
44
00:02:13,520 --> 00:02:16,100
is possible, what we can actually build. We need
45
00:02:16,100 --> 00:02:19,260
to compromise between these two things. And, finally, I would
46
00:02:19,260 --> 00:02:23,000
like to point out this term constituencies, which indicates
47
00:02:23,000 --> 00:02:26,220
that we need to identify all of the stakeholders, not
48
00:02:26,220 --> 00:02:29,130
just the customer and the users, so anybody who is
49
00:02:29,130 --> 00:02:32,040
affected by a software system. It is very important to
50
00:02:32,040 --> 00:02:35,130
consider all of these actors. Otherwise, again,
51
00:02:35,130 --> 00:02:37,530
we'll be missing requirements, we'll be missing
52
00:02:37,530 --> 00:02:41,120
part of the purpose of the system and we will build a suboptimal system.
|
