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
|
1
00:00:00,150 --> 00:00:02,290
But we collect requirements all the time, right? Every
2
00:00:02,290 --> 00:00:04,960
time we build a software system. So how do people
3
00:00:04,960 --> 00:00:08,320
cope with these difficulties? What are the best practices?
4
00:00:08,320 --> 00:00:12,950
In practice, developers or analysts usually identify a whole bunch
5
00:00:12,950 --> 00:00:16,590
of requirements. Sometimes the easiest and most obvious ones. They
6
00:00:16,590 --> 00:00:19,370
bring those to the stakeholders, and the stakeholders have to
7
00:00:19,370 --> 00:00:23,100
read the requirements, understand them, and if they agree, sign
8
00:00:23,100 --> 00:00:25,580
off on them. And the problem is that in general,
9
00:00:25,580 --> 00:00:28,910
these requirements documents are difficult to read. They are long, they
10
00:00:28,910 --> 00:00:32,470
are often unstructured. They typically contain a lot of information. And
11
00:00:32,470 --> 00:00:35,310
in general, they are not exactly a pleasant read. So what
12
00:00:35,310 --> 00:00:39,710
happens is that often the stakeholders are short on time, overwhelmed
13
00:00:39,710 --> 00:00:42,380
by the amount of information they're given and so they give
14
00:00:42,380 --> 00:00:44,800
in to the pressure and sign. And this is a bit
15
00:00:44,800 --> 00:00:47,300
of a dramatization clearly but it's clear that what we are
16
00:00:47,300 --> 00:00:50,640
looking at is not an ideal scenario. Clearly this is not
17
00:00:50,640 --> 00:00:53,810
the way to identify the real purpose of a software system to
18
00:00:53,810 --> 00:00:57,920
collect good requirements. And since one of the major causes for project
19
00:00:57,920 --> 00:01:02,130
failure is the inadequacy of requirements, we should really avoid this kind
20
00:01:02,130 --> 00:01:03,590
of scenario. We should follow a
21
00:01:03,590 --> 00:01:06,810
rigorous and effective requirements engineering process instead.
|
