1 00:00:00,130 --> 00:00:02,540 But how can we do that? How can we identify the purpose 2 00:00:02,540 --> 00:00:06,080 of the system and collect good requirements? To answer that question, let me 3 00:00:06,080 --> 00:00:07,800 give you another definition of requirements 4 00:00:07,800 --> 00:00:09,590 engineering. And this one is a classical 5 00:00:09,590 --> 00:00:13,010 one, one that summarizes what we discussed so far, and then we can 6 00:00:13,010 --> 00:00:16,180 use as some sort of reference. And it is a little long. 7 00:00:16,180 --> 00:00:18,710 Definitely longer than the one that we saw at the beginning. But it's 8 00:00:18,710 --> 00:00:21,840 an important one and it contains a lot of very relevant points. So, 9 00:00:21,840 --> 00:00:25,210 we're going to go through it and highlight these points. So the definition says, 10 00:00:25,210 --> 00:00:28,970 that the requirements engineering is a set of activities concerned 11 00:00:28,970 --> 00:00:32,990 with identifying and communicating the purpose of a software intensive 12 00:00:32,990 --> 00:00:35,770 system and the context in which it will be used. 13 00:00:35,770 --> 00:00:38,570 And this is exactly what we said at the beginning. But 14 00:00:38,570 --> 00:00:40,940 something we can highlight in here, is the fact that 15 00:00:40,940 --> 00:00:44,210 we're talking about a set of activities. So, what that means 16 00:00:44,210 --> 00:00:46,800 is that requirements engineering is not just a phase or 17 00:00:46,800 --> 00:00:51,050 a stage. It also says that it's about identifying and communicating. 18 00:00:51,050 --> 00:00:53,720 And what that is telling us is that communication is 19 00:00:53,720 --> 00:00:56,670 as important as the analysis. So, it's important to be 20 00:00:56,670 --> 00:00:59,990 able to communicate these requirements not only to collect them. 21 00:00:59,990 --> 00:01:02,018 And we will discuss many reasons why that is the 22 00:01:02,018 --> 00:01:05,880 case. It explicitly talks about purpose. So that allows me 23 00:01:05,880 --> 00:01:10,310 to stress, once more, that quality means fitness-for-purpose. We cannot 24 00:01:10,310 --> 00:01:14,410 say anything about quality unless we understand the purpose. And 25 00:01:14,410 --> 00:01:16,210 the last thing I want to point out in this first 26 00:01:16,210 --> 00:01:18,420 part of the definition is the use of the term 27 00:01:18,420 --> 00:01:21,060 context. This is also something else that we mentioned at 28 00:01:21,060 --> 00:01:24,890 the beginning, that designers, analysts, need to know how and 29 00:01:24,890 --> 00:01:28,015 where the system will be used. Without this information, you 30 00:01:28,015 --> 00:01:30,455 cannot really understand what the system should do and you 31 00:01:30,455 --> 00:01:33,280 cannot really build the system. So now, let's continue and 32 00:01:33,280 --> 00:01:35,755 read the second part of the definition that says, hence. 33 00:01:35,755 --> 00:01:41,550 Requirements engineering acts as the bridge between the real-world needs of 34 00:01:41,550 --> 00:01:45,315 users, customers, and other constituencies affected by a 35 00:01:45,315 --> 00:01:49,440 software system and the capabilities and opportunities afforded 36 00:01:49,440 --> 00:01:52,870 by software-intensive technologies. This is a long sentence, 37 00:01:52,870 --> 00:01:55,030 but also here, we can point out a 38 00:01:55,030 --> 00:01:57,670 few interesting and relevant points. Let me start 39 00:01:57,670 --> 00:02:00,612 by highlighting two parts. Real-world needs, and the 40 00:02:00,612 --> 00:02:04,150 capabilities, and opportunities. So, what are these two 41 00:02:04,150 --> 00:02:07,000 parts telling us? They are telling us that requirements 42 00:02:07,000 --> 00:02:09,949 are partly about what is needed, the real-world needs 43 00:02:09,949 --> 00:02:13,520 of all these stakeholders. But they're also partly about what 44 00:02:13,520 --> 00:02:16,100 is possible, what we can actually build. We need 45 00:02:16,100 --> 00:02:19,260 to compromise between these two things. And, finally, I would 46 00:02:19,260 --> 00:02:23,000 like to point out this term constituencies, which indicates 47 00:02:23,000 --> 00:02:26,220 that we need to identify all of the stakeholders, not 48 00:02:26,220 --> 00:02:29,130 just the customer and the users, so anybody who is 49 00:02:29,130 --> 00:02:32,040 affected by a software system. It is very important to 50 00:02:32,040 --> 00:02:35,130 consider all of these actors. Otherwise, again, 51 00:02:35,130 --> 00:02:37,530 we'll be missing requirements, we'll be missing 52 00:02:37,530 --> 00:02:41,120 part of the purpose of the system and we will build a suboptimal system.