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.