Specifications & testing

This week, the main team assignment will be working out the draft specifications along with a testing plan for your system.

Set up specification document

In your Team Google Drive, set up a folder for your system. Create a Google Doc for "Specifications". As we've said in class, the most important things are to 1) have a plan, and 2) write down your specifications. Your specifications should be written such that if you meet them, you automatically meet the system requirements. That's what we're doing here.

The format of your specifications document is up to you, but we strongly recommend following the sections laid out in Lecture and in the MAQS project. The specifications for the HW, SW, server, and FW subsections may take different forms (a list, table, wireframe, diagram, etc.). Do what makes sense!

For each concept, start filling in specifications, including ones you can set now and ones you don't know.

Testing & Verification

For each specifcation, create a plan for how you will test, or verify, that your system is meeting that specification.

To give an idea of what's involved here, let's consider a couple of likely specifications. For example, we have a requirement about surviving outdoors in Boston and Miami. So you may decide that your enclosure must meet an IP rating of 65. Now, how will you test that it meets this? Luckily, there are established tests for different IP ratings, but how will you implement them here at MIT? Will you use just the enclosure? Or the enclosure with functioning electronics inside? How will you determine success or failure? All things to consider.

As another example, you will need to estimate occupancy. Let's say you want to estimate occupancy to within 20% accuracy, with a time resolution of 1 minute (I made these up, don't necessarily copy them!) How will you test that? Will you put the system outside somewhere? Or inside? How will you determine the accuracy? Will you have someone sit there and watch and manually count the number of people? Mount a camera (sketchy...)? Something else? If you are only testing the system for a short duration, then how do you know if works under multiple scenarios (individuals, a crowd, in the rain, etc.).

Coming up with the testing plan will be at least, or likely more work than the specifications!

Questions that need answering

In a separate section or separate document, list questions that need answering for your system. Each question should have a plan associated with it for answering that question.

Some questions need answering by the staff or partners. Questions to the staff can be asked on Piazza or at the Wednesday lab meetings.

Other questions may need market research, or modeling. This is part of what you'll be doing prior to the first presentations on February 28.

Other questions can be answered by fast prototyping. We have a bunch of parts that you can take advantage of if you want to test something out for the HW node. If there's something that you want that we don't have, ask and we can maybe order it.

Team roles

Most of the technical team roles will be decided for the first set of presentations. But there are other roles that need to be decided now: See the project page, and create a document for "Team Roles" and write down who will be the Note-taker, Orderer, and Mentor Liaison.

Functional system diagram

Create and update your system diagram along with your specifications and testing plan. These are all dynamic documents! As you go along over the next few weeks, these diagrams will be updated, refined, and revised.