Software Requirements Specification

sacktoysSoftware and s/w Development

Dec 13, 2013 (3 years and 10 months ago)

85 views

Software Requirements
Specification

for

Tote Tracker Project

Version <1
.
0
>





Prepared by

Group Name:
Group Eight Ltd.

Jeffrey Fillingham

B00507809

jeffreyf@cs.dal.ca

Al sirhni Mshari

B00547343

alsirhni@cs.dal.ca

Jeremy Fournier

B00415949

jeremy.fourni
er@hotmail.co
m

Kyle Johnson

B00513432

kyle.johnson400@gmail.com





Instructor:

Andrew Rau
-
Chaplin

Course:

Software Engineering

Teaching Assistant:

Komalesh Narayan

Date:

February 10
th

2011



Software

Re
quirements Specification for <Project>


Page
ii


Contents

REVISIONS

................................
................................
................................
................................
..............................

III

1

INTRODUCTION

................................
................................
................................
................................
...............

1

1.1

D
OCUMENT
P
URPOSE

................................
................................
................................
................................

1

1.2

P
RODUCT
S
COPE

................................
................................
................................
................................
.......

1

1.3

I
NTENDED
A
UDIENCE AND
D
OCUMENT
O
VERVIEW

................................
................................
...................

1

1
.4

D
EFINITIONS
,

A
CRONYMS AND
A
BBREVIATIONS

................................
................................
.......................

1

1.5

D
OCUMENT
C
ONVENTIONS

................................
................................
................................
........................

1

1.6

R
EFERENCES AND
A
CKNOWLEDGMENTS

................................
................................
................................
..

1

2

OVERALL DESCRIPTION
................................
................................
................................
...............................

2

2.1

P
RODUCT
P
ERSPECTIVE

................................
................................
................................
............................

2

2.2

P
RODUCT
F
UNCTIONALITY

................................
................................
................................
.........................

2

2.3

U
SERS AND
C
HARACTERISTICS

................................
................................
................................
.................

2

2.4

O
PERATING
E
NVIRONMENT

................................
................................
................................
........................

3

2.5

D
ESIGN AND
I
MPLEMENTA
TION
C
ONSTRAINTS

................................
................................
..........................

3

2.6

U
SER
D
OCUMENTATION

................................
................................
................................
.............................

3

2.7

A
SSUMPTIONS AND
D
EPENDENCIES

................................
................................
................................
..........

3

3

SPECIFIC REQUIREMENT
S

................................
................................
................................
..........................

4

3.1

E
XTERNAL
I
NTERFACE
R
EQUIREM
ENTS

................................
................................
................................
....

4

3.2

F
UNCTIONAL
R
EQUIREMENTS

................................
................................
................................
....................

4

3.3

B
EHAVIOUR
R
EQUIREMENTS

................................
................................
................................
.....................

4

4

OTHER NON
-
FUNCTIONAL REQUIREME
NTS

................................
................................
..........................

6

4.1

P
ERFORMANCE
R
EQUIREMENTS
................................
................................
................................
................

6

4.2

S
AFETY AND
S
ECURITY
R
EQUIREMENTS

................................
................................
................................
...

6

4.3

S
OFTWARE
Q
UALITY
A
TTRIBUTES

................................
................................
................................
.............

6


Software

Re
quirements Specification for <Project>


Page
iii



Revisions

Version

Primary Author(s)

Description of Version

Date Completed

1.0

Jeffrey Fil
lingham

Finalizing the working copy

Feb 10
th

2011





Software

Requirements Specification for <Project>


Page
1


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 To
te Tracker program is to keep track of totes from the NS Firefighters Schoo
l.
The
purpose of the program is to streamline the
ir

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 th
eir 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 Firefi
ghters 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

Re
ferences and Acknowledgments


McMaster SRS Template
, found at :

http://web.cs.dal.ca/~arc/teaching/CS3130/Templates/SRS%20and%20Project%20Plan%20Templ
ates/SRS
-
template1.doc







Software

Requirements Specification for <Project>


Page
2


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 a
s 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 Characterist
ics

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.

Software

Requirements Specification for <Project>


Page
3



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 u
se 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 w
e 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 w
orks 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 s
turdy 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 chose
n 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 ide
ntification 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.




Software

Requirements Specification for <Project>


Page
4


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 Interfac
es

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 charac
ter. 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 Requiremen
ts



Tote

profile
s:

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 b
e required by the
product. A “sign
-
up” style screen will be required for the creation and editing of the
profiles.



I
nstructor profile
s:

o

Instructor profiles will contain the information about an instructor, such as their
barcode ID as well as their full nam
e. 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 capacit
y 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 o
ut 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
Software

Requirements Specification for <Project>


Page
5


the tote’s default item list) or if any items aren’t suppos
e 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 wil
l 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 o
ut 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 prog
ram:

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










Software

Requirements Specification for <Project>


Page
6




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 indi
viduals.

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. Refe
r 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 acc
ess 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 w
ith 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.