[MUSIC] Module 1, Lesson 1, Lecture Lecture 1.2, Design Process. So we'll start talking about the overall design process, a very generic form of design process. Because a lot of this project, this capstone project, what you'll have to turn in is evidence that you have a design process and what your design process was. So we'll talk about the design process right now. [COUGH] So, the design process. Here's a very generic view of a design process. By the way, when you talk about design processes, there's a lot of work, and different processes that can be used. Especially in software engineering, I do software engineering too. There are lots of different methodologies. You can have a course just on processes and different design processes and what are used in all this. What I'm showing you here is very generic but it gets across the key elements you're going to find in any process. Okay. So this is a safe bet, what I'm showing here. There's no everything sort of fits into this. So the process starts off, you make a requirement specification. So right there you're writing a document that defines what you want out of this system, what it's supposed to do. You need to start off with something like that and it is best if you formalize that in some type of a natural language document, or rather specifically English document, because that's all that, I would say English only just for grading purposes. I don't care if it's English but you know other people are going to have to grade this. English is the langue we're using in the class, so. Now once you have the requirement specification, you know what you want to build, then you going to synthesize alternatives. So there's this design space exploration that goes on, where you think of different alternatives and you synthesize them. Now when I say synthesize, that doesn't mean completely finish the design but you at least partially synthesize them. So you can get some notion of how well they work. Then with these design alternatives that you synthesize, or partially synthesize, you analyze those alternatives. So you have all these options, you analyze which ones best, which ones worse. And then eventually, you choose one of these alternatives. And then you finish the design, right. So you complete it. What this is really getting across is there has to be this design space exploration, where there are alternatives, and you are synthesizing them and evaluating those alternatives. And then you're going to choose alternatives, and then complete your design, okay. So that's all I'm trying to say in this very generic picture. But that's gotta be going on in your process. And it starts of with this requirements specifications document that we got at the beginning. So, let's talk about requirements specification. It needs to define the behavior of the system. How the system acts. How a user interacts with the system. Not the implementation, so you don't want to be talking about how it's going to be built. You just want talk that separates behavior for it's implementation, at this stage. Eventually when you start getting more into design you will. Think about how to implement it right? But right now when you're making the specification implementation is not part of it just the behavior. Now specifications generally need to be understood by multiple constituents okay? We're going to talk really about two sets of constituents. First the user right? So somebody who is using this device they need to be able to look at this specification and understand what it's supposed to do and how they're supposed to use it. So, that should be a goal when you're writing a specification that a user, somebody who is not an expert in design, that user could look at this and say okay I see what this is supposed to do and I like it or I don't like it, so that's one goal. Somebody who from the outside should be able to look at this and understand it. Now another thing is that, another goal here is that a designer should be able to understand it. So in some sense the user is looking top down, from the outside, the users looking saying, what is this going to do for me? Right? But on the other hand This design specification, requirement specification will be used by designers to actually design and implement the rest of the system. Now a designer is somebody who is clearly knowledgeable in design, is going to actually perform the design, right. Now in our example, this is going to be you. In general, when you write a specification, these specifications get handed off to another design group, who goes off and designs it. So, it's got to be useful to a designer, when they're making their design, and choosing different design options. They have to be able to say, look, does this option. Does this satisfy the goal stated in the specification. Does it do what the specification does. So they have to be able to evaluate their design options by comparing it to what is stated in that specification. So in order to make it useful to the designer, it's got to completely describe the behavior. So if the specification has parts of the behavior that are not described, then the designer doesn't know what to do. Right? The designer might say well what do I do in this case? If somebody presses button X instead of button Y, what happens right? So this the specification needs to specify it the behavior fully so the designer can know what they're they need to implement. Also look for rare cases. You know uncommon cases need to be stated in the specification. Now you know these systems, these kinds of designs, won't be that complicated so there shouldn't be really weird cases but in general when you're making specifications from say more complicated systems you got to completely specify the behavior you don't want to leave things out if you do now sometimes I should mention sometimes when you write a specification you do intentionally leave things vague. But that's because you don't want to over specify design. So basically you might leave vagueness if you don't care what happens in those cases. But in that case, when you're being vague you should state that in the specification. Say, it is not important what happens when X is pressed after Y. That is not a part of this specification. So we know that is an intentional vagueness, something that is intentionally left out as opposed to something that you accidentally forgot to put into the document. Right? So you should specify everything. And if there's something you don't want to specify, because you don't care about that behavior, then you should say that. Just so that the designer knows, okay, it doesn't matter what I do. Now another thing that you need to put into the, you need to consider when you're writing the specification, are the real world constraints. So I'm referring to these as a non-engineering constraints. I don't know what a good term is but these are constraints that I see as the business constraints, okay?. As an engineer, so I'm the engineer, right? If I'm working at a company, they give me a design, and maybe I negotiate on the details of the spec and stuff like this, but basically my job is to design this. I'm not really telling them. There are certain higher level ideals that I'm less involved in, okay? Engineers have to consider some of these things, so let's go through some of these things. One is existing expertise now actually this is a really important thing in practice in a company setting. When you're trying to figure out what design option to use. Should I design it using this board or that board. Do we know our Raspberry Pi or some other board. I could use Arduino as my control I can use Raspberry Pi or I can use board X. Board X might be cheaper and better than Arduino and Raspberry Pi, but since Arduino and Raspberry Pi are what we covered in this class, it would probably be a lot easier here for you to use Arduino and Raspberry Pi. So there is a very good chance that because your existing expertise is Arduino and Raspberry Pi, you will use Arduino and Raspberry Pi because you know you can meet your deadlines that way, right? Where if you go to Board X, it's cheaper, looks nice, but you don't know for sure if you'll be able to complete the design because it's a risk, it's something new. So existing expertise is a serious consideration because companies always need to meet these deadlines for completing their design. It's always safer if they do what they already done, right? If they use their existing expertise rather than try to do something new. Now, that's how it is in practise in companies. For you, you are students right? This is a class. So usually when I'm telling students how to make these projects. I'm more free with this, right? Because in school, generally you don't want to be locked into your existing expertise. In fact, the point of school is so that you gain new expertise, right? So often, I will tell students look try something new, it might be better, so you can learn about this. Now once you get a company than, you know, then you're stuck. You gotta meet those deadlines and maybe you don't have time to learn new things. Of course, I would say in the long term, you want to learn new things anyway because the market changes all the time. You need to be more learning all the time. So don't necessarily limit yourself into existing expertise, but it definitely has to be considered because you have to meet deadlines. Competing designs and patents, now of course we are not going to worry about that here. But if you're a company, you don't want to put out a product that already exists, right? Or you don't want to put out a product that uses some feature that's already patented because then you have to pay for the patent. Or if you are going to use that feature then you better know it so you can pay for the patent. So okay, the financial limitations, and actually, this is important to you, too, how much money do you have, right? If, especially if you're going to implement this, you need to have a money limit, I'm only going to spend this much money. And that is a tight limit, okay. That's a constraint that you always have. And you have to consider that in the specification, too. So all these issues have to be, if they exist, if there are issues, they have to be brought up in the specification, or should be. Legal restrictions, there are legal restrictions on some devices so for instance Quadcopters now as of very recently they need to be licensed in order to be flown so in the US anyway so you need to go and pay it's not expensive as an individual it doesn't cost much five bucks but it needs to be done and so you have to talk about these types of restrictions. And there are restrictions on different devices. Maybe you're making a high-powered device and you don't want it to be dangerous. It shouldn't violate whatever restrictions that whatever regulating agency has, so you need to be aware of those. About I don't expect that to be much of an issue for your carson design projects in practice though. Existing design and manufacturing processes and actually this goes to existing expertise this is a similar thing. Sometimes you know there are manufacturing processes that you are stuck with. It's the same as the existing expertise. You can change your design process but if everybody at your company is using Agile for agile design process for the software that probably you need to use the same thing, your boss is going to want to use the same thing, to make everything more easy to work with together. So if there's an existing design process you may have to adhere to that. That isn't so much of an issue for this project right? Because you're making this up as you go. And the manufacturing process is whatever you can afford, right so this is less of a limitation with your projects, thank you. [MUSIC]
