Use Cases

A page for use cases to reside. Section 1 will be for the hardware team, while section 2 is for the software team. Please read the guide and use the template found here.

1. Hardware Use Cases

Use Case ID:	1.1
Use Case Name:	Update database with collected and formatted data
Created by:	AC
Date Created:	November 24, 2013
Date Last Updated:
Last Updated by:
Actor:	RaspberryPi and sensors as they store and collect data
Description:	Collected data will be rendered compatible with the database, which will be updated in real time.
Preconditions:	1. Sensor is connected and collecting data 2. Database is accessible 3. Data has been successfully formatted
Postconditions:	1. Database received the new values successfully
Priority:	High during real time updates, otherwise normal
Frequency of Use:	High
Normal Course of Events:	1. Data is collected and stored by actors 2. Data is rendered into a database compatible form 3. Database is accessed and data is transferred
Alternative Courses:	1.a Data is collected but not stored 1.a.1 User is notified of the error 3.a Data is transferred but is not formatted correctly 3.a.1 User is notified
Exceptions:
Includes:
Special Requirements:
Assumptions:	1. Assumes that the collected data needs to be formatted. Will be verified through testing. 2. Assumes that the database (can be accessed and) does not clear itself every 10 minutes.
Notes and Issues:

2. Software Use Cases

Use Case ID:	2.1
Use Case Name:	Assign a location to a microcontroller
Created by:	Ben
Date Created:	November 24, 2013
Date Last Updated:
Last Updated by:
Actor:	Person setting up or changing sensor configuration
Description:	The microcontroller will have no way of knowing it's geographic location, so this should be configurable by a person. Once connecting a microcontroller, the user should be able to see that a new 'thing' has been added to the sensing network (Do they register themselves or do they need to be registered?). This will have a unique ID and can be assigned a location based on a map of the store.
Preconditions:	1. User is logged in/authenticated 2. System describing spatial location of shelves exists (may include map) 3. Microcontroller has registered as a 'thing' in the database
Postconditions:	1. Entity type: Location is set 2. New/no-location 'thing' flag removed
Frequency of Use:	High during initial set-up, low afterwards
Normal Course of Events:	1. User is made aware of 'thing' that has no location 2. User enters a mode where the location of the 'thing' can be added (either via map or manual entry) 3. User is shown location on map to verify that location is correct 4. Location is saved to database 5. Sensor's location can be accessed/displayed
Alternative Courses:
Exceptions:	2.ex User enters a location that is not valid 2.ex.1 User is notified of the error and asked for a new location 4.ex Database is not available 4.ex.1 User is notified of the error
Includes:	2.10 Log in/authenticate 2.3 Configure a spatial reference system
Special Requirements:
Assumptions:
Notes and Issues:

2.2 Assign a location to a sensor

2.3 Configure a spatial reference system (map?)

2.4 Get observation data

2.5 Display observations for a sensor

2.6 Display observations for a thing

2.7 Display observations for an aisle

2.8 Choose timeframe for historical observations

2.9 Display a notification

2.10 Log in/authenticate

2.11 Show a map

2.12 Show things/sensors on a map

2.13 Interpret observations

2.14 Show interpreted data on map