Software Requirements Specification Document
Project Dogfood
Simplexity
Ian Cook, Mitch Heer, James Lorenz, Tom Navarro, Levi Stanley
Version 1
April 29, 2011
1 INTRODUCTION
This is the software requirements specification document for Project Dogfood to be
sponsored by Ansync.
The development team for this project is Simplexity. The team is comprised of senior-level
students majoring in Computer Science at California State University, Sacramento. The
students are enrolled in a two-semester senior project course that is required of all
undergraduate majors. To fulfill the senior project requirement, the development team
must successfully deliver a desired software product.
The sponsor and development team are as follows:
PROJECT SPONSOR




Name:
Sam Miller
Title:
Owner
Company Name: Ansync Inc.
Contact Information
o Phone:
916-933-2850
o E-mail:
sam@ansync.com
SIMPLEXITY DEVELOPMENT TEAM





1.1
Ian Cook
o Phone:
916-243-8426
o E-mail:
ianvcook@yahoo.com
Mitch Heer
o Phone:
916-220-9845
o E-mail:
mgh201@sbcglobal.net
James Lorenz
o Phone:
916-678-0155
o E-mail:
jl338@csus.edu
Tom Navarro
o Phone:
209-531-4787
o E-mail:
navarrot@gmail.com
Levi Stanley (Project Manager)
o Phone:
530-559-8183
o E-mail:
avilyn.jarkal@gmail.com
PURPOSE
The purpose of the software requirements specification document is to outline the
behavior that is expected of the project. This document will ensure that the development
team, the faculty advisor, and the sponsor all know what the requirements will be for the
system.
1.2
SCOPE
The document will cover both functional and non-functional requirements of the project, as
well as define the data that will be used in the system. The interaction between the user
(“actor”) and the system, as well as the system features, will be demonstrated with use case
diagrams. The focus will be strictly on requirements and not the design; the design will be
specified at a later time.
1.3
DEFINITIONS, ACRONYMS, ABBREVIATIONS
This section will cover the definitions, acronyms, and abbreviations used throughout the
document to clarify terms the development team and the sponsor may be unfamiliar with.
1.3.1












DEFINITIONS
Apache
o Web server software that is typically used in a UNIX environment.
Cron
o Job scheduler within the UNIX/Linux environment.
Daemon
o A background process that isn’t controlled by the user.
Java
o Object-oriented language designed to have compatibility with many systems.
JavaScript
o An object-oriented scripting language used primarily in web development.
jQuery
o Cross-browser JavaScript library to ease the use of HTML scripting.
Man-In-The-Middle Attack
o An adversary intercepts communication between two users, and each user
thinks they are talking to the other user, but they are talking to the
adversary. This can be used to intercept data that is thought to be private.
Open-source
o Software (typically free) whose source code is available, and operates under
a license that allows users to edit and redistribute the software.
Packet Sniffing
o Hardware or software that can intercept data traffic passing over a network.
Pick and Place Machine
o Robotic machine that places the electronic components onto a Printed
Control Board (PCB).
Schema (Database)
o Describes the organization of a database and how the database will be
constructed via tables.
Task
o The smallest unit of work subject to management accountability.
1.3.2
















1.3.3

