84 lines
2.0 KiB
Plaintext
84 lines
2.0 KiB
Plaintext
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.
|