# COMP1531 Week 7 Lecture 1 **Channel:** UNSW COMP1531 **Source:** https://www.youtube.com/watch?v=d6Uk4tkNwfE **Transcript page:** https://www.withtranscript.ai/video/d6Uk4tkNwfE ## Chapters - 1:35 — Lecture Setup and Course Roadmap - 4:56 — Client-Server Testing Overview - 7:41 — SDLC Shift Toward Requirements - 10:58 — Why Requirements Matter More - 15:19 — Understanding Exceptions in Code - 20:16 — Exceptions Through Self-Driving Cars - 31:42 — Try-Catch and Graceful Recovery - 42:50 — Revisiting Code Coverage Concepts - 48:52 — Server-Side Coverage in Practice - 1:02:16 — Second Iteration and Upcoming Topics - 1:03:47 — Requirement Analysis in AI Products - 1:24:57 — Writing Better Software Requirements - 1:35:05 — Functional, Nonfunctional, and Requirement Types ## Transcript **[1:35] Speaker A:** Sa. **[2:07] Speaker A:** Sam. **[2:36] Speaker A:** Sa. **[3:29] Speaker A:** Hello. Welcome back. Is the lighting okay? **[3:37] Speaker A:** Is it okay if it's loud, you can hear me. So it's week seven, huh? Oh, I don't know. I was coming and thinking like nursing that it's week six. Not used to this flexi week. **[3:52] Speaker A:** Hope you had enough time to maybe get some rest, work on iteration one and I know maybe prepare for what's coming next. So it's a slow start, as you can see. Sorry for the delay. We got some technical issues on the live streaming and. **[4:19] Speaker A:** Yeah, so I was thinking actually how to resume the lectures. I always come in here. So what I did, I just updated the, you know, the mind map that you are building together. I did update that. I think maybe I should go for full screen. **[4:48] Speaker A:** It got a little bit better using I think 6chatgpt6. **[4:56] Speaker A:** So what we saw so far, pretty much everything in that you need to see in the implementation part for the software development life cycle. We have few things that we need to revisit today. 2 or 3. 2 actually this week we're gonna see three things we're gonna not revisit. **[5:26] Speaker A:** Well, somehow revisit testing. Because what we were doing, like if you, if you look at this mind map. So we did a bit of everything, but the focus was on teaching you how to code collaboratively. So the teamwork, coding and testing. So maybe you reached the conclusion that coding cannot be decoupled from testing. **[5:56] Speaker A:** So you code and you test at the same time. We did the coding when we were working on the standalone setup. So everything you were working on was just on your local machine. Then you send to, you push it to maybe the master branch on your shared repository on bitlab still the app was working locally if you need to run it. Working collaboratively for a standalone app. Then we learned about the new architecture, like software architecture, which is the client server architecture. So we have a server. We are coding for a distant server. We spent some time on that. Then we talked a little bit about testing. **[6:42] Speaker A:** So testing in that setup, we're going to revisit it today quickly. So what does it mean to test? You are now very well versed with static and dynamic verification because of iteration one labs quizzes. Maybe now we're going to just. I'm going to just tell you that there is a new way to do it, but I'm not going to teach again the static and the dynamic verification, mostly the code coverage. So we've been working on trying to optimize the code coverage for iteration one. We're going to Maybe you're going to do it again for iteration two. But in this new setup, the same things, the same rules, same techniques, except just it's going to be with the new mindset, if I can use this term. And the mindset is it's client server. So you are running your testing in order to test whatever is implemented from the server side. **[7:41] Speaker A:** So that's what you need to understand. We're going to see it quickly, maybe spend 10 to 15 minutes on that. Something else we're going to talk about like. Like stretching on that is the exceptions. So I think I'm going to. Let me write them here. Let me see. **[8:06] Speaker A:** Week seven, lecture one. Sorry about that. **[8:15] Speaker A:** So quickly we're going to see the code coverage again. **[8:23] Speaker A:** In the setup of client, let's say HTTP then exceptions. Maybe you do them the other way around. **[8:40] Speaker A:** What do you know about. Except. **[8:45] Speaker A:** Then here. That's why I need this introduction. I started talking because of this transition that we need to talk about. We will step back and talk a little bit about requirement engineering and design. Because if you go to the software development life cycle. **[9:13] Speaker A:** Software development life cycle. Let's go. Maybe borrow this one here. **[9:28] Speaker A:** So this is requirement engineering, requirement analysis. We're going to spend some time on this and that requirement analysis and design. So it's like stepping back because all what we were working on is that development and testing. Okay, then week nine, we're gonna see a little bit of that. So seven weeks on this, not seven weeks. Actually week six is not counted. Five weeks and a half. I would say like half of this week development and testing. Then we're going to see requirement analysis and design. A conclusion of this development and testing is this mind map that I prepared for you first five weeks. **[10:15] Speaker A:** Are you following with me? I'm trying to equip you if I can use that with all what you need to prepare for the exam. So this is. First five weeks was mostly focused on development and testing. Then we're going to step back and talk about requirement analysis and design. **[10:38] Speaker A:** And these two are nowadays since 2024, much more important than what you were learning before, despite the fact or the importance of what you were learning before for okay, the requirement analysis and design. **[10:58] Speaker A:** So maybe I will spend some time like around 30 minutes before the break to finalize the testing, like code coverage in the setup of client server and handling exceptions. Exceptions. Maybe it's a new concept for some of you. I'm going to talk a little bit about that then. **[11:21] Speaker A:** Yeah, next week there is another concept. It's actually Part of the, of the development. **[11:28] Speaker A:** But I tried to put it like to separate it and put it in a different lecture like next week because it's step zero for the security part. Cyber security part in software engineering life cycle, which is off. We call it off. **[11:48] Speaker A:** Maybe it's a lazy way to talk about two different concepts. They are linked, but they are different Authentication and authorization. So we're going to talk about that next week. So I'm going to tell you the mind map of this week. Week seven, we're going to finish all of the development and testing part by today. **[12:15] Speaker A:** Start, step back and start the requirement analysis and the design next week. But next. Not next week, next. Yeah, next week actually. But the start is going to be the end of next lecture. **[12:34] Speaker A:** I'm struggling here because I'm trying to put everything in one week again. I'm going to repeat gonna see exceptions and what's the other concept I talked about exceptions and code coverage. We saw code coverage. Right. You got sick and tired of it in iteration one. **[12:57] Speaker A:** Right. We're going to see it in a different setup. That's all of this is going to take 30 minutes. Exceptions and code coverage. Put it aside. **[13:05] Speaker A:** Done with 95 of the development of the testing. Let me go back to the SDLC part. **[13:14] Speaker A:** Done 90% with this part here. Then I will be spending maybe 30 minutes next lecture on Thursday talking about off. Off. It's the step zero. I'm not gonna even call it step one of the like having a secure software because we are talking about everything in the software engineering life cycle, but we are not talking about security. **[13:37] Speaker A:** Because this is, if I think about it, this is software engineering. Development and security is something that comes like horizontally. So you are developing. When I say it comes horizontally, it does not mean that it comes just once and it will intersect with software. We will see it multiple times. **[13:58] Speaker A:** But step zero, the very first intersection between the software development life cycle and cyber security practices is login off. Okay, you're going to see it next. Next lecture. **[14:14] Speaker A:** What's more important, I'm going to reiterate again is requirement engineering and design. It's more important because of AI. Many things that you are learning now are going to be easier using AI, easier to do using AI, or maybe you can delegate the tasks completely to AI. So what is it that you need as a software engineer now is controlling the design and before the design, controlling understanding the requirements that you are building the software for. Does it make sense? **[14:59] Speaker A:** Does it make sense at 2:20pm the last 15 minutes I was Talking maybe after lunch. Okay, so we're going to see it little by little now, but just I tried to build a mind map that what you're going to see next. **[15:19] Speaker A:** Let's start with an easy concept now. Exceptions. **[15:28] Speaker A:** Have you heard of exceptions before. **[15:41] Speaker A:** In this part of the lecture? Actually, it's not in this lecture. Have you heard of exceptions? **[15:48] Speaker A:** I'm going to give you an example here. Some of you are coming from C maybe if I have a. I'm going to give you two examples. One example is in arithmetics, like using addition, subtraction, multiplication and division. And in your inputs you are not, there is a high chance, not high chance. There is a chance that you would have a division by zero because you'll be receiving two inputs, A and B. **[16:21] Speaker A:** Maybe you multiply them, you add them, you subtract them. Depends on the conditions that you got in the division part. There is no control that stops you from having zero as an input. And you might end up in your code in like doing a division by zero. What do we call that? **[16:38] Speaker A:** Is this an issue or is it okay, obviously it's an issue, right? How to control that? **[16:55] Speaker A:** The name is exceptions, right? So the example that I just gave you in arithmetics we have numbers. Feed them, maybe just a B couple of numbers. You feed them and you have your all of your arithmetic operations. One exception is division by zero. If one of the if like in the division, one of the inputs is zero, not one of the inputs. Like if you divide by zero, you will get an error. This is an exception. So how to handle this exception? We're not going to spend too much time on that. So this is the issue, another issue. So this is an issue in math, like it's out of your control. Another issue is imagine that we will see in the live practice. Now you have just the code that we were using in the last few weeks grades. So if you have grade from 0 to 100 and according to that grade, you can give the credit. **[17:54] Speaker A:** It could be fail pass, credit distinction or high distinction. We assume that the input is from 0 to 100, right? If you get something like minus 20 or 9999 or ABC as an input, what would you do? **[18:12] Speaker A:** So that's something that you need to control to handle. Okay, you are assuming that you have a mainstream of input coming to you and you have some exceptions. **[18:23] Speaker A:** Scenario A, zero could be an exception. Scenario B, any the mainstream is from 0 to 100 and all like any other value is an exception. How to handle these? That's it pretty much, I think all of the slides are about that. **[18:41] Speaker A:** So how to handle that? If you get 0 or a value more like not between 0 and 100. How to handle that? You can look at this code. How can we handle it? **[19:01] Speaker A:** It's obvious. Coding here is just like trying to project or flash out. If I can use just this informal English, your logic as a code. And the code happened to be here JS JavaScript. **[19:20] Speaker A:** So how would you handle it if you get this error? If you get zero division by zero, the code is going to crash, right? We don't want our code to crash here. So what should we do? **[19:35] Speaker A:** We want the code to keep working for the rest of the inputs. But for this exception we wanted to handle it in a. In a smooth way. How can we do that? **[19:49] Speaker A:** Just need an input from you and I'll go to the practice. You can use the slides by the way, you can access the slides from the SharePoint, but I just need an input from you so I can jump to the practice session. I don't want to waste time on this because it's a bit. What you saw earlier is way more complicated than that. **[20:16] Speaker A:** Any thoughts? **[20:25] Speaker A:** Any thoughts here. **[20:33] Speaker A:** By the way, you can access the code. It's already shared with you here. **[20:38] Speaker A:** Exceptions. Yeah, here, It's open. **[21:36] Speaker A:** Let's start with this code first. **[21:41] Speaker A:** So what's the issue with this code? Imagine that we did not deliver this class exceptions. We did not talk about it at all. No labs, no lecture, no quiz about that. And you get this piece of code in the exam and the question is, spot the mistakes in this code. **[22:01] Speaker A:** What's the mistake here? **[22:18] Speaker A:** The thing is that when you get an error state, then just exists approximately without properly. **[22:30] Speaker A:** So it says processor exit 1, which means that the minute that you get a score that's less than 0 or greater than 100 or it's not a real number, then just think. So somehow we are handling the error, but not in a smooth way. So what happens? We have a code, we are expecting set of values 0 to 100. If it's there in the mainstream, that's good. **[22:56] Speaker A:** If it's an exception, the code just exits, crashes in a polite way. So this is handling, but this is naive handling. Like in this code you might accept it. But if you have a complex software and you get plenty of exceptions, how would you handle them? Example, self driving Tesla cars here in Sydney. **[23:24] Speaker A:** Can you think of exceptions for the self driving Tesla cars? **[23:34] Speaker A:** Maybe the exceptions are more than the mainstream inputs, right? Can you think of this setup like Tesla car has an amazing self driving software, then it gets a bunch of exceptions. Can you give me an example of exception and how would this self driving software handle that? **[24:01] Speaker A:** Then we see this naive ridiculous examples here. Yeah. **[24:05] Speaker B:** So I think if we were to take the most basic version of what was written for the desktop, it would be that when there's a green light you go ahead and stop. But what if there's like, let's say something in front of you when there's a green light? So without the exception it would probably either just not know what to do or you just go ahead and override that and just crash it. **[24:27] Speaker B:** So **[24:28] Speaker A:** that's, that's, that's good. Can you repeat it and like simplify it? **[24:32] Speaker B:** Yeah. So basically **[24:34] Speaker A:** start, start with the mainstream, with, with the. Yeah, normal case. **[24:39] Speaker B:** Normal case would be that when there's a green light, the Tesla car would just go. When there's a red light it would stop. **[24:44] Speaker A:** Okay. **[24:44] Speaker B:** If there's something in front of it like another car that's not holding as fast, or if there's another person and there's a green light, it would either not know what to do or it would just go ahead and override that and just crash. And the person. So the exception would be maybe trying to handle that by saying that you maintain like a distance between any. **[25:07] Speaker A:** Okay, so you are saying that the normal case is whenever the car sees a green light it goes ahead. Right. But the exception is assuming that with the green light it's going to be like free for like the, the road is for you. Right. But if someone like pedestrian or another car. **[25:27] Speaker A:** So this is the exception. Yeah, we can take this as an example. But Tesla does not rely on the lights, it relies on vision. Right? Yeah, yeah. Can you improve your example a little bit like by the car relying on vision? **[25:44] Speaker A:** Because if like relying on vision, it can **[25:49] Speaker B:** use computer vision to know what light. **[25:52] Speaker A:** Yeah, that's one input. Another input is relying on the surroundings. Yeah. So imagine, I can give you an easier example here. **[26:04] Speaker A:** A reckless driver. So you are driving in a highway and you have the assumption like the self driving, the presumption is everybody is in their lanes and when they are trying to change it, they use the light like indicator or they do it not suddenly, not in an abrupt way, just slowly. Right. But imagine that it happens in one instance abruptly. What would the car do? **[26:39] Speaker A:** Sorry. **[26:43] Speaker A:** Yeah. Okay, let's talk about version 30 of this self driving software. They improved it. What would it do? **[26:55] Speaker A:** Yeah, so the first instance it slows down. Okay. It happens again. What would happen? **[27:04] Speaker A:** It happens again in a random way, not a pattern. **[27:12] Speaker A:** So when you are in this lane, it happened abruptly here. Then you slow down, you save the day or you save the moment. Then just after a few minutes another car from the other lane. What would the self driving software do? **[27:33] Speaker A:** Either it gives up the control. Right. Or so this is what I mean by handling exceptions. So if it's once it's fine if it's repeated. So you need to ensure a smooth handling of exceptions when they happen. **[27:50] Speaker A:** So the first time you can handle it. I can rely on this software, I can rely on a self driving car. The second time it's fine. But if it's repeated in a non like in a random way there is no pattern to capture. So it's a absolute exception. I need to handle it. Maybe I give up the autopilot and. Yeah, go ahead. **[28:15] Speaker C:** Any exception in this case be more along the lines of say the LIDAR sensors gave a nonsense value. Like for example one of the LIDAR sense **[28:33] Speaker A:** conflicting readings. Essentially. Yeah. Maybe there's a group of them that are all getting a certain distance, a certain distance through the an object there but one of them is giving like a massive distance. Like there's something there like a faulty sensor for example. **[28:49] Speaker A:** Faulty sensor? Yeah, essentially. Yeah, yeah. What would you do? Yeah, yeah that could be an exception. Yeah. **[29:07] Speaker C:** But it's like two two k's away instead of two meters away but a one that the correct. **[29:19] Speaker A:** Yeah. So see, see the point here like when we went to this Tesla accept driving car. The the line should be very clear or clearly delineating between all what's expected. The mainstream, what they call the mainstream then the exceptions. But sometimes it's a fine line and you have to handle exceptions. You have to handle both cases in a smooth way. Many AI scientists said that it will never work. Self driving cars would never work. Many optimistic engineers like yourselves were like doubling down that it's going to work and we, we can see it nowadays right. Something in the middle. **[30:12] Speaker A:** So we have like the normal self driving but sometimes we have exceptions. Why is that? Because like the self we don't have 100% self driving cars. So we have, if we have 100% self driving cars it's going to be easier. But we have self driving cars and the exceptions that we have people driving cars. **[30:29] Speaker A:** So the behavior is completely different. These self driving software, they have to handle all of these exceptions. Handling exceptions in a smooth way is trying to recognize a pattern of that of these exceptions and handle them. If not give Up. Try not to give up from the first moment. Like this code here, okay? That's the worst way to handle exceptions. Exceptions could happen from the external environment and very good point that has been raised which is division by zero. Something from your logic, maybe from internal senses. Now how to handle that. **[31:11] Speaker A:** What we did in this live practice here, we prepared for you three versions of handling exceptions. So the first one here is just exit. The second one you tolerate it once. The third one you tolerate it maybe twice or three times. The fourth one, the best solution is you have a way to tolerate it continuously and that's the best way. Well, this is an easy example here. **[31:42] Speaker A:** But just like you got the idea right of exceptions, any questions? So I'm going to show you here in the practice, any questions about this philosophy of AI and self driving cars and exceptions. **[31:59] Speaker A:** Okay, so I'm assuming that you understood that if you have questions you can ask later or you can come. If you have any better example that, please feel free to share it with us as well. So I'm bringing AI now. I'll be bringing it a lot actually in the next four weeks or next three weeks because yeah, I forgot there's some announcement to talk about and I forgot about it because I'm not just focusing on your examiner project, I'm focusing even on preparing you and what you need for your future jobs. So this part, the second part of the the course is more about what you need in this AI era. **[32:41] Speaker A:** Like mostly design and understanding requirements. Okay, so let's see that the this code here. **[32:53] Speaker A:** Okay, quickly, quick refresher here. I'm importing these prompt. So in order to use like prompt the user from the terminal here getting a prompt then importing this function here. Importing grade from score from this here. Let's start with actually start with the easiest grades ts. **[33:25] Speaker A:** So I'm importing grade from score like this function here. **[33:32] Speaker A:** This is a function that I am using in this code here. I'm importing it and importing prompt in order to prompt from the terminal. So let's run this code. **[34:00] Speaker A:** Let's first install. **[34:24] Speaker A:** Okay so if we give it normal score, let's say 90 being optimistic. So it worked. Right. But if we give it so what we got is score must be between 0 and 100. That's it, that's an exits. **[34:49] Speaker A:** This concept is called. **[34:58] Speaker A:** EAFP. Easier to ask forgiveness than permission. It's like the naive sorry I couldn't do it. That's it, that's what happened. So a better way to do it. **[35:10] Speaker A:** So if we go to. So this is the naive one. If we go to this code here. **[35:22] Speaker A:** Look at this part here in the code. **[35:32] Speaker A:** What does it mean? So we upgraded this code, we upgraded the grade from score with this one. **[35:45] Speaker A:** The function is grade from score which we are exporting and it will be imported here. Grades input. So it's imported here from. We're going to import it now from exceptions one. And if we go to exceptions one, this is the function here. **[36:07] Speaker A:** And we got this piece of code. What does it mean here? **[36:22] Speaker A:** Try catch. So we are trying here at this input. If it's not within the mainstream we catch an error. Right? Let's. **[36:42] Speaker A:** Run again. **[36:49] Speaker A:** So just score must be between 0 and 100 and it's telling us that it's an error here. Okay, what's this? Try and catch. What happened? Higher view. **[37:05] Speaker A:** It's just telling you that it's an error because the value that you gave us is not like you got more input from the code but you made an error because the value that you gave is not between 0 and 100. And that's what we are expecting. Now look at this part here. Try catch. Same logic. We're going to use it here. **[37:27] Speaker A:** So what's the difference between the first one and the second one? A little bit of improvement by adding enter the value again, right? I'm giving this logic in this ridiculous example. But it applies to any complex software. Software. That's why I gave you the example of the self driving cars. But even like even computer vision, maybe some of your friends are doing their honors and they're working on AI. You will be developing software or mini software for your experiment like computer vision experiment. And any AI tool should be able to handle exceptions in a smooth way. So I'm just showing you how to handle it from a naive way to a smooth way. **[38:14] Speaker A:** So what we did here, we just give you a second chance, right? So interior score. **[38:24] Speaker A:** It's an error, right? **[38:41] Speaker A:** So the first time it accepts it. The second time we are back to the same issue. So what should we do? **[38:55] Speaker A:** Actually we should jump to three here. **[39:04] Speaker A:** This. **[39:14] Speaker A:** I wish that I can give rewards. And if one of you can explain that code to me, that piece of code that we added to handle exceptions in this function. Yeah, Grade from score. And we added that. **[39:33] Speaker A:** Yeah. **[39:41] Speaker A:** So you what's the improvement? What's the improvement from what we were doing? That's all. There's nothing wow about it. I'm telling you we should not spend too much time on it because what you did is way more complex than that explain just this logic. Yeah. **[39:59] Speaker B:** So what's happening is in the prompt function we've said thrownueer. What thrown you error does in JS is it creates an object called error or name and that or L over here. And that error object has three parameters. Name, message and stack. **[40:13] Speaker B:** So what we're using over here is we said that if success is equal to false, which is by default if there's no success, which means if it's false, I mean pilot's false, you try saying please enter your score and then you console a log with grade from score and then the success changes to true. This will only happen if there's no error. If there is an error, then it catches the error object. It says that for error, instance of error, which is the main object, you print the message parameter of the error. **[40:44] Speaker A:** You explained the core of it, the Try catch thing. But I did not explain what I was looking for. **[40:57] Speaker A:** Oh, sorry, what did I do? Clearly I just closed it here, this part here. **[41:12] Speaker B:** So while success is false, you try and then the minute that it goes successful success. Genius. True. And then you stop the while. But if it still falls, then dummies and heads and **[41:23] Speaker A:** error. **[41:25] Speaker A:** That's good. I told you. Core focused explanation. So the explanation should be like what we are trying to do, like a smooth way to handle exceptions by tolerating multiple times. **[41:39] Speaker A:** Okay, that's like. Because the main difference here between this code and this code here, exception two, just that loop is not there. That loop like the success. The loop with the flag of false or success. Okay, so what the takeaway from this, very good. Actually explaining the core of the Try Catch thing. But don't worry about the try Catch syntax. Now assume that it's just shrink wrapped black boxed tool for you to handle exceptions. How to use it in like to handle exceptions in a good way. You can use it once, it just displays an error. You can use it maybe twice or three times with just repeating the code, like repeating the prompting the user to give more input. But the best way to do it is to have this exception handling tool within a loop. So you tolerate multiple mistakes as long as they're not fatal, right? **[42:45] Speaker A:** Yeah, pretty much. That's it. So that's the exception part. **[42:50] Speaker A:** Well, it was to be waived actually from the course, but I said okay, let me spend maybe 20 minutes on that now. Any questions about that, about handling exceptions? And okay, one more thing. We finished. Now we need to revisit code coverage. By the way, anyone got 100% code coverage for iteration one? **[43:30] Speaker A:** Anyone got 100%. 97 like is the winner now any 100%? **[43:37] Speaker A:** Did you get 100%? **[43:42] Speaker A:** Is it possible to have 100%? No, you don't have to answer. I want to hear it from. Is it possible to have 100%? Theoretically guys, yes or no? I'm not looking for explanation. Yes. No. **[44:00] Speaker A:** Yes or no? Why is that? Because you never know what the user's going to do. Sorry, you never know what the user is going to do. Theoretically, yeah, theoretically you never know what, what the user going to do. But in your case here, so what you, what you did. **[44:22] Speaker A:** Okay, it's debatable. Not just at this level here of this comp 1,531 having 100% code coverage. Because you look at it from the perspective of you as a developer or from the perspective of the inputs that you get right. And I like the way you put it in plain English, you never know what the users can do. That's why exceptions are important. **[44:48] Speaker A:** By the way, what we were talking about here because you might get what you expect them to get to get from them, I should say. Or you might get something completely exceptional and you need to handle that. Okay, so for the code coverage now the very same thing, but just in a different setup. We're going to see it quickly here. **[45:12] Speaker A:** So what we did or what I did, okay, This is exceptions, this is requirements engineering. Yeah, it's like a manual here. **[45:34] Speaker A:** It's not a lecture slides but more of a manual. We have seen coverage before. But what I did, If you use the dynamic verification that we know of. So what's going to happen is it might work but you will not get the exact coverage because you are not covering the code run on the server side. So that's what you will get. **[46:05] Speaker A:** And in order to get that. **[46:10] Speaker A:** Well, this is an example here. Well, I'm not going to talk about this example here. **[46:21] Speaker A:** You just need this slide here. **[46:25] Speaker A:** So you run the test from the server side. Actually you run the server. You run the server and you run the tests from the client side. And when you run the tests from the client side, they will not be run just locally, but they will go to the server will be run and you will get the score from there. That's what we. **[46:48] Speaker A:** So we will see quickly in a practice like this, a practice of this slide here. And in order to. The new thing here that you need to learn about is that is C8 like the dynamic verification that we are used to is just you are using vtest but it runs locally in order to run vtest on the server side. So you need this C8 package here. So just you install the C8 package and the code coverage will be like. It's going to be counting the tests, the tested lines of code on the server side. Just C8 package, install it and run it. That's it. Like, this is. **[47:47] Speaker A:** We're going to practice one example to explain this slide here. And we will be pretty much done with everything in the testing and development that you are required to learn in this unit. **[48:04] Speaker A:** Okay, Any questions? I saw like, some of you raised your hands, but I, I got carried away with my explanation. Any questions? **[48:15] Speaker B:** It was actually about the. **[48:20] Speaker B:** How many edge cases can you account for? Because as I said, you never really know what the user can. **[48:28] Speaker A:** Yeah, we're gonna, we're gonna see that here. We're gonna, we're gonna see that in the live practice and we're gonna discuss that. Actually, let's take it with us to the practice now. **[48:38] Speaker A:** So we're going to spend maybe 10 minutes, then we'll take a breather of maybe 10 minutes and take your question with you to the practice here because we are not going to get 100% and you help me find out why. **[48:52] Speaker A:** Okay. **[50:15] Speaker A:** Okay. So the same thing, we're going to follow the previous example. So we have grades here, same code given credit according to the mark. Then a server that implements this function, we're going to run that server. **[50:41] Speaker A:** You already got access to that code on your GitLab. **[50:51] Speaker A:** So if we. **[50:58] Speaker A:** Just have a new terminal to be on the safe side. Oh, my bad. **[51:14] Speaker A:** So first thing. No, cannot copy the over NPM run start coverage. **[51:32] Speaker A:** Let's make sure that we have everything installed first. **[51:52] Speaker A:** Okay, so let's assume that this is the server side, this one is the server side. So I'm going to do npm. You can split the terminal just from here. NPM hit start. **[52:13] Speaker A:** Let me make sure. So we prepared everything here. If you want to check like in the package. JSON was working on them before the lecture, actually. So what we got here. **[52:27] Speaker A:** NPM start. Yeah. So now we need to start the server. **[52:36] Speaker A:** As usual. The server is running and listening now. So if we go like check. That. **[52:46] Speaker A:** Just happened here. **[52:52] Speaker A:** Sorry. **[53:06] Speaker A:** So we, we got a mistake here because I did not put a score. But If I put 90, so it's HD, right? **[53:20] Speaker A:** I put. **[53:24] Speaker A:** Okay, so it's working now the server is working. How should we test it? So we go to the client side and run the test. **[53:39] Speaker A:** Okay, Test. **[53:48] Speaker A:** So running the test, we'll run this code here because this is the server. And these are our tests. I implemented these tests using some AI. So I'm coming to your question here. **[54:07] Speaker A:** Then let's see the coverage. **[54:13] Speaker A:** So for the coverage. **[54:17] Speaker A:** So that's the coverage of vtest. Let's start with that. **[54:23] Speaker A:** Sorry. NPM run Coverage. **[54:30] Speaker A:** So we got this coverage, right? **[54:36] Speaker A:** It's saying that we got 90% and the uncovered line is 14. **[54:48] Speaker A:** Now this is the coverage VTEST coverage that we saw before. Then let's see the coverage. **[54:59] Speaker A:** Because I added this here. **[55:05] Speaker A:** Scripts. **[55:10] Speaker A:** Start. Coverage. Okay, there is one coverage that I added of the eight, right? **[55:21] Speaker A:** Let's check quickly here. **[55:26] Speaker A:** Coverage. Coverage. Coverage C80 coverage C8. **[55:38] Speaker A:** Again npm run. **[55:47] Speaker A:** Let's focus on this one. **[55:52] Speaker A:** So what's the difference between these two? **[56:00] Speaker A:** First coverage and the second coverage? **[56:07] Speaker A:** Here I used coverage. **[56:11] Speaker A:** Can you see? It's just the VTEST dynamic verification coverage that we know. Then coverage C8. I just added it. **[56:22] Speaker A:** So that's what's testing. It's testing. **[56:28] Speaker A:** What's the difference? **[56:37] Speaker A:** It overlaps with the answer to your question. Not answers your question. What's the difference between these two? **[56:55] Speaker A:** So the first one, which code is. It's checking. **[57:03] Speaker A:** The client. So which is grades? **[57:12] Speaker A:** Is it checking? This one. **[57:19] Speaker A:** And this one. Which code is it's checking server ts. **[57:31] Speaker A:** Let's see the lines here. Yeah. Line number 14. Okay. **[57:44] Speaker A:** See the test that it passed. Can you see the difference? Look, which codes are being tested here in the V test coverage and the C8 coverage. So the C8 coverage straight forward to the server code or lines of code and it verifies them whether they have been tested or not. Technically we do not have server test ts. **[58:18] Speaker A:** Nothing is being tested on the server side. What's tested on the server side is just this function that is being called. Okay. By the server. **[58:33] Speaker A:** Now 1 to 18. 9 to 17. Yeah, pretty much here. Maybe just the calls are being tested. And this one is saying line 14 of which code? **[58:46] Speaker A:** And we will finish the first half of this lecture. **[58:52] Speaker A:** All the tests passed. But something that did not, that hasn't been tested. And we got the percentage of 90%. All the functions are being tested. The branch is tested. **[59:05] Speaker A:** Not all of them tested. And the lines. Not all of them tested. If you go line 14 here. **[59:13] Speaker A:** Sorry. **[59:19] Speaker A:** Yeah. So in this. In this coverage, the distinction has not been test been tested. And if we look at that. **[59:33] Speaker A:** We tested invalid score. We tested like the. Between 0 and 100 here. 49, 50, 75, 85. Okay. **[59:48] Speaker A:** It's tested, but not fully. Then what I did, I tried to add more cases Here. **[59:59] Speaker A:** But still I could not cover all the cases of distinction. That's why I'm still getting 14 here. This line is not being fully tested. So somehow it's bad design of testing. Okay. **[1:00:17] Speaker A:** However. So it's still important, but it does not COVID testing the server side. **[1:00:27] Speaker A:** Well, you help me figure it out because you already got the dynamic verification class and you practiced that in your labs and iteration one. We're not going to solve it now. Just I want to point your attention to that. So this. This coverage C8 here is about testing the lines of code from the server side, which is literally that the server that's running here, the lines here. **[1:00:53] Speaker A:** So what is it that has been tested? Maybe just the function. **[1:01:06] Speaker A:** Yeah. So you have that code. Let's stop the. You can improve the score and let me know about it maybe next lecture or next week. So pretty much that's it. **[1:01:19] Speaker A:** So we just revisited. Let's go quickly here to our schedule. **[1:01:29] Speaker A:** Exceptions. Yeah, sorry. Is C8 coverage just checking what all is being called from the other files onto the server side and then checking in those tests? Yeah, pretty much. That's it. That's it. So it's just. It accounts for the lines of code from the server side. That's it. And that's what you maybe need to redo in your testing. Like in the iteration. The second iteration. So all of your coverage was in a standalone setup when you have a client server. So you're gonna split somehow your application back end server side. So how to have coverage from the server side. **[1:02:06] Speaker A:** That's what you. Where you need this concept of test or code coverage from the server side. Yeah. **[1:02:16] Speaker A:** So I opened that. We're gonna take a breather now of maybe it's like 10 minutes. **[1:02:22] Speaker A:** But before that just gonna tell you next week we will have next lecture. Actually we will have around one hour or maybe one hour more than that to talk about the second iteration. Please read all of the specs and start working. Actually so you. If you have questions you can ask them during the lecture. **[1:02:46] Speaker A:** So be were off. That's yeah. For the second iteration for exceptions code coverage. Then after that let the iteration two. We're going to see the Auth spend some time on Auth and start the design part. So we're going to spend some time on design this week and next week. But before that there was a part that we skipped that we should have talked about it earlier, which is requirement analysis. We need to talk about it now. Why is that? Because in iteration two you need to do some requirement analysis. You already got my interview with Ronnie. Did you get that? So there is recording of me and Ronnie talking about your app and you need to get the requirement from that. Have you seen that? **[1:03:37] Speaker A:** Okay, so it's 11 minutes and you need to watch it and get my requirements. Requirements. It's part of iteration two. We're going to talk about requirements in the second half of the lecture. **[1:03:47] Speaker A:** Let's take a breather of maybe eight minutes. **[1:03:50] Speaker A:** It's 3:13. Let's meet at 3:22. Yeah. **[1:04:07] Speaker A:** It. **[1:06:41] Speaker A:** Sa. **[1:07:58] Speaker A:** Sa. **[1:08:24] Speaker A:** Sam. **[1:08:49] Speaker A:** Sa. **[1:09:15] Speaker A:** Sam. **[1:09:40] Speaker A:** Sa. **[1:12:43] Speaker A:** The website. **[1:12:46] Speaker A:** Let's resume. Just all. I think I already mentioned about it in my weekly newsletter. We released a practice exam for you. **[1:13:01] Speaker A:** Yeah. So that's practice exam to get taste of it, I think in with the forum. **[1:13:39] Speaker A:** Yeah. **[1:13:42] Speaker A:** Can you see that you got this practice exam here. Can you see it? Can you access that? You will get the flavor of it. I wouldn't say it's exactly the same. **[1:13:58] Speaker A:** Of course not. But similar. So that's the type of questions you will get. It's not. This is a help from us. We might release another exam next week. Not next week, by week nine. So week nine or week ten. And yeah, so as I said here in the. Sorry, where's the announcement? **[1:14:24] Speaker A:** 50% theory and 50% programming. **[1:14:29] Speaker A:** And to understand that, you can see the questions, the theory questions and the practice questions. So you have starter files and you finish the code and we will ask you about what we saw. So anything that we learned or will be learning, you will get some questions about. Okay, Now let's talk about requirement analysis. Requirement analysis. **[1:15:01] Speaker A:** Okay, simple. Start ChatGPT. It's a SaaS, right? Software as a service. **[1:15:13] Speaker A:** You open it, you prompt it and you get something. Right. If you have been using ChatGPT in its first days, it was just chat. So you prompt and you get something. Then it got improved to the point like these days we have either a tab of chat and a tab of work. **[1:15:40] Speaker A:** And in each one of them we have levels instant, medium and high. Right. For the chat. So all of these are improvements started from December 2022 and it got improved to what we saw now. And it's getting even better. **[1:16:04] Speaker A:** And there is a competition, whatever, like what's happening there in that AI sphere. But what we need actually in the requirement analysis part, how did these Chat GPT developers think of that UI that they got? That's question one. Put aside. **[1:16:33] Speaker A:** Before the release of ChatGPT, we were using Google, right? Google. It's very simple. You have that small window, you look like you put Your query there and you get something. Right. **[1:16:48] Speaker A:** Then Google tried to catch up with this. ChatGPT before, their software was about information retrieval. You put a query and you get something. And they were the best, the ultimate best at that. But we got something new now, which is AI ChatGPT. You have this chatbot, advanced chatbot, and you communicate with it. Google, they are trying to catch up. So how. What did they do to add AI services into their UI that. We are already used to it. **[1:17:27] Speaker C:** In the beginning, ChatGPT was just something that could replicate human language. Back in the day, **[1:17:33] Speaker A:** it didn't have the capacity to think. If you remember, it had no access to the Internet. It was limited to 2022 knowledge. **[1:17:40] Speaker A:** So it was just a way for a machine to sound useful. So it was more of a chat interface than an actual search engine chatbot. It was a. Yeah, exactly. So they do installation from WhatsApp, stuff like that. Yeah. **[1:17:57] Speaker A:** Sorry, should I share again? **[1:18:05] Speaker A:** Sorry. **[1:18:08] Speaker A:** You can reconnect if you want. Yeah, okay. So, not quite sure like what, what's your point in like what? You say it was a chatbot and Google was an information retrieval website. **[1:18:24] Speaker B:** Yeah, **[1:18:25] Speaker A:** different. Right. **[1:18:27] Speaker B:** So then ChatGPT became the namesake for AI. **[1:18:31] Speaker A:** Okay. Just **[1:18:32] Speaker B:** copy from whatever was built on that, even though it's not the most practical way to display the information. **[1:18:41] Speaker A:** Yeah. So you are talking about two different softwares now. But just like my point, like my question was I gave the first scenario about ChatGPT. Like maybe you are answering the first question, but the second question is just I used it as a segue because Google, we know them with their information retrieval, their ui, then they wanted to catch up with this Cloud and ChatGPT and Deep Seek and they added AI services to whatever. They got the software that we are already using as users. **[1:19:13] Speaker A:** What did they do that was a problem for them? Okay, and Chat GPT, the problem for them, what you were trying to answer is they had an AI service and it was just a chatbot and they were thinking how to release this service. What would be the ui? What would be. What would be good for users? **[1:19:35] Speaker A:** Just using plain English. So just these two questions are an introduction for my information. Sorry, requirement engineering step in the what is the. **[1:19:56] Speaker A:** Requirement engineering step in the software development lifecycle. So we got it the very beginning for the first question, ChatGPT. And we got it at the very end for this. Google, when they have everything working, then they got. They wanted to catch up with these AI services. **[1:20:13] Speaker A:** They finished the software development life cycle and they wanted to add this AI Services. So it's at the very end of the software development life cycle, which IGBT at the very beginning. What's, what's this and what's that? Like can you, can you help me like think like put ourselves in the shoes of these engineers, software developers in OpenAI. And how did they like you tried actually you gave like an answer. It was just a chat bot. Right. Like how did. Like when you are saying just a chatbot, what does that mean? **[1:20:53] Speaker A:** So they got the UI from a regular chat? Yes. Person to person chat. **[1:21:02] Speaker A:** Is it working or. **[1:21:09] Speaker A:** We don't need the. Maybe the monitor for the live streaming? **[1:21:15] Speaker D:** Yeah, **[1:21:15] Speaker A:** it's like I don't need it much because it's going to be mostly discussion. Yeah. **[1:21:25] Speaker A:** So you are saying that they got it, they mimicked the person to person chat, Right? Okay, that's a good start. Yeah. So I would say that the **[1:21:34] Speaker B:** major difference point between where ChatGPT was at the technique and Google started rather further is because Google already had a search inquiry engine in place and they already had all the data. **[1:21:45] Speaker B:** The major part in an AI system when it comes about is the data. OpenAI had no access to this public information repository and all that. So they had to train it slowly. And that's why like he said, it started with just one instance, 2021, 2022 and they had to train over there with millions of users and their information. Google already had the data. So what they could do is now they added the search for agent to end AI thinking platform and what this AI would do is now just it. Similarly like a search inquiry box of original Google it retrieves the information when the user types prompt but it also adds an analysis layer on top of it where it thinks over that information and tries and gives an alternate output. So that's what your Google AI, the top section of any search and figma that's just basically analyzing the same search query over multiple websites and giving you a **[1:22:32] Speaker A:** summary. Yeah. **[1:22:33] Speaker A:** So you are saying that they were already ahead. Google, they were already ahead. But like I don't want to drift the conversation. Like you gave like valuable information and like insights there. But you are talking about these three here. **[1:22:47] Speaker A:** Actually these two design and development, like for ChatGPT they were early stages, just they mimic the person to person chat and they had this chatbot then even chatbots they were there, even not advanced, but they were there. So they mimicked that. And for Google they had the information retrieval part then. Actually my point was a higher view of what you were like you were hardcore software Developers talking about design and development. But my question was about the usability of the software, if I can use this term here. **[1:23:21] Speaker A:** The ChatGPT, they started from scratch. They tried to provide something for their users. Okay, so they needed to analyze the requirements, right. Then they got, they said, okay, maybe the people are already used to chat bots and person to person chat, so let's have this ui. So they got this from this phase from the requirement analysis for Google. **[1:23:47] Speaker A:** It was very challenging. Why is that? I'm not talking about the development part. They were way ahead. Yeah, that's why they quickly caught up from the system part, but from the software development life cycle part. Like the usability part is we got our customers already trained and used to this UI and we want to provide them with this AI service. How should we provide them with that? Just like maybe two years ago it was a research problem, it's still a research problem. So what they did, you can answer me, but just like I want to. So if you open Google, it's the usual one, right. **[1:24:36] Speaker A:** Then they added that, see that, that feature, it took them I think 18 months. I'm not sure about the exact information, But I think 18 months of requirement analysis. Just this simple feature here, that's my introduction. **[1:24:57] Speaker A:** And it's not straightforward actually to put it here. Some thoughts were just change the whole thing and have a new interface similar to what we got, like Claude and chatgpt, some of them. And the winner was that I'm already used to that and it's kind of predicted or predictable, I should say, to stick to the original ui. After analyzing the requirements they gathered from their customer base or their users and they added this feature here. All of this is actually a discipline by itself, like paradigm, sub discipline in software engineering, which is requirement engineering. Now what does it mean, requirement analysis? That's the definition, a standardized definition here. **[1:25:53] Speaker A:** Human to work completed by all stakeholders. What does it mean? Stakeholders? Already talked about that. Stakeholders. **[1:26:01] Speaker A:** Simple, plain English. Anyone? Sorry. **[1:26:08] Speaker A:** Yeah, that's more specific. But this is 80% of it. Actually it's 100% of it, but you can simplify it. Anyone who has a stake in that software. So it could be software developers, users, investors. **[1:26:30] Speaker A:** Right. If it's a big company, like the employees in that company. Right. So these. So the requirement is agreement to work by all the stakeholders. **[1:26:45] Speaker A:** This is a bit generic. So it needs to be unfolded because all the stakeholders, some of them are more important than others. Right. **[1:27:03] Speaker A:** Now why is it important to do this requirement analysis? Why didn't these Google engineers just Added that feature in a way or another and not spending 18 months to do that. Why is that you can cheat from these. **[1:27:24] Speaker A:** You know, what was the stake if Google messed up with this analysis and they are still at risk. People are migrating from using Google to using AI, right? That's why they are trying to improve their AI services. Like. Like what? **[1:27:45] Speaker A:** Anyone using Google AI services. Gemini. Okay, this takes me. Yeah, You use Gemini. Yeah, that's actually my next question. **[1:28:02] Speaker A:** Why do you prefer Gemini than ChatGPT or why you prefer Claude than ChatGPT or Gemini? Why is that? All of these are requirements actually. Why? Can you tell me why? Just like **[1:28:17] Speaker B:** so with Google AI it's, I think it's the least friction because when you, when you say in terms of user friction, they spent months trying to tell everyone don't use Google. If you want any, any answer in the world, shift over to chatgpt.com and ask us then the minute Google added that feature, future now people can go back to using Google how they were for hundreds of years, but they also get AI in the same platform. So you're getting these user fiction by Google AI. And also when you compare Gemini and ChatGPT models, Gemini over my usage decent gives me more accurate results over time than ChatGPT. **[1:28:55] Speaker B:** So I guess both of those features. **[1:28:59] Speaker A:** Yeah, actually I can go and answer you from the other side of the fence. Like Chat GPT guys, they used to have a deadline like up to December 2022. All of the information we got is not up to date. Then they improved it to catch up with what's happening with Google because like when they released their services it was a very powerful chatbot, but still if I need up to date information I wouldn't get it. So people still using Google and they thought that okay, they were safe but when they chatgpt they knew that this is competing with them and they improved that by the analysis of the requirement of their customer base of their users. **[1:29:41] Speaker A:** So they had that and Google became at risk and they are improving that. See all of this comes back to the requirements of your stakeholders or users mainly. Now how can you capture gather the requirements? That's the question. So I'll jump from these two examples of AI services to your project and iteration too. **[1:30:05] Speaker A:** You got. Did you find my interview with Ronnie? Is it there? **[1:30:14] Speaker A:** So there will be an interview if it's not released, it's going to be released maybe by Thursday's lecture. I think Ronnie or Amba will be here and they will release that. It's just I was Talking in plain English about what I want from your project, from your software, from your back end. And you need to capture that, that's part of your iteration. Two projects. **[1:30:44] Speaker A:** Okay, so how can you capture that? One way is that interview with me. Then you need to take get insights from my plain English interview to the input that you need to add to your software. So I will be using it. Okay, look at this. **[1:31:11] Speaker A:** Requirements. These are requirements, right? **[1:31:16] Speaker A:** Which one of them is good, which one is bad? **[1:31:21] Speaker A:** There has to be a way to authenticate. I want to build a support system with live chat help and case management. I want to store users Facebook ID in the database. I want to view a chart that shows a percentage of time spent on particular websites. **[1:31:44] Speaker A:** Which one is good, which one is bad? **[1:31:53] Speaker A:** To me all of them are bad. **[1:31:57] Speaker A:** But that's what you get unfortunately. And you're gonna see in that interview when you go like you work as a software developer and you want to get requirements from maybe one of your friends comes to you and can you help me build an app? Vibe code an app to do such and such. So you get it in plain English, right? You get these initial requirements, then you want to add more and more, gather more and more requirements to build your software. **[1:32:27] Speaker A:** Usually when you get that it's plain English ambiguous sometimes. How can you transform it to something that you can rely on and start the software development lifecycle? Look at these winners here. Worst requirements. It has to be robust, easy to use, make it accessible, reporting just one word, you get it from your friend. **[1:33:02] Speaker A:** The system has to be bug free. Of course, we all want that. So this is an information free sentence, round the clock availability. All of these like are obvious, right? Response time should be less than X seconds. Well, this is challenging and it seems a bit sophisticated and maybe measurable, but still it's bad. That's the winner. The system must have good usability. Yeah, we know that. Otherwise we'll not be using it, right? **[1:33:40] Speaker A:** We tried here to define a good statement for requirements. **[1:33:49] Speaker A:** Maybe you can see these three. So why I'm talking about requirement analysis and requirement gathering because you get it in a very. Let's put maybe just use raw form, just raw form, just plain English ambiguous. Like these. Then you have to transform it, rewrite it in this like following these rules. **[1:34:14] Speaker A:** Look at this statement here. The online banking system shall allow the Internet, I think I never used Chal. Maybe 10 times, 20 times in my lifetime shall allow the Internet user to access her current account balance in less than five seconds. What do you think of this one? Compared to what we just saw here, this is English, but very far from the English that we use to communicate, right? **[1:34:45] Speaker A:** So there is a gap that you need to bridge. You get the requirements, you try to rewrite it in a formal way. And the like, the more effort you spend on that, the easier for you later to like to and the faster for you to move forward with the SDLC later. **[1:35:05] Speaker A:** The design and the development now functional and non functional. Well I spend like good part of my life research using these two terms. **[1:35:21] Speaker A:** What does functional and non functional? Reading this and just from what you understand, like English functional, no function, function requirement, non functional requirement. **[1:35:38] Speaker A:** What do you understand from that? **[1:35:42] Speaker A:** This is a bit academic and fancy. I'm going to give you an example that one of my supervisors gave me when I started doing research in software engineering. Engineering the functional and non functional requirements. He said like imagine that. Give me two examples. One example, imagine that you are going to a doctor. So what's the reason that made you go to a doctor? **[1:36:17] Speaker A:** Right, sick. The doctor can help me get antibiotics, for example, right? So the doctor has a function that I needed. Now imagine that I have three or four doctors. Which one I should go to? **[1:36:38] Speaker A:** Dr. A. If I go, I need maybe to wait for four days. Dr. B is available the same day, Dr. C cheaper, like to go and pay, it's cheap. So this is the non functional requirement. See the difference between functional and non functional. I need the function that the doctor provides which is gives me a prescription to get antibiotics. All of them, the four of them can provide that. That's the functional part. The non functional part is like how can I different compare between them? Okay, faster, cheaper, available the same day after four days, very good reputation. **[1:37:23] Speaker A:** So these are the non functional. That's the first example. The second example is I want to take. Listen to this and like it's ridiculous but I want to take a flight. Is this complete sentence in English? **[1:37:47] Speaker A:** Just take a flight or go in somewhere. Take a flight to Perth or. **[1:37:56] Speaker A:** So where's the functional part here? And the non functional part **[1:38:05] Speaker B:** is taking a flight. **[1:38:11] Speaker A:** Apply the doctor analogy. But you can apply the other way around, right? Like I'm going to Perth, not going anywhere else, I'm going to Perth. Then I'm taking this flight. I can take maybe my car, right? **[1:38:26] Speaker A:** I can take a flight. Well in Australia you can. It takes forever to reach there. But I chose the option of so which one is functional and which one is non functional? **[1:38:42] Speaker A:** So the functional is like if I use your term, it's the non negotiable part. It's the part that you need, the function that you need the non functional part. It makes you compare between multiple like services that provide this function. If it makes sense. I'm just trying to simplify it for you here. **[1:39:10] Speaker A:** Okay, This is a breakdown of the non functional part. **[1:39:24] Speaker A:** Product requirement, organizational requirement, external requirements. I can think of, you know like some countries they have the like think of a car, car company, let's, I don't know, Holden, Ford, so they export their cars, right? **[1:39:51] Speaker A:** But when Australia gets or receives cars from let's say overseas the government has very strict regulations about environment. Is this a requirement? **[1:40:09] Speaker A:** It's a requirement and the government needs to respect these standards. So these are requirements. Where does it fall? Is it product requirement, organizational or external requirement? **[1:40:25] Speaker A:** Who is going to use the car? Who is going. So if you think of it, it's who's the manufacturer of the car, the user of the car. Then you have the government that's imposing that it's external agency. The government imposes this requirement that you have to respect as a car manufacturer. **[1:40:43] Speaker A:** Right. Now let's think of an example of organizational requirements. So you are providing like B2B service, a service to a business, like an app to businesses. And one of the requirements is like all of my users or all of my employees should be able to log in to that software. So this is imposed by the organization. **[1:41:12] Speaker A:** Another requirement could be all of the data of my company should be on prem, should not go to the cloud. That's what's happening these days actually that's an area where you can find jobs. In the next maybe two years everybody can use the cloud services, the NEO cloud services, the available AI services over the cloud. But if I want my AI to be on prem, so this is an organizational requirement that I have to respect. So it puts more challenges to building my AI software product requirement. Now I think all the rest is product requirement. **[1:41:56] Speaker A:** If we take the car example, like the manufacturing cars and the product is car. So what could be a product requirement? **[1:42:11] Speaker A:** You can take this example, you can copy from it a product requirement, something that's linked to the product. Maybe you can impose size, weight, something I don't know, like some specific features, options. **[1:42:31] Speaker A:** Is it clear? The functional, non functional part. Because like I want to end it with this. So you have this hierarchy here. It's more breakdown to these like product and organizational and external. **[1:42:46] Speaker A:** I think we provided you with quizzes like you have these questions, quizzes, you can, you can go and practice that. So next week what we will do I will quickly try to summarize the steps of requirement analysis and take it from there to conceptual modeling. Because, like, if you look at the sdlc. So what I'm going to do. **[1:43:15] Speaker A:** Try to summarize. Sorry, here. This part. So summarize the design part and take it as a segue to the. The requirement gathering part as a segue to the design part. That's what we will do. But before that, what, what? We will see iteration two. Hopefully, we'll have one hour on that. Like, one of the admin team members is going to do that, and the second part is going to be the author. **[1:43:43] Speaker A:** So we're going to see iteration 2 auth, then resume with requirement and conceptual modeling. That's it. Thank you, everyone. If you have questions, I'll be here for the next five minutes. You can come and ask me. Thanks, Sam.