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
|
1
00:00:00,230 --> 00:00:03,200
So, let's start with requirements engineering, which is the
2
00:00:03,200 --> 00:00:06,560
field within software engineering that deals with establishing the
3
00:00:06,560 --> 00:00:09,400
needs of stakeholders that are to be solved by
4
00:00:09,400 --> 00:00:13,480
the software. So why is this phase so important?
5
00:00:13,480 --> 00:00:16,350
In general, the cost of correcting an error depends
6
00:00:16,350 --> 00:00:19,060
on the number of subsequent decisions that are based
7
00:00:19,060 --> 00:00:22,160
on it. Therefore, errors made in understanding requirements have
8
00:00:22,160 --> 00:00:25,670
the potential for greatest cost because many other design decisions
9
00:00:25,670 --> 00:00:29,020
depend on them and many other follow up decisions depend on them.
10
00:00:29,020 --> 00:00:31,510
In fact, if we look at this diagram, which is again a
11
00:00:31,510 --> 00:00:35,210
qualitative diagram, where we have the cost of error correction over the
12
00:00:35,210 --> 00:00:38,780
phase in which the error is discovered. We can see that if we
13
00:00:38,780 --> 00:00:42,420
discover an error in requirements it's going to cost us one. If
14
00:00:42,420 --> 00:00:45,020
we find it in in design it's going to cost us five and
15
00:00:45,020 --> 00:00:47,410
so on and so forth. And the cost grows dramatically as we
16
00:00:47,410 --> 00:00:50,960
go from the requirements phase to the maintenance phase. Why? Because of course
17
00:00:50,960 --> 00:00:53,092
if we discover a problem here we're left to undo a
18
00:00:53,092 --> 00:00:55,536
lot of the decision that we had made before to correct the
19
00:00:55,536 --> 00:00:58,019
error. Whereas if we find an error here we can correct it
20
00:00:58,019 --> 00:01:01,380
right away and we don't affect the subsequent phases. So how can
21
00:01:01,380 --> 00:01:03,540
we collect the right requirements. Traditional
22
00:01:03,540 --> 00:01:05,310
requirements in engineering does so through
23
00:01:05,310 --> 00:01:08,930
a set of steps. The first step is elicitation which is the
24
00:01:08,930 --> 00:01:12,840
collection of requirements from stake holders and other sources and can be
25
00:01:12,840 --> 00:01:15,890
done in a variety of ways, we will discuss some of them.
26
00:01:15,890 --> 00:01:19,280
The second is requirement analysis which involved the study and
27
00:01:19,280 --> 00:01:23,200
deeper understanding of the collective requirements. The third step is this
28
00:01:23,200 --> 00:01:26,760
specification of requirements, in which the collective requirements are suitably
29
00:01:26,760 --> 00:01:30,730
represented, organized and save so that they can be shared. Also
30
00:01:30,730 --> 00:01:32,530
in his case, there are many ways to do this,
31
00:01:32,530 --> 00:01:34,350
and we will see some of this ways when we talk
32
00:01:34,350 --> 00:01:37,550
about the requirements engineering in the dedicated lesson. Once the
33
00:01:37,550 --> 00:01:40,970
requirements have been specified, they can be validated to make sure
34
00:01:40,970 --> 00:01:44,420
that they're complete, consistent, no redundant and so on. So
35
00:01:44,420 --> 00:01:48,460
that they've satisfied a set of importance properties, for requirements.
36
00:01:48,460 --> 00:01:52,410
Finally, the fifth step is requirements management which accounts for
37
00:01:52,410 --> 00:01:56,100
changes to requirements during the lifetime of the project. And here
38
00:01:56,100 --> 00:01:58,330
I talked about steps, kind of giving the impression that
39
00:01:58,330 --> 00:02:01,310
we're just going from the first step to the fifth one
40
00:02:01,310 --> 00:02:03,300
and that this is sort of a linear process. In
41
00:02:03,300 --> 00:02:05,990
reality, as we will see, this is more of an iterative
42
00:02:05,990 --> 00:02:09,690
process in which will go and cover the different phases in an
43
00:02:09,690 --> 00:02:12,560
iterative fashion. We will discuss extensively
44
00:02:12,560 --> 00:02:15,453
requirements engineering in our second mini-course.
|
