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.
| Use Case ID: | 1.1 |
|---|---|
| Use Case Name: | Update database with 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: | Once the hardware is set up and working, data will be collected by the actors and stored. As this happens it should be formatted if need be (use case 1.2). The database should then be accessed and updated with new, formatted data. This will eventually be implemented 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: | 1.2 Format Data |
| 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: | Much of this may change as the group begins working with sensors. |
| Use Case ID: | 1.2 |
|---|---|
| Use Case Name: | Format data for the database |
| Created by: | AC |
| Date Created: | November 25, 2013 |
| Date Last Updated: | |
| Last Updated by: | |
| Actor: | RaspberryPi and sensors as they store and collect data |
| Description: | Data collected by sensors will be formatted so that it can be easily updated to the database with use case 1.1 |
| Preconditions: | 1. Sensor is connected 2. New data is being gathered and stored |
| 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 ... will be revised as we start testing |
| Alternative Courses: | 1.a Data is collected but not stored 1.a.1 User is notified of the error ...again this will be revised later |
| Exceptions: | |
| Includes: | 1.1 Update database |
| Special Requirements: | |
| Assumptions: | |
| Notes and Issues: | Much of this may change as the group continues working with sensors. |
| Use Case ID: | 1.3 |
|---|---|
| Use Case Name: | Identify sensors |
| Created by: | AC |
| Date Created: | November 25, 2013 |
| Date Last Updated: | |
| Last Updated by: | |
| Actor: | RaspberryPi and sensors attached to it |
| Description: | All the sensors collecting data need to be recognized and given a unique ID so that their data may be distinguished even after it is formatted and updated to the database |
| Preconditions: | 1. Sensor is connected and recognized |
| Postconditions: | 1. The data that was collected can be related to a unique ID that represents each sensor |
| Priority: | High during real time updates, otherwise normal |
| Frequency of Use: | High |
| Normal Course of Events: | 1. Sensors are connected and recognized 2. Sensors are assigned a unique ID 3. Data is collected and the ID of the sensors corresponds to it 4. All this is relayed to the formatting use case (1.2) ... will be revised as we start testing |
| Alternative Courses: | 1.a Data is collected but not stored 1.a.1 User is notified of the error ...again this will be revised later |
| Exceptions: | |
| Includes: | 1.2 Formatting Data |
| Special Requirements: | |
| Assumptions: | |
| Notes and Issues: | Much of this may change as the group continues working with sensors. |
| 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: | November 30, 2013 |
| Last Updated by: | Ben |
| 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 |
| Priority: | Low |
| 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: | 1.a 'Thing' has a location, but is being moved to a new location 1.a.1 Remove Location attribute of associated sensors 1.a.2 Remove location of microcontroller |
| 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 store layout |
| Special Requirements: | |
| Assumptions: | |
| Notes and Issues: |
| Use Case ID: | 2.3 |
|---|---|
| Use Case Name: | Configure a store layout |
| Created by: | Ben |
| Date Created: | November 24, 2013 |
| Date Last Updated: | November 30, 2013 |
| Last Updated by: | Ben |
| Actor: | High during initial set-up, medium during operation |
| Description: | There needs to be a way for a user to construct a store layout system in order to locate sensors. This will be based on a typical grocery store shelf. Attributes can be added to increase the specificity of the model, but a bare-bones requirement will be enforced to ensure data can be mapped to the right area. This system will work with a visual representation (map) to provide context and help users. |
| Preconditions: | 1. User is logged in/authenticated |
| Postconditions: | 1. Store layout is saved 2. Spatial reference system can be used for other use-cases |
| Priority: | Medium |
| Frequency of Use: | Medium |
| Normal Course of Events: | 1. User enters store layout creator 2. User changes aisle configuration 3. User changes facing configuration 4. Spatial reference system is updated |
| Alternative Courses: | |
| Exceptions: | |
| Includes: | 2.10 Log in/authenticate |
| Special Requirements: | |
| Assumptions: | Some sort of quad-tree data structure can accommodate the addition/removal/editing of shelve layout |
| Notes and Issues: | Functionality of this feature may need to be limited due to complexity, experience and time-restraints. In the worst case scenario, the website only features one spatial reference system that cannot be changed. |
| Use Case ID: | 2.4 |
|---|---|
| Use Case Name: | Get aisle traffic observations |
| Created by: | Ben |
| Date Created: | November 24, 2013 |
| Date Last Updated: | Novemeber 30,2013 |
| Last Updated by: | Ben |
| Actor: | Internal, part of 2.x See aisle traffic |
| Description: | Observation data from the motion sensors needs to be accessible so that it can be displayed on the map. This data is located in the database, where each sensor will have a unique ID, associations with other objects, and other attributes. Using these associations to filter, sensor data needs to be requested with jquery. |
| Preconditions: | 1. User is logged in/authenticated. 2. A 'thing' with motion sensors exists in the database 3. A datastream belongs to said 'thing', made from observations belonging to said sensor |
| Postconditions: | 1. Data from motion sensor is retrieved from the database |
| Priority: | High |
| Frequency of Use: | High |
| Normal Course of Events: | 1. Webpage gets new data from database using jquery 2. Data is assigned to variable which can be used to display data |
| Alternative Courses: | 1.a No new data exists 1.a.1 No new data is assigned to variable |
| Exceptions: | |
| Includes: | |
| Special Requirements: | Each motion sensor observation is associated with a micro-controller from which it originated. This will be used to determine the location to show the data on the map. |
| Assumptions: | |
| Notes and Issues: |
| Use Case ID: | 2.5 |
|---|---|
| Use Case Name: | Get facing observations |
| Created by: | Ben |
| Date Created: | November 30, 2013 |
| Date Last Updated: | |
| Last Updated by: | |
| Actor: | Internal, part of 2.x See if products are faced |
| Description: | Observation data from the magnetometer/(other sensor?) needs to be accessible so that it can be displayed on the map. This data is located in the database, where each sensor will have a unique ID, associations with other objects, and other attributes. Using these associations to filter, sensor data needs to be requested with jquery. |
| Preconditions: | 1. User is logged in/authenticated. 2. A 'thing' with a sensor used for facing detection exists in the database 3. A datastream belongs to said 'thing', made from observations belonging to said sensor |
| Postconditions: | 1. Data from sensor used for facing detection is retrieved from the database |
| Priority: | High |
| Frequency of Use: | High |
| Normal Course of Events: | 1. Webpage gets new data from database using jquery 2. Data is assigned to variable which can be used to display data |
| Alternative Courses: | 1.a No new data exists 1.a.1 No new data is assigned to variable |
| Exceptions: | |
| Includes: | |
| Special Requirements: | Each facing detection sensor observation is associated with a micro-controller from which it originated. This will be used to determine the location to show the data on the map. |
| Assumptions: | |
| Notes and Issues: |
| Use Case ID: | 2.6 |
|---|---|
| Use Case Name: | See aisle traffic |
| Created by: | Ben |
| Date Created: | 30 November 2012 |
| Date Last Updated: | |
| Last Updated by: | |
| Actor: | Manager, Store Clerk |
| Description: | A user (Manager or store clerk) should be able to see if the aisle traffic on a map of the store. This should update automatically without input from the user, so they can have an idle screen showing the data as it become available. If they wish, this data can be filtered in some useful ways. It will have both a graphical and numerical version of the data, displayed in an attractive and easy to understand format. |
| Preconditions: | 1. User is logged in/authenticated. 2. A 'thing' with motion sensors exists in the database 3. A datastream belongs to said 'thing', made from observations belonging to said sensor 4. Aisle traffic observations are being retrieved by the database and assigned to a variable |
| Postconditions: | 1. Traffic information is shown on the map in a graphical form 2. Traffic information is shown on the map in numerical form |
| Priority: | Medium |
| Frequency of Use: | High |
| Normal Course of Events: | 1. User navigates to map view 2. Observations are shown without input from user |
| Alternative Courses: | 2.a User adds filter input 2.a.1 Data displayed based on the filters that the user has configured 2.b There are no observations 2.b.1 There is an indication that the sensor is working, but that it is in an idle state |
| Exceptions: | 2.ex Observations are not being shown on map 2.ex.1 User is shown an error message of some kind, most likely propagated from use case 2.4 get aisle traffic observations |
| Includes: | 2.10 Log in/authenticate 2.2 Assign a location to a micro-controller 2.3 Configure a store layout 2.4 Get aisle traffic observations 2.7 Show map UI |
| Special Requirements: | |
| Assumptions: | |
| Notes and Issues: |
| Use Case ID: | 2.7 |
|---|---|
| Use Case Name: | See if products are faced |
| Created by: | Ben |
| Date Created: | 30 November 2012 |
| Date Last Updated: | |
| Last Updated by: | |
| Actor: | Manager, Store Clerk |
| Description: | A user (Manager or store clerk) should be able to see if the products are faced in an area of the store via the map UI. This should update automatically without input from the user, so they can have an idle screen showing the data as it become available. If they wish, this data can be filtered in some useful ways. It will have both a graphical representation of the data, displayed in an attractive and easy to understand format. |
| Preconditions: | 1. User is logged in/authenticated. 2. A 'thing' with a sensor used for facing detection exists in the database 3. A datastream belongs to said 'thing', made from observations belonging to said sensor 4. Facing information observations are being retrieved by the database and assigned to a variable |
| Postconditions: | 1. Facing information is shown on the map in a graphical form |
| Priority: | Medium |
| Frequency of Use: | High |
| Normal Course of Events: | 1. User navigates to map view 2. Observations are shown without input from user |
| Alternative Courses: | 2.a User adds filter input 2.a.1 Data displayed based on the filters that the user has configured |
| Exceptions: | 2.ex Observations are not being shown on map 2.ex.1 User is shown an error message of some kind, most likely propagated from use case 2.5 Get facing observations |
| Includes: | 2.10 Log in/authenticate 2.2 Assign a location to a micro-controller 2.3 Configure a store layout 2.4 Get facing observations 2.7 Show map UI |
| Special Requirements: | |
| Assumptions: | |
| Notes and Issues: |
| Use Case ID: | 2.8 |
|---|---|
| Use Case Name: | Show Map UI |
| Created by: | Ben |
| Date Created: | November 30, 2013 |
| Date Last Updated: | |
| Last Updated by: | |
| Actor: | Internal / User (manager, store clerk) |
| Description: | Once a store layout is configured, there should be a map UI where the user can see observation data in it's correct location. This map will include controls to filter observations in certain ways. The map should update as new observations become available. |
| Preconditions: | |
| Postconditions: | |
| Priority: | |
| Frequency of Use: | |
| Normal Course of Events: | |
| Alternative Courses: | |
| Exceptions: | |
| Includes: | |
| Special Requirements: | |
| Assumptions: | |
| Notes and Issues: |
2.10 Log in/authenticate
2.11 Become System configurator
Probably un-needed:
| Use Case ID: | 2.x |
|---|---|
| Use Case Name: | Assign a location to a sensor |
| Created by: | Ben |
| Date Created: | November 24, 2013 |
| Date Last Updated: | |
| Last Updated by: | |
| Actor: | Person setting up or changing sensor configuration |
| Description: | A sensor will have no way of knowing it's geographic location, so this should be configurable by a person. Once a sensor is added to a microcontroller, the user should be able to see that a new sensor exists that does not have a location assigned to it. This will have a unique ID and can be assigned a location based on a map of the store/location of the microcontroller. |
| 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 4. Microcontroller has a set location 5. Sensor has been associated with 'thing' |
| Postconditions: | 1. Sensor Location is set 2. New/no-location sensor flag removed |
| Priority: | Low |
| Frequency of Use: | High during initial set-up, medium during operation |
| Normal Course of Events: | 1. User is made aware of sensor that has no location 2. User enters a mode where the location of the sensor 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: | 1.a The sensor has a location, but is being moved 1.a.1 Remove sensor's location attribute |
| 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 2.1 Assign a location to a microcontroller |
| Special Requirements: | |
| Assumptions: | |
| Notes and Issues: |