1 00:00:00,190 --> 00:00:03,440 Unfortunately, extracting requirements from these sources is not 2 00:00:03,440 --> 00:00:06,220 a straightforward task, as there are many issues involved 3 00:00:06,220 --> 00:00:09,470 with the requirements elicitation. One first problem is the 4 00:00:09,470 --> 00:00:13,930 thin spread of domain knowledge. Knowledge is rarely available 5 00:00:13,930 --> 00:00:15,970 in an explicit form, that is, it is 6 00:00:15,970 --> 00:00:20,310 almost never written down. Moreover, knowledge is often distributed 7 00:00:20,310 --> 00:00:23,410 across many sources. For example, in the graphical depiction 8 00:00:23,410 --> 00:00:25,590 here, to find out that this is the purpose 9 00:00:25,590 --> 00:00:28,240 of the project. The developer, the analyist, needs to talk 10 00:00:28,240 --> 00:00:30,870 to a lot of different people. And, to make things even 11 00:00:30,870 --> 00:00:34,400 worse. There are often conflicts between the knowledge gathered from 12 00:00:34,400 --> 00:00:37,610 different sources. A second issue is the fact that the knowledge 13 00:00:37,610 --> 00:00:41,090 is often tacit. What is also called the say, do 14 00:00:41,090 --> 00:00:44,052 problem. In the example shown here. For instance. We have a 15 00:00:44,052 --> 00:00:47,650 customer that is describing to the analyst. The way in which 16 00:00:47,650 --> 00:00:51,060 he accomplishes a task. So it performs these three steps and 17 00:00:51,060 --> 00:00:54,300 reaches the goal. Whereas in practice, the actual way in 18 00:00:54,300 --> 00:00:57,530 which this task accomplished is by going through a larger number 19 00:00:57,530 --> 00:00:59,880 of steps to get to the same goal. So the point 20 00:00:59,880 --> 00:01:02,650 here is that, even if the knowledge were more concentrated, so 21 00:01:02,650 --> 00:01:05,660 not as spread as in this example. People simply find 22 00:01:05,660 --> 00:01:08,680 it hard to describe knowledge that they regularly use. So it 23 00:01:08,680 --> 00:01:11,740 is hard to make this knowledge explicit, to pass this knowledge 24 00:01:11,740 --> 00:01:13,130 to someone else. Yet another 25 00:01:13,130 --> 00:01:16,690 problem is limited observability. Identifying requirements 26 00:01:16,690 --> 00:01:20,570 through observation is often difficult as the problem owners might be 27 00:01:20,570 --> 00:01:23,550 too busy to perform the task that we need to observe. 28 00:01:23,550 --> 00:01:25,750 Or they might be doing a lot of other things together 29 00:01:25,750 --> 00:01:27,980 with the task that we need to observe, so that becomes 30 00:01:27,980 --> 00:01:31,530 confusing. That introduces noise. Moreover, even when this is not the 31 00:01:31,530 --> 00:01:34,460 case, the presence of an observer might change their problem. It 32 00:01:34,460 --> 00:01:38,020 is very typical for human subjects to improve or modify an 33 00:01:38,020 --> 00:01:41,760 aspect of their behavior, which is being experimentally measured in response 34 00:01:41,760 --> 00:01:44,110 to the fact that they know that they're being studied. You know 35 00:01:44,110 --> 00:01:47,110 that somebody's studying you and you change the way in which you behave. 36 00:01:47,110 --> 00:01:50,910 A typical issue. Finally, the information that we collect might be biased. 37 00:01:50,910 --> 00:01:54,270 For several reasons. People might not feel free to tell you what you 38 00:01:54,270 --> 00:01:57,030 need to know. Or, people might not want to tell you what 39 00:01:57,030 --> 00:02:00,240 you need to know. For example, in all the common cases in which 40 00:02:00,240 --> 00:02:03,870 the outcome might effect them, people might provide you a different picture 41 00:02:03,870 --> 00:02:06,770 from the real one. In order to influence you. So, they might have 42 00:02:06,770 --> 00:02:08,820 a hidden agenda, and mislead you, either 43 00:02:08,820 --> 00:02:11,860 consciously or unconsciously. So, all these issues 44 00:02:11,860 --> 00:02:14,370 add to the complexity of collecting requirements, 45 00:02:14,370 --> 00:02:16,522 of identifying the purpose of a system.