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
|
1
00:00:00,250 --> 00:00:01,940
Now we are at the point in which we
2
00:00:01,940 --> 00:00:05,590
have collected and modeled our requirements. So the next thing
3
00:00:05,590 --> 00:00:08,310
that we can do is to analyze the requirements to
4
00:00:08,310 --> 00:00:11,720
identify possible problems, and specifically there are three types of
5
00:00:11,720 --> 00:00:14,646
analysis that we can perform. The first type of analysis
6
00:00:14,646 --> 00:00:16,820
is verification. So in this case we're talking about the
7
00:00:16,820 --> 00:00:19,700
requirements verification. And in verification
8
00:00:19,700 --> 00:00:21,990
developers will study the requirements
9
00:00:21,990 --> 00:00:25,270
to check whether they're correct, whether they accurately reflect the
10
00:00:25,270 --> 00:00:28,710
customer needs as perceived by the developer. Developers can
11
00:00:28,710 --> 00:00:32,170
also check the completeness of the requirements, check whether there
12
00:00:32,170 --> 00:00:34,510
are any missing pieces in the requirements as we
13
00:00:34,510 --> 00:00:37,710
discussed earlier. They can check whether the requirements are pertinent,
14
00:00:37,710 --> 00:00:41,260
or contain irrelevant information, like the one shown here.
15
00:00:41,260 --> 00:00:44,670
And they can also check whether they're consistent, unambiguous, testable
16
00:00:44,670 --> 00:00:46,920
and so on, so all those properties that should
17
00:00:46,920 --> 00:00:50,380
be satisfied for the requirements. A second type of analysis
18
00:00:50,380 --> 00:00:53,670
that is typically performed on requirements is validation. And
19
00:00:53,670 --> 00:00:56,290
the goal of validation is to assess whether the collected
20
00:00:56,290 --> 00:00:59,870
requirements define the system that the stakeholders really want.
21
00:00:59,870 --> 00:01:02,330
So the focus here is on the stakeholders. And in
22
00:01:02,330 --> 00:01:05,670
some cases, stakeholders can check the requirements directly if
23
00:01:05,670 --> 00:01:08,910
the requirements are expressed in a notation that they understand.
24
00:01:08,910 --> 00:01:11,120
Or they might check them by discussing them with the
25
00:01:11,120 --> 00:01:15,490
developers. Another possibility is that stakeholders asses the requirements by
26
00:01:15,490 --> 00:01:18,400
interacting with a prototype of the system, in case
27
00:01:18,400 --> 00:01:21,690
the requirements engineering process that is being used involves
28
00:01:21,690 --> 00:01:25,300
early prototyping. And finally surveys, testing, and other techniques
29
00:01:25,300 --> 00:01:28,400
can also be used to validate requirements. A final type
30
00:01:28,400 --> 00:01:30,780
of analysis that we can perform on requirements is
31
00:01:30,780 --> 00:01:34,430
risk analysis. And risk analysis aims to identify and
32
00:01:34,430 --> 00:01:37,680
analyze the main risks involved with the development of
33
00:01:37,680 --> 00:01:40,560
the system being considered. And if some requirements are deemed
34
00:01:40,560 --> 00:01:43,320
to be too risky, like in this case, this might result in
35
00:01:43,320 --> 00:01:47,880
changes in the requirements model to eliminate or address those risks. And note
36
00:01:47,880 --> 00:01:49,950
that all these analysis activities can
37
00:01:49,950 --> 00:01:52,390
be performed in many different ways depending
38
00:01:52,390 --> 00:01:53,990
on the modeling languages chosen to
39
00:01:53,990 --> 00:01:56,150
represent the requirements and on the context.
|
