[MUSIC] Here I'll go through a specification example, a requirement specification example. I'll go through one good one and a couple of weaker ones. And just talk about what's wrong with the weak ones and why they're not so good and try to give you an idea of what I expect. Okay, so let's talk about a soda machine. So, we got a picture of a soda machine. Here's a really basic specification. I can't give a whole specification here because that's a long document, but here's the idea. So it's a machine, it has a coin slot, a soda button. A soda dispensing slot, a change return slot. Actually, according to the picture there's probably more than one button, but that's okay. Change return slot. Coins are inserted into the coin slot and if soda button is pressed and enough money has been deposited then a soda is dispensed and change is returned. So this is giving us our base specification on how it works. And this is pretty good. It's mostly complete, not completely complete, there are little details and the behavior there probably left out. Like for instance, if you'd ever used a soda machine, you can put in a few coins and you can press a button and they'll all come out without you even buying a soda, right, if you change your mind or something. So that's not in there but this mostly describes the behavior. It describes the user interface for the users. So the user can understand from reading this and from looking at the picture, the picture is useful, by the way. Looking at the picture, okay, I basically get the idea of what this is. Some behaviors are not explicit, like if you put in the coins and you press the coin return button without pressing a soda button, that's not actually explicitly stated there. But this is pretty good. Now, you might want to add in the extra details about what happens in the other cases, but this is pretty good. Okay, so, another soda machine specification. So this one is much shorter. Insert some money, press a button, get a soda. Now, why is this weak? It's less detailed, right? So it leaves out a lot of details. Now leave out details in general is, some details it is okay to leave out. But you have to be very careful about this. I would say leave out very few details but in practice, sometimes you leave out details, because if you put every detail in there, the specification can get very long. And sometimes some details are not necessary. So for instance, if we talk about a soda machine, and everybody has already used a soda machine, now this is assuming everybody has already used a soda machine. But everybody I know has used a soda machine and basically knows how they work. So, in a situation like that where everybody already knows how they work, then why give all the details of exactly how it works, right? Just give the key details and move on. Now the difficulty with this is, you're assuming everybody's background. You're assuming everybody uses soda machines that basically work the same way. And that happens, people do that a lot, but that is not necessarily right. And actually this course might be a good example. This course, people view this course worldwide. Most people who look at this course are not in the US. And I don't know what soda machines are like in different parts of the world, not for sure. I've never been to India, I don't know what soda machines are exactly like there, right? Maybe they are different sort of machines because they are different vendors, right? So I may make some assumption and you, say you're in India, and you look at my specification, you may make a different assumption because my specification is not complete and then the design is wrong. This is the source of a lot of errors, okay? So when you assume background knowledge, you have to be sure. In fact, I remember an example where I saw this was with traffic lights, okay? In the US, everybody knows what a traffic light does, red, yellow, green and you know how basically they work and how they cycle. So one time I went to Shanghai, right? And I was driving through there, I was in a taxi, I did not drive. The driving is different there all right, I didn't want to do it but the taxi driver, he was driving. As I'm watching, we get to a light and it's a very long red okay, so he's sitting there forever. And then normally after, in the US anyway, after a red, you expect a green signal right, eventually. Instead what happened was it went from red to yellow, all right? And then it was like a red yellow and then it was green. And I remember thinking, what is going on here? It seemed like to me, this yellow phase, I think somebody told me that the idea behind that yellow was that red is such a long red that people shut their engines off. Yellow is a hint, okay, we're about to to turn green so turn on your engine again. I think that's what somebody told me. Now I don't think this happens in every light in Shanghai. But this happened at this light, and this is one of those things that you can easily miss. If I think okay, I'm going to write a specification for a traffic light controller here in the US and I don't specify the light sequence because I'm thinking everybody knows light sequences are the same everywhere. Then that traffic light controller is sold in Shanghai, I might be in trouble, right? Or vice versa, if a Shanghai traffic light controller is sold in the US, there might be trouble because people had different understandings of the specification. Okay, so this is a weak specification because it leaves out a lot of detail. Now here's another one, insert money, press button, get soda. It adds a little more of those. It says, okay. We're going to use an Arduino to connect to a coin sensor to track the money, to count how much has been inserted. And then we're going to have the same Arduino will connect to a server to dispense the soda. So maybe there's a motor in there that moves a lever and then the soda comes out. So we've decided, look, we're going to use an Arduino to do the control system. That's inside the specification so the problem with this, and also Arduino is going to give change. So it's connected to a coin dispenser to release change. It computes the change and it releases the change. So this is bad because it's over-specified. We're giving implementation detail. We're saying look we're going to use an Arduino to do this, right? So, that's not necessary, right? In the specification and requirement specification, we don't want to talk at that level of detail, we just want to say what the behavior is and leave it later to the designer to decide do I want an Arduino or do I want Raspberry Pi, or do I want this or that. Thank you. [MUSIC]
