 In the previous video, we understood the importance of design comprehension and how experienced designers comprehend a given design. We also interacted with the Verisim learning environment. Verisim helped us understand how to comprehend a given design by tracing various scenarios in the design. Okay, so we have modeled, created a design, comprehended and now we also have an integrated understanding of the design. Yes, along with comprehending a design, we also have to evaluate whether the design is correct. Design is correct? In what sense? Can you help me understand this with an example? Yes, let's take an example from a non-software context. It might help us understand the concept better. Let's say that you are paying money for a Tiffin service which provides you with three meals, breakfast, lunch and dinner every day. So what are different scenarios for which you will not be satisfied with the Tiffin service? You can pause this video, write down your responses and then proceed. So the first thing is that I want my food to be delivered on time and I don't want any mix ups happening. For example, the service shouldn't be giving me breakfast for lunch. Yes, exactly. So what you actually mentioned now, these are the basic requirements, right? The Tiffin service should make sure that these basic requirements are satisfied. This is known as correctness. Okay, so going back to the software design context, we need to ensure the correctness of the design. We make sure the design satisfies all the requirements. We can say that the design is correct in some sense. Yes, you're right. When you check for correctness, you ensure that the design satisfies all that your system should do. Correctness is the extent to which a program behaves according to its specification. Learners, this is what you did in verisim as well. Using design tracing, you checked whether various scenarios in the design correctly satisfied all the requirements of the automated door locking system. Correctness is one of the functional requirements of the system. Functional requirements describe what the system should do. We need to ensure that all the functional requirements are satisfied by the design. The functional requirements are satisfied is one way to evaluate the given design. But isn't the only way? Are there other perspectives we need to consider while evaluating a given design? Yes, there are several other ways to evaluate a software design. It is necessary to evaluate a design against various quality attributes. Quality attributes? Can you help me understand this with an example? Yes, let us go back to the defense service example. What else do you expect from the defense service? Okay, next, I want the service to be reliable. For example, if I miss more than 3 meals a week, I wouldn't be happy. Exactly. This is termed as reliability. Reliability is the extent to which a program behaves the same way over time in the same operating environment. In case of software, we need to ensure that it doesn't crash often. Otherwise, users will get frustrated. For example, in a mobile wallet like Amazon Pay, reliability is even more important. We must ensure that the wallet reliably handles all operations, especially important operations like withdrawal and deposit. I also want the service to handle unexpected situations reasonably well. For example, if the main chef falls safe, is there a replacement? Is there any other option to serve the customers? Okay, so this is similar to the quality attribute of being robust even in unexpected situations. Robustness is the extent to which a program can recover from errors or unexpected input. For example, in a mobile wallet system like Amazon Pay, we have to ensure that the service handles unexpected input like negative numbers and large numbers and high traffic as well. So, while checking for quality attributes like reliability and robustness, we are in a way checking how the system is behaving and not exactly checking the system requirements. So, are these quality attributes different from the functional requirements of the system? Yes, you are right. Attributes like reliability and robustness are known as the non-functional requirements of the system. Non-functional requirements essentially specify how the system should behave. For example, we looked at two non-functional requirements, reliability and robustness. Okay, so functional and non-functional requirements have to be considered while designing, creating and evaluating the system. Yes, you are right. To summarize, in this video, we discussed functional and non-functional requirements. There are other non-functional requirements such as performance, portability, security and so on. Do check out the additional resources for more information.