Requirements Specification
-
-
Purpose
-
Document Conventions
-
Intended Audience and Reading Suggestions
-
Product Scope
-
References
-
-
-
Product Perspective
-
Product Functions
-
User Classes and Characteristics
-
Operating Environment
-
Design and Implementation Constraints
-
User Documentation
-
Assumptions and Dependencies
-
-
External Interface Requirements
-
User Interfaces
-
Hardware Interfaces
-
Software Interfaces
-
Communications Interfaces
-
-
-
RFID Scanning
-
Data Storage
-
User Interface
-
Use Cases
-
-
Other Nonfunctional Requirements
-
Performance Requirements
-
Safety Requirements
-
Security Requirements
-
Software Quality Attributes
-
Appendix A: Glossary
This Software Requirements Specification will document the requirements for the EECS Inventory Software application, release number 0.1.0 upon first release. This product was requested by the client, Dr. David Juedes, Department Chair for the School of Electrical Engineering and Computer Science, Russ College of Engineering, Ohio University. This product has not been implemented in full, but it is an expansion upon a pre-existing inventory system of the Russ College of Engineering Electrical Engineering and Computer Science department's widely varied equipment holdings. As the pre-existing system was not a single software application, but a process of manual labor and spreadsheets, this product will build upon the resources previously utilized, but in practicality, replace it.
This document was originally written in Markdown. There are no other special fonts or typographical conventions.
The glossary of terms is in the Appendix.
This document is intended for the product's software developers, project managers, and client. As this product is designed, implemented, tested, and maintained by the same set of software developers with a hands-on partnership with the client, all sections of this document will be pertinent to all readers.
The EECS Inventory Software application will provide the EECS department with a modern cloud-based inventory system. This system will involve placing RFID tags on inventoried items and using a tag readers to locate the items. The Software Applications will connect to the tag reader via Bluetooth and record the time, date, serial number, and an image of the item and save this data in remote cloud storage. These features will drastically improve on the current system. With the help of the RFID scanner, Application, and Cloud database, the user will be able to efficiently locate items for inventorying and then update the items location and information for the next time.
RFID reader manufacturer's page: https://www.tsl.com/products/1128-bluetooth-handheld-uhf-rfid-reader/
The EECS Inventory Software application is augmenting the current system of performing required inventory checks which is currently a manual labor process using spreadsheets and personnel check-offs. The product will utilize an RFID scanner, mobile application, and persistent data storage for streamlining the inventory process.
Software and Process Flowchart:
The EECS Inventory Software must be able to perform the following functions:
- The product must correctly scan for and determine the location of the RFID tags on the inventory item.
- The product must collect the RFID tag ID number and connect to a database with correlating data.
- The product must store the inventory in a persistent manner with time and location snapshots with history management.
- The user must be able to find all inventory items in the surrounding area with the product.
- The user must be able to find a specific item with the product, either by RFID scanning or a database search.
- The user must be able to take an image with the mobile device and save this image in correlation with the database entries for a given inventory item.
- The user must be able to make manual entries into the product regarding an item's location, image, and other details.
The EECS Inventory Software will be used by one user class, the Registered User. The potential registered user includes, but is not limited to, EECS department chairs, department administrative specialist staff, laboratory coordinators, and support staff or approved student assistants. Because of the purpose of the product, the user depends upon who is responsible for inventory at the time.
The product will exist on an Android-based device with Bluetooth v2.1 capabilities. This device will interface with a TSL 1128 Bluetooth UHF RFID Reader for RFID tag reading purposes, and also with the Internet through either WiFi or a mobile data connection.
The user must have a Google account for authentication.
The RFID tags will primarily be used for "green tagged" and "red tagged" items for Ohio University. Green tagged items cost above a certain dollar threshold, while red tagged items are on loan from another organization, e.g. governmental organizations. The product must follow University rules and regulations.
Documentation will be posted to GitHub under the Wiki section of the repository as well as inside the repository itself under the docs folder.
- Ohio University has an existing database of tagged items. The project assumes the team can utilize that database.
- The User Interface is constrained by the Android device with an initial entry screen requiring the user to log in.
- Every subsequent screen must allow for the user to properly log out.
- Every subsequent screen must allow for the user to access the inventory feature sections and exit.
- The option for immediate cloud backup is available in the 'frequently used' interface bar.
User Interface Mockups:
TSL 1128-US-BT-UHF-IMG (FCC) RFID Reader
- Interface: USB, Bluetooth
- Frequency: UHF
- Style: Handheld, Bluetooth, iPhone
- Scanner Type: Radio Frequency + Barcode Laser.
Motorola Moto G (2nd gen)
- OS: Android 4.4.4 (KitKat), upgradable to 6.0 (Marshmallow)
- WLAN: Wi-Fi 802.11 b/g/n, hotspot
- Bluetooth: 4.0, A2DP, LE.
- GPS: Yes, with A-GPS, GLONASS.
This product, the EECS Inventory Software, will be connected to the cloud storage system (Firebase) where the database and images will be saved. The product will require updated libraries for the connection between the RFID scanner and the Android device, via bluetooth. The product will utilize wifi or other internet sources for backing up data to the cloud server.
The product implements Bluetooth and internet connectivity through the built-in functions of the phone and operating system.
The RFID reader operates over the Bluetooth 2.1 protocol.
The cloud backup feature requires communications with the Firebase realtime database, Firebase storage, and Firebase authentication over the Ohio University WiFi network using the provided API.
The software is for users to check the information of the items by scanning the tags, including images, owners, history of recording time/date/locations. The registered users can scan, read, and update the information. All data will be stored in cloud data storage.
The marquee feature of the product is to use the handheld scanner to read all RFID tags in a room. This is the highest priority.
The users connect the RFID scanner and mobile device first. After starting the "scan" function on the software, users can scan the tags on items, then the software will show the information of the items.
REQ-1: The mobile OS and Bluetooth version must fit the requirements. If not, the software will show a warning about the unusable equipments.
REQ-2: All the users must log in before using the software (initially).
The Application stores all database entries with pictures in a cloud based storage medium for ease of accessibility. This is of highest priority.
Data will be created or updated when saved from the application. The user will provide the necessary entries in database if creating a new item or update the location and picture(if needed) if item already exists in database. Database stored remotely will be accessibly by only the database owners.
The user will provide the necessary entries in database if creating a new item or update the location and picture(if needed) if item already exists in database. There must be a good internet connection to access the cloud database.
The UI will provide option buttons to users to let them use the functions of the software. First priority.
Booting functions after users press the button, like to log in/out, and finally show the information they need.
Let users log in/out, scan, check and update the item information, check history, and show items' current location.
- Description: The User wishes to add an item to the database
- Actors: Registered User
- Preconditions:
- RFID scanner is attached to system
- The user has a tagged item nearby
- Main Flow:
- User decides to Scan the Area and taps the appropriate icon.
- The User uses the scanner to create a list of nearby items.
- The user chooses the desired tagged (but not logged) item and goes to the item view.
- Alternate Flows: The user cancels and returns to the previous screen
- Exception Flows:
- If there are no tags in the scan (e.g. scanner was not properly aimed) then show an error message “No items found.”
- If an item is already in the database, then bring up the existing properties from the database (that is, the program should check if a scanned item is in the database)
- Postconditions: User is at the item properties screen with a new item and an RFID tag.
- Description: The User wishes to scan many items and verify their location in the database
- Actors: Registered User
- Preconditions:
- RFID scanner is attached to system
- The user has a tagged item nearby
- Main Flow:
- User decides to Scan the Area and taps the appropriate icon.
- The User uses the scanner to create a list of nearby items
- The user chooses “Update All” in the application.
- The application prompts the user for the current location.
- The application iterates through each item and updates the location and last seen date
- Alternate Flows: The user cancels from the list view and returns to the previous screen
- Exception Flows: If there are no tags in the scan (e.g. scanner was not properly aimed) then show an error message “No items found.”
- Postconditions: User is at the list view screen with all scanned items visible
- Description: The User wishes to modify an existing item in the database
- Actors: Registered User
- Preconditions: The user is in the item properties view. The properties view may have blank fields (e.g. for new item creation) or filled or partially filled fields (for item editing). Both are considered an “update”
- Main Flow:
- User modifies item properties using the phone touch screen and keyboard
- These properties include: Photograph, Date Seen, Date Purchased.
- User hits “ok” to save and “back” to exit
- If the item is not in the database, saving the item creates it.
- Alternate Flows: If user hits “back” without saving, the program checks for changes and if necessary prompts them to save or cancel.
- Exception Flows: None
- Postconditions: The item as it exists in the database reflects the changes input by the user
- Description: The User wishes to delete an existing item in the database through a scan.
- Actors: Registered User
- Preconditions: The user is in the item properties view. The properties view may have blank fields (e.g. for new item creation) or filled or partially filled fields (for item editing). Both are considered an “update”
- Main Flow:
- User in the item view decides to press the “delete” button.
- The program asks for confirmation and then deletes the item permanently.
- Alternate Flows: If user hits “back” without saving, the program checks for changes and if necessary prompts them to save or cancel.
- Exception Flows: If the user is in the item view but the item is not in the database, the icon should be unavailable.
- Postconditions: The item shows as removed from inventory (still exists in the database).
- Description: The User wishes to find an item without scanning
- Actors: Registered User
- Preconditions: The database has some item entries
- Main Flow:
- User decides to view the database itself and taps the appropriate button
- The user applies filters to find items that match criteria, e.g. “location” or “last seen” or “name”
- If no filters are applied then all items (batched) are pulled from the database and displayed on the screen.
- Alternate Flows: The user cancels filtering and returns to the previous screen
- Exception Flows: If there are no items in the database then show an error message “No items found.”
- Postconditions: The list of items pulled from the database are displayed on the screen
- RFID scanner must function out to a room-sized distance.
- Database should not exceed the storage capacity of the local device (< 8 GB)
- Use of wireless communications should not introduce excessive battery drain.
There are no known safety requirements at this time.
- The Ohio University database is subject to a degree of security. The team needs to consult the regulations at this point, but physical security of the database item as well as securing the cloud storage account should be sufficient at this time.
- The EECS Inventory Software users will need correctness, reliability, and maintainability to be of highest value in product attributes. Then, portability and usability will be of next highest value.
- The EECS Inventory Software developers will need testability and flexibility to be of highest value in product attributes.
Term(s) in this document that require clarification: They are listed below:
Cloud as a location refers to the internet, or more specifically, the internet-based storage service provider.