1.4
ACRONYMS
CSS3 (Cascading Style Sheets Level 3)
DPI (Dots Per Inch)
GUI (Graphical User Interface)
HTML (HyperText Markup Language)
HTTP (HyperText Transfer Protocol)
JSON (JavaScript Object Notation)
MTBF (Mean Time Between Failures)
MTTF (Mean Time To Failure)
MySQL (“My” Structured Query Language)
o Open-source version of SQL.
PHP (PHP: Hypertext Processor)
o General-purpose scripting language used in web development to provide
dynamic web pages.
SRS (Software Requirements Specification)
UI (User Interface)
UM (User’s Manual)
VPN (Virtual Private Network)
W3C (World Wide Web Consortium)
o Organization that determines World Wide Web standards.
XHTML (Extensible HyperText Markup Language)
ABBREVIATIONS
None.
REFERENCES
Buckley, Robert. “Guide To Preparing The Software Project Requirements Specification
Document”. 02 Nov. 2010. 29 Apr. 2011
<http://gaia.ecs.csus.edu/~buckley/CSc190/SRS.pdf>.
“Guide to the software requirements definition phase”. European Space Agency. 1995. 29
Apr. 2011 < http://www.fabricadesoftware.cl/documentos/ESA/PSS0503.pdf>.
1.5
OVERVIEW OF DOCUMENT CONTENT
Section 2 contains information needed to understand the specific requirements covered
later in the document. Section 2.1 describes how the software fits within the sponsor's
environment. Section 2.2 contains descriptions of the users and use case diagrams of the
features they require. Section 2.3 describes the work users will accomplish using the
software. Section 2.4 lists constraints that limit the software's development. Section 2.5
contains the assumptions and dependencies for the development of the software.
Section 3 is the core of the SRS. It contains all of the technical information needed to design
the software. Section 3.1 documents each of the use cases found in Section 2. Section 3.2
outlines performance requirements for the software. Section 3.3 explains the design
constraints that will be used when designing the software. Section 3.4 covers all of the
system's non-functional requirements.
Section 4 contains the sign-off sheet that is used to indicate approval of and agreement to
the requirements and data definitions contained in this document. The signed proposal
serves as a de facto “contract” between the project team, the faculty advisor, and the
sponsor.
Appendix A contains the data dictionary of all data contained within the database, including
data elements, data structures, and data tables.
2 GENERAL DESCRIPTION
This section contains information needed to understand the specific requirements covered
later in the document. Section 2.1 describes how the software fits within the sponsor's
environment. Section 2.2 contains descriptions of the users and use case diagrams of the
features they require. Section 2.3 describes the work users will accomplish using the
software. Section 2.4 lists constraints that limit the software's development. Section 2.5
contains the assumptions and dependencies for the development of the software.
2.1
PRODUCT PROSPECTIVE
Project Dogfood will operate as a web-based application that will be accessed by employees
of Ansync both from on site computers and from remote computers. The software will
utilize MySQL for the database back-end and Apache as an intermediate application server.
PHP will be the interpreter for the web server in order to provide dynamic web pages
which act as the user interface. Additionally, we will be using Cron for handling the
scheduling of all jobs.
2.2
USE CASE MODELS
The following are the users that will interact with the software:
 Admin User
 Basic User
 Backup Daemon (system user)
Admin users inherit all of the requirements of basic users.
The following are the primary features included in the software:
 Basic Users can receive parts
 Admin Users can confirm changes
 Basic Users can run designs
 Basic Users can audit the inventory
 The Backup Daemon can backup the database
 Admin Users can restore the database
 Admin Users can manage other users
 Admin Users can manage the schema
