about summary refs log tree commit diff
path: root/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/32 - Requirements Engineering Process - lang_en_vs4.srt
blob: aa1ab28e2e91c5345603ff996cf34f22b998ba73 (plain) (blame)
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
1
00:00:00,180 --> 00:00:02,580
Let's now put together all that we have discussed

2
00:00:02,580 --> 00:00:06,340
and see how a requirements engineering process actually works.

3
00:00:06,340 --> 00:00:08,450
So, first of all, we saw that requirements engineering

4
00:00:08,450 --> 00:00:12,080
consists of three main steps. Elicitation of the requirements,

5
00:00:12,080 --> 00:00:15,450
in which we extract requirements from various sources. Modeling

6
00:00:15,450 --> 00:00:17,880
in which we represent the requirements using one or

7
00:00:17,880 --> 00:00:21,650
more notations or formal reasons and analysis, in which

8
00:00:21,650 --> 00:00:25,230
we identify possible issues with our requirements and there is

9
00:00:25,230 --> 00:00:27,870
actually a 4th step that we kind of mention

10
00:00:27,870 --> 00:00:30,670
but not explicitly. And this is the negotiation that can

11
00:00:30,670 --> 00:00:34,320
happen between the stakeholders and the developers, during which

12
00:00:34,320 --> 00:00:38,400
requirements are discussed and modified until an agreement is reached.

13
00:00:38,400 --> 00:00:40,000
So if you want to think of this as a

14
00:00:40,000 --> 00:00:43,030
process, so as a sequence of steps, we can see

15
00:00:43,030 --> 00:00:46,000
that we start from elicitation. So we start by eliciting

16
00:00:46,000 --> 00:00:50,450
an initial setup requirements. We negotiate and refine this set,

17
00:00:50,450 --> 00:00:53,820
then we model the resulting requirements. And finally, we

18
00:00:53,820 --> 00:00:58,190
analyze such requirements. However, the process doesn't really stop here.

19
00:00:58,190 --> 00:01:00,620
Why? Well, because as a result of the analysis,

20
00:01:00,620 --> 00:01:03,230
we might have to perform further elicitation. And so this

21
00:01:03,230 --> 00:01:05,850
process is not really a sequential one, but rather

22
00:01:05,850 --> 00:01:09,340
an iterative process. So, in practice, we continue to iterate

23
00:01:09,340 --> 00:01:12,700
over these four steps gathering a better and better understanding

24
00:01:12,700 --> 00:01:15,560
of the requirements at every iteration until we are happy

25
00:01:15,560 --> 00:01:18,080
with the settle requirement that we gather and stop the process.