Today we're going to carry on our little video series on the microcontroller exams and look at the specifications specifically for the taxi calculator a client brief that we looked at in the last video. If you didn't see that you should be able to see a link to it at the top of the screen now. Today we're going to be building on what we looked at there, looking at the brief and then building a specification from that.
First of all it's probably a good idea to have a quick look at what we do for a specification and here's what the exam says. It says by interpreting the client brief as operational requirements prepare a technical specification for a user-friendly system that can handle some unexpected events. And for this, we probably want to have eight bullet points for the specification, or more if we can. If we can put more points in, that's good.
But I think a minimum of eight is a good kind of barrier to have for this. the specification. The points should also have detail and this is really important and we'll come back onto it a little bit later on but just having a few words for a point isn't going to be enough to get the highest marks. To get the good marks we need to have some good detail in the specification points.
Finally it does say in the little overview there but we need to have some comments on unexpected events and these unexpected events are needed for the very highest marks. marks to get the top level of marks in the specification and they come up time and again throughout the exam so getting to grips with them is really really important and again I'll come on to them a little bit later later in the video First things first, we need to have a look at the client brief and this is the one that we looked at last time. We went in a little bit more detail last time and kind of had a read through about what it was saying. And the first job is to convert this client brief, the instructions from the client, into a specification. I think a good place to start is by looking at where we have some numbers in the client brief and I picked up a few of them here where you can see we've got some costs and some times and things like that but usually 95% the time or so you're gonna to have the numbers are going to be giving you some instructions as to exactly what the device is supposed to do we also have some other points so i've highlighted one here uh it's not a number obviously but it does say that the device has to be simple to operate so you need to factor that in when you're coming up with your specification points and you've really got to go through the whole thing and to be honest when you're going through you're not looking for points that you need to put into the specifications so much as looking for things that you don't want to include because the material majority of the client brief is going to be included in the specification in some way but you do have the odd little bit like here it says that they've deployed new taxis in all the major cities around the uk and there will be kind of superfluous passages within the which you don't need to put in the specification, but really you need to be arguing to keep something out of the specification rather than trying to find things to put in.
And there's lots and lots of things in the brief here that you could include in the specification, and you just need to make sure you're including them all. You get marks on how much of the specification you cover and how many things that you cover. If you start missing things out, you will be losing marks, which is obviously what we need to not be doing. So once you've found all of the points that you need to write the specification for, we need to go about starting to write the specification itself, and we need to write those eight or more points to it. What I often see when I'm looking at specifications is where people have just come up with a very basic specification with some quite simple bullet points.
I've just done four here. Obviously, you can have more than this and still wouldn't quite be there. But we've got some very basic specification points. The device should track the cost of the fare.
The device should charge 25 pence per 20 second duration and an initial fee of £1.50. The driver should be able to pause the calculator and the driver should be able to add discounts and surcharges. And you could put another few in like that. And to be.
To be honest, this isn't a really bad specification. It's fine, it would get a passing grade probably, but we're not really looking to get a passing grade. We want to get a bit more detail into these points to get the highest marks. So ... the way I would actually write one of these is I would give detail to all of my specification points and this might be a bit different to what you've came across before because often when you're writing a specification then your points need to be quite brief and to the point.
In this case that's not what the exam is looking for so we need to kind of put that to one side in our minds even if that's what we do elsewhere. For this the specification points need to have some good detail and need to have some reasoning behind them. To do that you need to extrapolate on what the point's there for, so instead of just giving a short sentence of what I need to do, we need to put a bit of context behind that and why we're going to do it and potentially how we're going to do that, even though that's something that we're really going to be covering later on in the hardware selection.
processes in activity 3 but for now we need to think about maximizing the marks and showing the examiner that we understand what the briefs asking us to do and to do that we need to get a lot of nice detail into the specification points. Here's an that I've written the driver should be able to add surcharges or discounts to the fare in case of extenuating circumstances with the fare such as a breakdown or similar. This should be simple to use whilst the car is in motion and you can see I've taken the initial point of the drive the driver should be able to add surcharges and discounts to the fare.
That would be fine by itself. It would get you a couple of marks in the specification if all your points were like that, but I've put a bit of context on it as to why that's a specification point and why we're talking about this. And we have also kind of elaborated on it a little bit and we've said that it needs to be simple to use whilst the car is in motion and all those types of things.
And this will get more marks. I'm not saying it's a perfect specification point, but it's a lot. better than the original one was so just make sure you're putting some context in there and thinking about the English that you're using making sure you're writing in a way that makes sense if you are aren't sure if it makes sense kind of read it to yourself silently and uh you know normally you'd probably read this out loud but you're going to be an exam conditions but if you're doing a mock or doing a practice feel free to read it to yourself out loud and just listen to how it sounds and i find that's a really good way just to make sure that it makes sense you know if somebody described that to you would it make sense to you The other thing that we need to look at when we're doing these specification points is unexpected events and unexpected events are needed for the highest marks in not just a specification in a few other points throughout the exam as well and we'll come to that when we come to those different activities throughout the exam.
What the unexpected events are there for is preparing for things that aren't supposed to happen. So for example we could have a user error so the user presses the wrong button at the wrong time so presses a button say for the surcharge before the timer has even started before the calculations even started or something like that obviously depending on the depending on the device that we're building it would be different things and another example could be a power cut this is more something that i think i would use when where we might have a number of different things so it could be like an alarm system if there's a power cut when the power comes back on does the alarm start up right away if it's something that users using quite a lot then it doesn't really matter about a power cut because if they can like set the device up again but if you think you know you've got an alarm on a computer in an office and all the computers in the office have the alarm what you don't want to be doing is if there's a power cut going right round around all the computers in the office and reset the alarm on each one of those computers. Whereas if it was just a device that you're gonna be ready to use and you're gonna be handling it quite a lot, then a power cut isn't as big of a deal, in which case the user error is probably gonna be your better option.
Of course, again, you can have many more examples than just these two, but these are the first two that come to mind for me and these will work for almost any situation, either one of the two. Finally, in summary, the specification is going to be written from the brief. It'll be the first task that you do that is going to be different depending on what your brief is saying.
So the time plan stuff that you do at the start, that's going to be pretty much identical every single time. But this is going to be the first thing which is going to depend on what's being asked of you. And it does help you understand the requirements of the brief that you're given. You need at least eight points here, and I think this is really important. It's a good, solid number to kind of write around, but you should have at least eight points, and this will help you cover all of the things that are in the brief.
If you can think of more, of course that's fine, but at least eight points is kind of the minimum point we should be looking at. The points should be detailed and have context with them. Just having a short point, a little bit like the points that I've put on screen here, isn't enough for this brief, even though we might have done that in other specifications before. It's not what we should be doing in this exam. And you really need a few lines with some context and reason behind it to get the most marks out of what we're doing.
And that's pretty much it. I'll be doing the next video on the test plan, the other part of activity two, and that should be coming out the next day or so. And then as we go forward, we'll be looking at the different... parts of activity three we're looking at some of the programming looking at the different parts of annotating the code and then looking at the test plan again at the end we're going right the way through the process with this particular client brief again if you want to make sure you're going to be kept up to date with those videos as they come out and they'll be coming out with quite a high frequency over the next few days then i suggest that you give us a like give us subscribe and do the bell notification thing just like you do with all your favorite youtube channels thanks again for watching and I hope to see you again with the next video