Figures 1 through Figure 8 outline the functions required for each of these features.
Appendix A contains an exhaustive list of fields required for these features.
Figure 1: Receive Part Use Case Diagram
The user must be able to choose which type of part was received. To indicate the part, the
user must be able to find or create the part in the system. Once the part is selected the user
must be able to create a batch of parts and indicate how many of the incoming parts will be
stored in a specific location. To indicate the location, the user must be able to find and
create locations.
Figure 2: Confirm Changes Use Case Diagram
To confirm a change, an admin user must be able to choose a pending change and view the
details of that change. Based on the details, the user must be able to update the details,
accept the change, and reject the change.
Figure 3: Run Design Use Case Diagram
To run a design, a basic user must be able to choose a design and indicate how many times
to run that design. Indicating the design requires that the user be able to find or create the
design. Creating a design requires that a user be able to choose which parts are used for the
design. Indicating parts requires the user be able to find or create parts. The user must also
be able to check how many parts would be left in inventory if the design was run an
indicated amount of times. Finally the user must be able to indicate that the design ran and
update the remaining parts in inventory.
Figure 4: Audit Inventory Use Case Diagram
To audit the inventory, a basic user must be able to find, create, update, and delete any part,
location, and job in the system. The user must also be able to update how many parts are
stored in each location.
Figure 5: Backup DB Use Case Diagram
To backup the database, the backup daemon must be able to run a backup script at a
regularly scheduled time. That backup script will create a restore point.
Figure 6: Restore DB Use Case Diagram
To restore the database, the admin user must be able to get a list of the recent restore
points created when the database is backed up. The user must then be able to choose to
restore the database to one of those points.
Figure 7: Manage Users Use Case Diagram
To manage users, the admin user must be able to create, update, and delete users from the
system. Updating the user includes resetting the user's password, changing information
about the user, and changing the user's username. The admin must also be able to change
each user's privileges.
Figure 8: Manage Schema Use Case Diagram
To manage the schema, the admin user must be able to create, update, and delete tables
from the additional schema. With those tables, the admin must be able to create, update,
and delete fields.
2.3
USER CHARACTERISTICS
The work that is expected to be done by the users will be different depending on the type of
the user. “Basic” users will have access to the database, and be able to do all operations on
the database that the “admin” users are able to do. Those operations include two major
features: track materials, and build/verify parts. The difference between the admin and
basic user classes is the admin will have the ability to add/remove users, to modify current
user permissions.
To the user, “tracking materials” will be making sure the materials are accounted for when
they arrive in the building, when they leave, and everything in between. The materials
arriving in the building have to be accounted for, which means determining what the part
is, the quantity of that part, and the batch number of that part. The users want to be able to
locate a part at any given time by searching for a part and referring to the “location” field.
Also, the users want to be able to edit the inventory quantities, either manually (looking up
a part and editing the “quantity” field), or have the data output from the pick-and-place
machine imported into the database, making necessary changes.
2.4
GENERAL CONSTRAINTS
This subsection defines any restrictions and conditions that will limit Simplexity's options
in the development of Project Dogfood. This includes, for example, hardware limitations,
languages, and security concerns.
HARDWARE
Based on available hardware, Project Dogfood must be designed to run on an Intelcompatible platform, running a variant of Linux. The system will have a minimum of 2 GB
of ram, 50 GB of hard disk space, and a modern Intel-compatible processor with at least
two cores, running at least 2.1 GHz.
GUI
The GUI must render and function properly in all standards-compliant desktop browsers,
except Microsoft Internet Explorer. This includes, but is not limited to, Mozilla Firefox 3.6,
Opera 11, and Safari 5 (or their equivalent versions). Project Dogfood must also use
XHTML 1.1, CSS3, JavaScript, and the jQuery library version 1.4.2 with the Template plug-in
version 1.0.0pre (or equivalent). The GUI must work equally well for supported browsers
on Windows, Linux, and Mac platforms.
CONCURRENT OPERATIONS
The system must support up to three concurrent users, who may be running any or all of
the use cases concurrently. Such use cases (and their requisite functions) must be
managed so as to be capable of running multiple concurrent instances.
SECURITY
Project Dogfood must allow users to connect remotely over the internet, via a VPN. Users
that connect remotely will have the same access privileges they would get if they logged in
locally. Remote users count toward the three-user maximum. The system must support
secure transmission of data and commands, and must ensure that common exploits (such
as packet sniffing, man-in-the-middle attacks, etc.) do not compromise the security or
integrity of data.
EXTENSIBILITY
The core functionality of Project Dogfood must be designed in such a way as to facilitate
extensibility. Users must be able to add “parts” with an arbitrary set of information (and
fields).
2.5
ASSUMPTIONS AND DEPENDENCIES
Project Dogfood's minimum recommended system requirements are 2GB of RAM, a 50 GB
hard drive, and a dual-core processor operating at a stock speed of at least 2.1 GHz per
core.
Project Dogfood depends on the availability of a Linux based host operating system.
Apache HTTP Server 2.2 is required as the web server and MySQL Community Edition 5.5
is required as the database management system. It is assumed that all of the above
underlying software is installed, configured, and operating correctly. Instructions for
installation and configuration will be provided in the User's Manual.
Updates or upgrades to the underlying software will have unpredictable results.
Simplexity will not be updating Project Dogfood after its delivery.
Project Dogfood will be designed to function properly in Firefox 3.6 (or later), Chrome
10.0.648.204 (or later), Opera 11.01 (or later), and Safari 5.0.4 (or later).
It is assumed that the project software will be used on a secure network. Security
measures for transactions over public networks will not be implemented.
It is assumed that the sponsor will monitor the disk space of the host database server. If a
transaction fails due to inadequate available disk space, a message will inform the user that
more disk space is needed.
It is assumed that all changes to the database will be done through Project Dogfood.
Modifications to the delivered software will not be supported by Simplexity. The sponsor
will assume all risks if modifications to the software are made.