176 lines
4.2 KiB
Plaintext
176 lines
4.2 KiB
Plaintext
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.
|