From b2d80610db6beda38573890ed169815e495bc663 Mon Sep 17 00:00:00 2001 From: Nguyễn Gia Phong Date: Sun, 24 May 2020 16:34:31 +0700 Subject: [usth/ICT2.7] Engineer software --- ...rview with Jane Cleland-Huang - lang_en_vs5.srt | 411 +++++++++++++++++++++ 1 file changed, 411 insertions(+) create mode 100644 usth/ICT2.7/P2L1 Requirements Engineering Subtitles/2 - Interview with Jane Cleland-Huang - lang_en_vs5.srt (limited to 'usth/ICT2.7/P2L1 Requirements Engineering Subtitles/2 - Interview with Jane Cleland-Huang - lang_en_vs5.srt') diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/2 - Interview with Jane Cleland-Huang - lang_en_vs5.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/2 - Interview with Jane Cleland-Huang - lang_en_vs5.srt new file mode 100644 index 0000000..2a1bc1c --- /dev/null +++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/2 - Interview with Jane Cleland-Huang - lang_en_vs5.srt @@ -0,0 +1,411 @@ +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. -- cgit 1.4.1