1.3 - Specification Example

Loading...

En provenance du cours de University of California, Irvine

Programming for the Internet of Things Project

371 notes

University of California, Irvine

Programming for the Internet of Things Project

371 notes

Cours 6 sur 6 dans Specialization An Introduction to Programming the Internet of Things (IOT)

In this Capstone course, you will design a microcontroller-based embedded system. As an option, you can also build and test a system. The focus of your project will be to design the system so that it can be built on a low-cost budget for a real-world application. To complete this project you'll need to use all the skills you've learned in the course (programming microcontrollers, system design, interfacing, etc.). The project will include some core requirements, but leave room for your creativity in how you approach the project. In the end, you will produce a unique final project, suitable for showcasing to future potential employers. Note that for the three required assignments you do NOT need to purchase software and hardware to complete this course. There is an optional fourth assignment for students who wish to build and demonstrate their system using an Arduino or Raspberry Pi. Please also note that this course does not include discussion forums. Upon completing this course, you will be able to: 1. Write a requirements specification document 2. Create a system-level design 3. Explore design options 4. Create a test plan

À partir de la leçon

Capstone Design, Part 1

This module will assist you in selecting an idea for your Capstone project. There are many variables to consider in this decision so it's important to know the parameters and how they impact your choice. Your decision will then drive the content of the very first step in your Capstone project -- preparing a requirements specification.

1.1 - Deciding on a Project Idea8:10

1.2 - The Design Process11:06

1.3 - Specification Example6:17

Rencontrer les enseignants

Ian Harris
Professor
Department of Computer Science

[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]

Explorer notre catalogue

Rejoignez-nous gratuitement et obtenez des recommendations, des mises à jour et des offres personnalisées.

Coursera propose un accès universel à la meilleure formation au monde, en partenariat avec des universités et des organisations du plus haut niveau, pour proposer des cours en ligne.

© 2019 Coursera Inc. Tous droits réservés.

Télécharger dans l'App Store

Disponible sur Google Play