1 00:00:00,270 --> 00:00:02,800 As we did for other lessons, before starting this 2 00:00:02,800 --> 00:00:06,150 lesson on requirements engineering, I want to ask a world 3 00:00:06,150 --> 00:00:10,210 expert on this topic a few questions. I'm here with 4 00:00:10,210 --> 00:00:14,150 Jane Cleland-Huang, a professor at the DePaul University. And Jane 5 00:00:14,150 --> 00:00:16,500 is a world expert in the area of requirements 6 00:00:16,500 --> 00:00:19,830 engineering, which is the theme of this lesson. So I'm 7 00:00:19,830 --> 00:00:22,220 talking to Jane who is currently in Chicago and I 8 00:00:22,220 --> 00:00:25,380 want to. Ask her a few questions about requirements engineering. 9 00:00:25,380 --> 00:00:26,530 So hi Jane how are you? 10 00:00:26,530 --> 00:00:27,990 >> Fine. Thank you Alex. 11 00:00:27,990 --> 00:00:29,480 >> And thank you so much for agreeing to 12 00:00:29,480 --> 00:00:31,960 be interviewed for our course, I'm sure the students 13 00:00:31,960 --> 00:00:34,080 will really benefit from this. And let me start 14 00:00:34,080 --> 00:00:37,240 with the first question which is what are software requirements? 15 00:00:37,240 --> 00:00:40,900 >> That's an interesting question. And software requirements 16 00:00:40,900 --> 00:00:44,220 basically provide us a description of what a 17 00:00:44,220 --> 00:00:47,520 system has to do. So, typically they describe 18 00:00:47,520 --> 00:00:50,550 the functionality of the features. That the system has 19 00:00:50,550 --> 00:00:54,420 to deliver in order to satisfy its stakeholders. 20 00:00:54,420 --> 00:00:59,010 And we usually talk about the requirement specification 21 00:00:59,010 --> 00:01:01,050 in terms of what the system's going to 22 00:01:01,050 --> 00:01:04,010 do. And we describe it sometimes formally in 23 00:01:04,010 --> 00:01:07,300 terms of set of shall statements, that the 24 00:01:07,300 --> 00:01:09,110 system shall do this or shall do that. 25 00:01:09,110 --> 00:01:12,330 Or we can use various templates to specify 26 00:01:12,330 --> 00:01:16,120 both textural requirements. But requirements can also be represented 27 00:01:16,120 --> 00:01:20,790 informally in, in the form of user stories, or use cases, or more 28 00:01:20,790 --> 00:01:26,180 formally in the form of state transition diagrams and even in kind of 29 00:01:26,180 --> 00:01:32,260 formal specifications. Especially for critical parts of safety critical systems. 30 00:01:32,260 --> 00:01:34,180 >> And another should discuss what the 31 00:01:34,180 --> 00:01:37,230 requirements are. What is the requirements engineering? 32 00:01:37,230 --> 00:01:41,180 >> So, that's also an interesting question because if you notice 33 00:01:41,180 --> 00:01:45,330 it's it's engineering and I'm sure in the 34 00:01:45,330 --> 00:01:47,750 other parts of the software engineering process that 35 00:01:47,750 --> 00:01:51,130 you're discussing in your course. Parts such as 36 00:01:51,130 --> 00:01:55,200 testing or coding. They don't have the word engineering 37 00:01:55,200 --> 00:01:56,930 there and I think one of the reasons 38 00:01:56,930 --> 00:02:00,310 requirements engineering has that term is because it covers 39 00:02:00,310 --> 00:02:03,570 a number of different activities. So it includes 40 00:02:03,570 --> 00:02:07,390 things such as working with stakeholders to elicit or 41 00:02:07,390 --> 00:02:10,620 to proactively discover what their requirements of the 42 00:02:10,620 --> 00:02:14,440 system are. Analyzing those requirements so that we 43 00:02:14,440 --> 00:02:17,380 understand the tradeoffs. So you might have different 44 00:02:17,380 --> 00:02:21,170 stakeholders that care about different things, and it 45 00:02:21,170 --> 00:02:26,086 might not be possible to deliver all of those things, so we have to analyze the 46 00:02:26,086 --> 00:02:29,140 feasibility of the requirements, explore the tradeoffs, emerge 47 00:02:29,140 --> 00:02:32,550 conflicts. And then of course the specification part, 48 00:02:32,550 --> 00:02:34,930 which we talked about a little bit already, 49 00:02:34,930 --> 00:02:37,340 and the validation, so did we in fact get 50 00:02:37,340 --> 00:02:40,480 the requirements right? Did we build a system 51 00:02:40,480 --> 00:02:43,490 that actually matches our, our requirements. And then on 52 00:02:43,490 --> 00:02:46,960 into the requirements management process. And the requirements 53 00:02:46,960 --> 00:02:50,860 management process. Kind of like goes through things like 54 00:02:50,860 --> 00:02:55,010 change management. So what if customer or stakeholders 55 00:02:55,010 --> 00:02:57,630 need the system to change? How do we manage 56 00:02:57,630 --> 00:03:00,180 changing requirements? And I think this is one of 57 00:03:00,180 --> 00:03:03,230 the reasons that we've coined the term engineering because 58 00:03:03,230 --> 00:03:06,490 that it's, has to be a systematic process which 59 00:03:06,490 --> 00:03:09,550 extends across. The whole of this is life cycle. 60 00:03:09,550 --> 00:03:12,890 >> And I guess my last question here is 61 00:03:12,890 --> 00:03:15,100 so now that we heard about software requirements and 62 00:03:15,100 --> 00:03:18,790 about software requirements engineering, why is requirements engineering so 63 00:03:18,790 --> 00:03:20,770 important? So what happens if we don't do it right? 64 00:03:20,770 --> 00:03:22,620 >> Well, I'm sure that, you know, 65 00:03:22,620 --> 00:03:24,880 many people have probably read the kind of 66 00:03:24,880 --> 00:03:28,560 report like Spanish report, and other reports of failed 67 00:03:28,560 --> 00:03:31,900 project, and things like that, and are aware that 68 00:03:31,900 --> 00:03:35,280 one of the major reasons for projects failing 69 00:03:35,280 --> 00:03:37,360 is because we didn't get the requirements right 70 00:03:37,360 --> 00:03:40,110 in the first place. So if we don't understand 71 00:03:40,110 --> 00:03:42,970 the requirements then we're simply going to build the 72 00:03:42,970 --> 00:03:47,960 wrong system. Getting requirements right includes all sorts of 73 00:03:47,960 --> 00:03:52,900 things such as finding the right group of stakeholders so we don't exclude major 74 00:03:52,900 --> 00:03:56,940 groups of stakeholders. Understanding the requirements correctly. 75 00:03:56,940 --> 00:03:59,910 There will be many, many different examples of 76 00:03:59,910 --> 00:04:02,310 projects that have failed. For example, in 77 00:04:02,310 --> 00:04:06,500 America the healthcare.gov failure, and while we cannot 78 00:04:06,500 --> 00:04:09,540 put the blame squarely in the area 79 00:04:09,540 --> 00:04:13,040 of requirements, because obviously the project was challenged 80 00:04:13,040 --> 00:04:15,650 for a number of different reasons. But 81 00:04:15,650 --> 00:04:21,070 clearly it underperformed in many respects related to 82 00:04:21,070 --> 00:04:25,740 security, performance, and reliability and these are all 83 00:04:25,740 --> 00:04:28,300 parts of the requirements process. Things that should 84 00:04:28,300 --> 00:04:30,000 have been discovered and the system should have 85 00:04:30,000 --> 00:04:32,914 been built in order to meet those requirements, 86 00:04:32,914 --> 00:04:36,240 getting the requirements right in the first place. 87 00:04:36,240 --> 00:04:38,110 Puts us, a project on the right foot. 88 00:04:38,110 --> 00:04:41,430 And so that gives us a much better chance 89 00:04:41,430 --> 00:04:44,940 of delivering to the customer what they need. And 90 00:04:44,940 --> 00:04:49,130 designing a solution that really meets those requirements. So, 91 00:04:49,130 --> 00:04:52,800 it's a critical part of the overall software engineering success. 92 00:04:52,800 --> 00:04:56,441 >> Okay. So that's critical. I mean, we better get our requirements right. 93 00:04:56,441 --> 00:04:56,987 >> Yeah. 94 00:04:56,987 --> 00:04:57,733 >> That's, that's the message. 95 00:04:57,733 --> 00:04:57,743 >> Yeah. 96 00:04:57,743 --> 00:05:00,822 >> Okay. Well, thank you so much Jane, for taking 97 00:05:00,822 --> 00:05:03,435 the time off your busy schedule to speak with us. 98 00:05:03,435 --> 00:05:07,150 I'm sure. The students really appreciate this, and we'll talk to you soon. 99 00:05:07,150 --> 00:05:08,480 >> Bye Alex, thank you. 100 00:05:08,480 --> 00:05:10,890 >> Bye, Jane, bye bye. Jane gave 101 00:05:10,890 --> 00:05:13,410 us an interesting perspective on requirements engineering 102 00:05:13,410 --> 00:05:15,410 and its importance. Let's now start our 103 00:05:15,410 --> 00:05:18,050 lesson with a general definition of requirements engineering.