Requirements and Verification


Requirements: Requirements provide a technical definition of what each and every block in your system block diagram must be able to do. Each module in your system's block diagram should be associated with a set of requirements. If all requirements have been met for every module, you should have a fully functioning project. A good set of requirements should meet the following criteria.

Verification: Verifications are a set of procedures that you will use to verify that a requirement has been met. Every requirement should have a verification procedure associated with it. Good verification procedures will meet the following criteria.

Remember, a good R&V table should function like a debugging checklist.

Points Summary: At the time of demo, 50 points will be defined by the R&V table for your project. It is up to you to define how important each requirement is and how many points it will be worth. If your project is not fully functioning at the time of demo, these points will define how you will earn partial credit. If you do not provide a points summary or define one poorly (e.g., by giving too many points to a trivial requirement) the course staff reserve the right to define the points for your requirements without your input. The point summary should be organized as a table separate from the R&V table where the points are distributed across each functional block in your block diagram. Meeting the requirements for that block will then represent earning those points. If desired, you may define how many points each individual requirement is worth but this is not required.

This point allocation should initially be proposed by the students themselves with TA approval and finally instructor approval at DR. This point allocation must be printed and brought to the demo at the end of the semester. Changes must be approved by the instructor. Here is an example.


You can view example R&V tables in the sample Design Review documents: Good Sample DR and a Poor Sample DR. It is also helpful to examine the points summary example and a good example R&V table as it was presented in a final report.

A note about formatting: Requirements and Verification are best organized into a table and organized by functional block. If each module of your project has several requirements, you may want to create an R&V table for each block separately. Each row of your R&V table should have one requirement (in one column) and the corresponding verification procedure (in another column).

Submission and Deadlines

Requirements and Verification will be included in your Project Proposal, Design Review Document and you will receive feedback and suggestions for improvement. Changes to your R&V table made after design review must be approved by your TA. Changes made after Mock Demo will not be approved with the exception of extreme circumstances.

Unapproved changes to the R&V table that are presented at the Final Demo may be penalized up to 50 points (the total associated with R&V).


Aashish Kapur, Connor Lake, Scott Liu


Featured Project

# People

Scott Liu - sliu125

Connor Lake - crlake2

Aashish Kapur - askapur2

# Problem

Buses are scheduled inefficiently. Traditionally buses are scheduled in 10-30 minute intervals with no regard the the actual load of people at any given stop at a given time. This results in some buses being packed, and others empty.

# Solution Overview

Introducing the _BusPlan_: A network of smart detectors that actively survey the amount of people waiting at a bus stop to determine the ideal amount of buses at any given time and location.

To technically achieve this, the device will use a wifi chip to listen for probe requests from nearby wifi-devices (we assume to be closely correlated with the number of people). It will use a radio chip to mesh network with other nearby devices at other bus stops. For power the device will use a solar cell and Li-Ion battery.

With the existing mesh network, we also are considering hosting wifi at each deployed location. This might include media, advertisements, localized wifi (restricted to bus stops), weather forecasts, and much more.

# Solution Components

## Wifi Chip

- esp8266 to wake periodically and listen for wifi probe requests.

## Radio chip

- NRF24L01 chip to connect to nearby devices and send/receive data.

## Microcontroller

- Microcontroller (Atmel atmega328) to control the RF chip and the wifi chip. It also manages the caching and sending of data. After further research we may not need this microcontroller. We will attempt to use just the ens86606 chip and if we cannot successfully use the SPI interface, we will use the atmega as a middleman.

## Power Subsystem

- Solar panel that will convert solar power to electrical power

- Power regulator chip in charge of taking the power from the solar panel and charging a small battery with it

- Small Li-Ion battery to act as a buffer for shady moments and rainy days

## Software and Server

- Backend api to receive and store data in mongodb or mysql database

- Data visualization frontend

- Machine learning predictions (using LSTM model)

# Criteria for Success

- Successfully collect an accurate measurement of number of people at bus stops

- Use data to determine optimized bus deployment schedules.

- Use data to provide useful visualizations.

# Ethics and Safety

It is important to take into consideration the privacy aspect of users when collecting unique device tokens. We will make sure to follow the existing ethics guidelines established by IEEE and ACM.

There are several potential issues that might arise under very specific conditions: High temperature and harsh environment factors may make the Li-Ion batteries explode. Rainy or moist environments may lead to short-circuiting of the device.

We plan to address all these issues upon our project proposal.

# Competitors

Accuware currently has a device that helps locate wifi devices. However our devices will be tailored for bus stops and the data will be formatted in a the most productive ways from the perspective of bus companies.