Software Requirements Specification for <Project> Page iii
Software Requirements Specification
for
Tote Tracker Project
Version <1.0
Prepared by
Group Name: Group Eight Ltd.
Jeffrey Fillingham / B00507809 /Al sirhni Mshari / B00547343 /
Jeremy Fournier / B00415949 /
Kyle Johnson / B00513432 /
Instructor: / Andrew Rau-Chaplin
Course: / Software Engineering
Teaching Assistant: / Komalesh Narayan
Date: / February 10th 2011
Contents
Revisions iii
1 Introduction 1
1.1 Document Purpose 1
1.2 Product Scope 1
1.3 Intended Audience and Document Overview 1
1.4 Definitions, Acronyms and Abbreviations 1
1.5 Document Conventions 1
1.6 References and Acknowledgments 2
2 Overall Description 3
2.1 Product Perspective 3
2.2 Product Functionality 3
2.3 Users and Characteristics 3
2.4 Operating Environment 3
2.5 Design and Implementation Constraints 4
2.6 User Documentation 4
2.7 Assumptions and Dependencies 4
3 Specific Requirements 5
3.1 External Interface Requirements 5
3.2 Functional Requirements 6
3.3 Behaviour Requirements 6
4 Other Non-functional Requirements 7
4.1 Performance Requirements 7
4.2 Safety and Security Requirements 7
4.3 Software Quality Attributes 7
Revisions
Version / Primary Author(s) / Description of Version / Date Completed /1.0 / Jeffrey Fillingham / Finalizing the working copy / Feb 10th 2011
Software Requirements Specification for <Project> Page 6
1 Introduction
1.1 Document Purpose
The purpose of this document is to outline the Software Requirements for the Tote Track project that Group Eight Ltd. is preparing.
1.2 Product Scope
The purpose of the Tote Tracker program is to keep track of totes from the NS Firefighters School. The purpose of the program is to streamline their inventory process by providing a reliable and efficient electronic way to keep track of the borrowing and returning of totes, as well as their contents. The delivered program will consist only of the actual tracking program; they will have to fill in the database itself. The goal of the product is to provide a simple system that will help the school by allowing them to inventory their totes for the purpose of determining what has gone missing and when as well as what needs to be replaced.
1.3 Intended Audience and Document Overview
The intended audience of this document includes our TA and professor, our client (the Nova Scotia Firefighters School) as well as ourselves (to reference to when designing the system).
1.4 Definitions, Acronyms and Abbreviations
Client refers to the Nova Scotia Firefighters School.
1.5 Document Conventions
This document will use Arial Font, size 11, throughout.
1.6 References and Acknowledgments
McMaster SRS Template, found at :
http://web.cs.dal.ca/~arc/teaching/CS3130/Templates/SRS%20and%20Project%20Plan%20Templates/SRS-template1.doc
2 Overall Description
2.1 Product Perspective
The product is a replacement for a system the client already has. Basically the client tries to track totes by writing down who has what tote on a whiteboard. This whiteboard is erased often, and totes (as well as their content) go missing. This product will improve their current system by making everything electronic. Totes will be easily scanned into the system, making tracking intuitive. It will allow for automated tracking and should improve both reliability and accuracy.
2.2 Product Functionality
The major functions of the system are as follows:
· Create a tote profile
· Create a instructor profile
· Create items for a tote
· Return/checkout a tote
· Check a totes inventory
· Keep a record (time stamped) of all inventories and returns/check outs of totes
· Analysis of the data
2.3 Users and Characteristics
The users of the product will be mainly firefighter instructors as well as front office administrators. The instructors generally have a low level of computer skill. They are pretty laid back and do not like computer systems getting in their way. This will mean the program will have to be very simple to use. The administrators have higher level computer skills but will be in contact with the system less often than the instructors.
2.4 Operating Environment
The operating system will be Windows XP. Java 1.6 will be used to build the system. The database we will use is still under consideration, between SQLite, MySQL, Ozone and JDBC. A Unitech MS210-1B barcode scanner will be used to interface with the program, as well as manual keyboard and mouse input. The system will be contained mostly inside the instructor’s offices, but will be portable as long as the computer the product is being used on has permission to access the database.
2.5 Design and Implementation Constraints
As the group consists of four full time students it is difficult to schedule meetings. Therefore, we may have trouble meeting our goals and objectives on time.
We have been unable to find any software packages or systems that we could use to relieve us of some coding work. All of the packages we have seen either don’t meet our needs or exceed our requirements.
Because the client is located far from where the team lives and works, it will be difficult to get any real world testing done. This means we will have to trust that the barcode scanner works as described by the client.
Because the instructors at the school do not necessarily have a high level of computer skills, we will have to make the system simple to use. An intuitive design and user friendly interface will be required, as well as a sturdy back end to minimize the chance of system failure. Any defect in the system will be difficult to address, as the team will lack the means and motivation to maintain the program after the semester ends, and the client lacks the technical skills needed to fix an error.
2.6 User Documentation
User training will be provided upon completion of the product. As well, both a one page reference sheet and a more in-depth manual will be provided outlining all the functions of the device. The manual will include a step-by-step tutorial on the basic use of the system, as well as some other more advance topics.
2.7 Assumptions and Dependencies
Design & testing of the software will be made on a Windows XP machine, capable of running Java 1.6 or higher. Moreover, the chosen database system will be installed and tested on this machine. Therefore, future upgrades of the OS will not be supported, nor considered.
The use of a barcode scanner will be required for interfacing with the system, along with a predefined barcode identification format. Modifications to either entity will not be supported.
The actual use of the system must be followed in proper order, in order to ensure appropriate check-out, check-in procedures. We assume the trained client will follow instructions during the use of the program after launch.
3 Specific Requirements
3.1 External Interface Requirements
3.1.1 User Interfaces
We do not currently have a graphical interface designed. Paper prototypes will be required before a design is finalized.
3.1.2 Hardware Interfaces
Our Tote Tracker program will interface with a Unitech MS210-1B barcode scanner. The scanner is designed to interface as a keyboard, so when it reads a barcode the code is stored as text. Once the scan is complete it finishes with a return escape character. The scanner works best with CODE39 barcodes, but can handle others as well.
3.1.3 Software Interfaces
Java 1.6 will interface with a Windows XP OS, along with our chosen database system. All components will reside on the same system, and no dependency on a Server machine is required. The user-interface of the program will run similar to a desktop application, and operate along with a barcode scanner device. The mouse, and keyboard will be require for the use of the proposed program.
3.2 Functional Requirements
· Tote profiles:
o The users of the product will be able to create a complete tote profile. This profile will encompass everything about the tote, such as its barcode ID and name (i.e. “Tote 63”). Creation, editing and deletion of instructor profiles will be required by the product. A “sign-up” style screen will be required for the creation and editing of the profiles.
· Instructor profiles:
o Instructor profiles will contain the information about an instructor, such as their barcode ID as well as their full name. Each instructor can be assigned a tote. Creation, editing and deletion of instructor profiles will be required by the product. A “sign-up” style screen will be required for the creation and editing of the profiles.
· Tote Items:
o Each tote has the capacity to hold items. The product will have functionality create new items and add them to a specific tote, as well as remove them. Items will consist only of a barcode and a name. Each tote will have a specific list of default tote items that should always be in it.
· Return/checkout a tote:
o The program will track totes. This will require functionality to return and checkout totes. Upon checking out a tote, the user will have to scan all the items inside the tote. The items in the tote, the time it was checked out and the instructor checking it out will have to be saved to the database. Upon checking out, if any items are missing that should be in it (by comparing the inventory just scanned to the one in the tote’s default item list) or if any items aren’t suppose to be in there, a warning will appear on the screen. Upon return, all items must be scanned. It will save the list of items, and the time it was returned. A warning will appear if any items are missing or are extra.
· Analysis of the data:
o The product will provide functionality to view current totes that are missing items (or have extra items) as well as where all the totes currently are, and who possesses them.
3.3 Behaviour Requirements
3.3.1 Use Case View
· Create a Tote: A user will scan a new tote that will be added to the database.
· Update a Tote: A user will scan new items to be added or removed from a tote.
· Delete a Tote: A user will scan a tote that will be deleted from the database.
· Create inventory: User requests an inventory and gets a list of checked out items, missing items, items in stock etc.
· Create User: A new instructor will be added to the database.
· Update User: Update an instructors information.
· Delete User: Delete an instructor from the database.
· Add Item: User will scan a new item that will be added to the current tote.
· Remove Item: User will scan an item to be removed from the current tote.
· Start up program: User double clicks icon from Windows XP and it loads the program
· Analysis of data: User has access to logs for analysis
· Close program: Upon shutting down the program, user prompted whether to save data and the database is exited successfully
· Program crashes: In case the program crashes while user is accessing a database, proper maintenance will need to be performed the next time the program is started
4 Other Non-functional Requirements
4.1 Performance Requirements
The following performance metrics have been arranged, in understanding of the nature of the client.
1. All interactions & activities on the software shall not take more than 5 seconds. This ensures users are not de-motivated from using the digital solution, and relapse to the paper-based approach.
2. Accessibility to the database shall be made available to experienced users should exports/imports be needed in the future. This ensures future access to the Admin after the completion of the software support.
3. Screen interface & color selection shall be made simple and intuitive to the Admin staff. For example, all font sizes will be larger enough to quickly read for most individuals.
4. The database must allow for multiple client accesses. Although not immediately required, future installations and additions of clients should be supported.
5. The handheld scanner should be small and easy-to-use. It should read and process barcodes within 1 second. This is to motivate and enhance the check-in, check-out processes.
4.2 Safety and Security Requirements
There are no safety requirements for the program beyond the safety requirements of the scanner as well as typical use of a computer. Refer to scanner safety instructions for further details.
4.3 Software Quality Attributes
The usability quality attribute is arguably the most important factor in the software development of the Tote Program; due to the required motivation to move from the current paper-based system to a brand new electronic format, which may be slower at first to adopt. The use of large fonts, large buttons, and intuitive design will be essential.
Both software and database used will be open-source, and will allow for simple access to the source and records by future Developers, should the need arise. The readability and future modifications of the source code will need to be considered. Furthermore, the relational database design will be implemented using best practices, and with clear and appropriate table & field names.
Reliability and accuracy of the software should be kept above 95% in terms of the functions implemented. Since the functions performed will involve holding individuals accountable for products and materials, extra care will be taken to ensure consistency.
Since the software will be installed and used by one machine, portability does not play a major role, and will not be involved beyond ensuring future upgrades of Java are safe to do.