Epoch Inc.

Software Requirements Specication

Software Engineering Fundamentals, Fall, 2014
Modication history:
Team Name: Epoch Inc.
Team Members:

Bryce Mueller - bcmueller1395@eagle.fgcu.edu

Matt Sinex - mtsinex2695@eagle.fgcu.edu

Isaac Gainey - iagainey7197@eagle.fgcu.edu

Tomas Hoelzel - tchoelzel3565@eagle.fgcu.edu

Contents of this Document
Introduction

Software to be Produced

Denition, Acronyms, and Abbreviations

Product Overview

Assumptions

Use Case Diagram

Use Case Descriptions

Specic Requirements
SECTION 1: Introduction
Software to be Produced:

The software to be produced is titled, TimeWorks. It will be delivered in the form a desktop
application designed to work on two operating system platforms, namely Windows and
Macintosh OS X. The software will allow two di"erent kinds of user types to interact with it: a
Student user and an Admin user. Di"erent tasks can be accomplished depending on the
user, which is detailed in the Use Case Diagram. The key aspects of the software feature the
ability for the users to search for and book rooms for events, and access a calendar of the
events.
Denitions, Acronyms, and Abbreviations:

OS: Operating System

db: Database
Version Date Who Comment
v0.1 9/22/2014 Matthew Sinex Changed font and made some
formatting adjustments.
v0.2 9/25/2014 Matthew Sinex Initial draft of document
v0.3 9/29/2014 Matthew Sinex Added more content to sections two
and three.
SECTION 2: Product Overview
Assumptions:
$ Assumptions for the software include:

Software will be run on a computer running either Windows or Macintosh OS X and will
have access to standard computer components such as a mouse and keyboard.

Su%cient storage capacity for the software to perform due to its performance being
more important than the storage size.

Software will have access to an internet connection, preferably broadband or a

connection of equal or greater stability and speed.
Use Case Diagram:

Use Case Descriptions:
# Use-Case Description
1 Login to Application With a username and password, the user will be able to login to
the application as either an admin or a student user type.
2 Create Room The Admin user can create a new room in the database that a
student user will then be able to nd via search and request a
booking for.
#
3 Edit Room The Admin user will have the ability to edit the information
associated with the room that was originally input at the time of
creation. All data for the room can be changed, and the room
can be deleted.
4 View List of All Rooms Both user types will be able to view a list of all of the rooms, as
they are in that moment. Whether the rooms are booked or not,
the user will be able to view a list of them all.
5 View Map of Room Both user types will be able to view a visual map of the
buildings within the connes of the campus/area and what
rooms are contained within those buildings.
6 Search For Rooms The user will be able to search for rooms one of three ways:
7 Search by Room Criteria The user will be able to search for a room by using a series of
drop down boxes and checkboxes that determine what criteria
the room must have for that user. Examples include: the
number of seats the room will hold, if it is a lab or not, etc.
8 Search by List of All Available Rooms The user can look over a single list of all rooms of all types. The
only thing they will all have in common is that they will be
unbooked.
9 Search via Search Bar The user will be able to search by a search bar, which will
match what the user inputs to various results, whether it is the
room number, professor linked to the room, etc.
10 Request Room and Time The student user type will be able to request a room once one
has been found via search. The request will go to the admin.
11 Approve or Deny Room Request Once a room request has been submitted, the Admin user will
have the ability to approve or deny said request from within a
window (visible only to admin user types) in the application.
12 View Calendar of Booked Rooms and
Times
Any rooms that have been booked will be visible to either user
type via a calendar-like view inside the application.
13 Logout of Application Both users will have the ability to logout of the application,
provided that they are currently logged in to the program.
Use-Case Description #
SECTION 3: Specic Requirements
No: 1
Statement: A user should be able to download the software from an application store or
similar service via a web browser. The application shall be free.
No: 2
Statement: Given that the software has been downloaded and installed, a user shall be able
to utilize a login system in order to interact with the application.
No: 3
Statement: The software shall provide two user types for application use: a student user and
admin user.
No: 4
Statement: The user shall be able to login as one of the aforementioned user types with a
username and password.
No: 5
Statement: The admin user type shall be able create a room with properties associated to it,
such as how many seats the room holds, whether it is a lab or not, if food and drink is
allowed, etc.
No: 6
Statement: The admin user type shall be able to edit existing rooms that are in the database.
Edits may include, but are not limited to, the ability to change the name of the room, the
number of seats it holds, its location, room number, etc.
No: 7
Statement: Both the admin and student user types shall be able to search for rooms by means
of viewing a list of all available rooms.
No: 8
Statement: Both the admin and student user types shall be able to search for rooms via a
series of drop down menus that specify certain search criteria, such as searching for a room
that is a lab and can hold 100 people.
Template created by G. Walton (GWalton@mail.ucf.edu) on Aug 30, 1999 and last updated Aug 15,
2000; updated by A. Koufakou, Aug 2014
This page last modied by Matt Sinex (bcmueller1395@eagle.fgcu.edu ) on Sept 29, 2014
No: 9
Statement: Both the admin and student user types shall be able to search for rooms via a
search bar that accepts a string of letters and numbers and producing a list of results that
match the input from the user.
No: 10
Statement: Upon searching for a room, the student user type shall be able to send a request
to the admin to book the room.
No: 11
Statement: Given that a request has been sent to book a room, the admin user type shall be
able to approve or deny the request via a window in the software that shows all pending
requests.
No: 12
Statement: Both the student and admin user types shall be able to view a text list of all
rooms that are currently booked and for which days they are booked on.
No: 13
Statement: Both the student and admin user types shall be able to view a calendar of dates
that show what rooms are booked and when.
No: 14
Statement: Both the student and admin user types shall be able to view a map of all of the
rooms, whether they are booked or not.
No: 15
Statement: Both the student and admin user types shall be able to logout of the application
when activities have concluded via a clickable button in the application window.