Graduate

Signed-off-by: Matt Strapp <matt@mattstrapp.net>

5 files changed, 0 insertions, 853 deletions

diff --git a/OLD/csci5801/a1.tex b/OLD/csci5801/a1.tex
deleted file mode 100644
index c79ad75..0000000
--- a/OLD/csci5801/a1.tex
+++ /dev/null
@@ -1,266 +0,0 @@
-%Copyright 2014 Jean-Philippe Eisenbarth
-%This program is free software: you can 
-%redistribute it and/or modify it under the terms of the GNU General Public 
-%License as published by the Free Software Foundation, either version 3 of the 
-%License, or (at your option) any later version.
-%This program is distributed in the hope that it will be useful,but WITHOUT ANY 
-%WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A 
-%PARTICULAR PURPOSE. See the GNU General Public License for more details.
-%You should have received a copy of the GNU General Public License along with 
-%this program.  If not, see <http://www.gnu.org/licenses/>.
-
-%Based on the code of Yiannis Lazarides
-%http://tex.stackexchange.com/questions/42602/software-requirements-specification-with-latex
-%http://tex.stackexchange.com/users/963/yiannis-lazarides
-%Also based on the template of Karl E. Wiegers
-%http://www.se.rit.edu/~emad/teaching/slides/srs_template_sep14.pdf
-%http://karlwiegers.com
-\documentclass{scrreprt}
-\usepackage{listings}
-\usepackage{underscore}
-\usepackage[bookmarks=true]{hyperref}
-\usepackage[utf8]{inputenc}
-\usepackage[english]{babel}
-\usepackage{graphicx}
-\graphicspath{{./img/}}
-\def\myversion{1.0 }
-\date{}
-%\title{%
-
-%}
-\usepackage{hyperref}
-\begin{document}
-
-\begin{flushright}
-    \rule{16cm}{5pt}\vskip1cm
-    \begin{bfseries}
-        \Huge{SOFTWARE REQUIREMENTS\\ SPECIFICATION}\\
-        \vspace{1.9cm}
-        for\\
-        \vspace{1.9cm}
-        Sports League Administration Manager (SLAM)\\
-        \vspace{1.9cm}
-        Prepared by Matt Strapp\\
-        \vspace{1.9cm}
-        University of Minnesota\\
-        \vspace{1.9cm}
-        \today\\
-    \end{bfseries}
-\end{flushright}
-
-\tableofcontents
-
-
-\chapter{Introduction}
-
-\section{Purpose}
-
-The purpose is to provide a description for the Sports League Administration Manager (SLAM). It will explain the purposes, features, interfaces, and designed use cases for the system. This is intended for both the Minneapolis Parks and Recreation Board and the developers of the service.
-
-\section{Document Conventions}
-
-This Document made to comply with the IEEE Software Requirements Format.
-
-\section{Intended Audience and Reading Suggestions}
-This document is designed to be read by the developers creating and maintaining SLAM, the administrators at the Minneapolis Parks and Recreation Board, and the athletes, league administrators, coaches, and other interested parties.
-
-\section{Project Scope}
-SLAM will be used by Minneapolis Municipal Parks and Recreation to organize sports leagues throughout the city. The system will provide methods for creating, managing, and administering sports leagues as well as assign officials. The system will also allow coaches to create teams and add players to teams.
-
-
-\section{References}
-\noindent
-Sports League Administration Manager (SLAM) Software Requirements \\
-\noindent
-Sports League Administration Manager (SLAM) Use Cases
-
-\chapter{Overall Description}
-
-\section{Product Perspective}
-\includegraphics[width=\textwidth]{diagram} \\
-
-The Sports League Administration Manager is developed to organize a 
-$<$Describe the context and origin of the product being specified in this SRS.  
-For example, state whether this product is a follow-on member of a product 
-family, a replacement for certain existing systems, or a new, self-contained 
-product. If the SRS defines a component of a larger system, relate the 
-requirements of the larger system to the functionality of this software and 
-identify interfaces between the two. A simple diagram that shows the major 
-components of the overall system, subsystem interconnections, and external 
-interfaces can be helpful.$>$
-
-\section{Product Functions}
-$<$Summarize the major functions the product must perform or must let the user 
-perform. Details will be provided in Section 3, so only a high level summary 
-(such as a bullet list) is needed here. Organize the functions to make them 
-understandable to any reader of the SRS. A picture of the major groups of 
-related requirements and how they relate, such as a top level data flow diagram 
-or object class diagram, is often effective.$>$
-
-\section{User Classes and Characteristics}
-The system is divided into four users: administrators, officials, coaches, and the public. The roles are defined below.
-\begin{itemize}
-    \item Administrators:
-    \begin{itemize}
-        \item Create and manage leagues
-        \item Create and manage league and tournament schedules 
-        \item Generate user statistics on demand
-        \item Assign officials to leagues and games
-    \end{itemize}
-\end{itemize}
-Administrators include Staff members and the Parks and Recreation Organizer.  They have the highest privilege level. Administrators are the ones in charge of creating leagues, scheduling games, and assigning officials. They also are the users that create statistics and deal with finances.
-\begin{itemize}
-    \item Officials:
-    \begin{itemize}
-        \item Submit their availability to official games
-        \item Accept or reject games to officiate
-        \item View the schedule of games they need to attend
-        \item Submit scores when game is complete
-    \end{itemize}
-\end{itemize}
-Officials are responsible for submitting scores when games are over. They also are responsible for submitting their schedules so all games played have a sufficient number of officials.
-\begin{itemize}
-    \item Coaches:
-    \begin{itemize}
-        \item Create teams
-        \item Add athletes to teams
-    \end{itemize}
-\end{itemize}
-Coaches are responsible for creating teams and adding athletes to teams.
-\begin{itemize}
-    \item Athletes, the Public:
-    \begin{itemize}
-        \item View schedule
-    \end{itemize}
-\end{itemize}
-Athletes and other end users need to be able to view the schedule of games they plan on attending or playing in.
-
-\section{Assumptions and Dependencies}
-
-It is assumed that an external database and interface already exist.
-
-\chapter{System Features}
-
-\section{League Creation}
-
-\subsection{Description and Priority}
-The system shall allow administrators to create leagues for sports. The system will list sports to create a league for and the user will select the sport. The system will then list the leagues that are available for the sport and the user will select the league.
-
-\subsection{Stimulus/Response Sequences}
-A user must be logged in as an administrator to be able to create a league. The user submits the sport they want to create a league for and the system will respond by verifying the response and creating a new league if the response is valid.
-
-\subsection{Functional Requirements}
-REQ-101: The system shall list all sports that leagues can be created for. \\
-REQ-102: The system shall validate the user input. \\
-REQ-103: The system shall return an error if the user tries to create a league for a sport that does not exist or is no longer allowing league creation. \\
-REQ-104: The system shall create the league after verifying the input. \\
-\indent Valid sports are as follows: Sand Volleyball, Kickball, Indoor Soccer, Softball, Outdoor Soccer, Tennis, Flag Football, Fall Soccer, Dodgeball, Indoor Volleyball, Fall Kickball, Fall Softball, Basketball, Broomball, and Pond Hockey.
-
-
-\section{Schedule Generation}
-
-\subsection{Description and Priority}
-The system shall allow administrators to create schedules for leagues.
-
-\subsection{Stimulus/Response Sequences}
-A user must be signed in as an administrator. The user supplies a beginning and ending date for the schedule and the system will generate a schedule for the league.
-
-\subsection{Functional Requirements}
-
-REQ-201: The user must specify a start and end date for the league. \\
-REQ-202: The system shall verify the dates. The verification process is TBD.
-REQ-203: The system shall generate a valid schedule for the league provided between the dates provided. The verification process for this is TBD.\\
-REQ-204: The system shall return an error if the dates are invalid. \\
-REQ-205: The system shall return an error if it cannot generate a schedule for the league.
-REQ-206: The system shall return a valid generated schedule after it has validated the inputs. What constitutes a valid schedule is TBD. \\
-
-\section{Team Creation}
-    
-    \subsection{Description and Priority}   
-    The system shall allow coaches and administrators to register teams.
-    \subsection{Stimulus/Response Sequences}    
-    A user must be signed in as a coach or administrator. The user supplies the name of the team and the system will create the team. The user must supply a valid roster and the league they want to register the team for.
-    \subsection{Functional Requirements}
-    REQ-301: The system shall validate the number of team members and return an error if the team is too small for the sport. \\
-    REQ-302: The system shall validate the team name and return an error if the team name is invalid. What constitutes an invalid team name is TBD. \\
-    REQ-303: The system shall create a team with the supplied roster and name and add it to the database.
-
-\section{Roster Editing}
-  
-    \subsection{Description and Priority}   
-    The system shall allow coaches and administrators to edit rosters.
-        \subsection{Stimulus/Response Sequences}    
-    A user must be signed in as a coach or administrator. The user submits the change that they want to make to the roster. The system responds by changing the roster as requested.
-        \subsection{Functional Requirements}
-    REQ-401: The system shall return an error if the user does not have permission to edit that team's roster. \\
-    REQ-402: The system shall return an error if the user tries to edit a team that does not exist. \\
-    REQ-403: The system shall change the roster as requested if the user has permission to edit that team's roster.
-\section{Generate Statistics}
-
-    \subsection{Description and Priority}
-    The system shall allow administrators to generate statistics.
-    \subsection{Stimulus/Response Sequences}
-    A user must be signed in as an administrator. The user submits the type of statistics they want to generate. The system will generate the statistics asked.
-    \subsection{Functional Requirements}
-    REQ-501: The system shall return an error if the user tries to generate statistics for a sport, league or player that does not exist. \\
-    REQ-502: The system shall generate the statistics and display them to the user when generated.
-
-\section{Assign Officials}
-    \subsection{Description and Priority}
-    The system shall allow administrators to assign officials to leagues and games.
-    \subsection{Stimulus/Response Sequences}
-    A user must be signed in as an administrator. The user submits the league and game they want to assign officials to. The system will assign the officials to the game based on the schedule given by the officials.
-    \subsection{Functional Requirements}
-    REQ-601: The system shall return an error if the user tries to assign officials to a league or game that does not exist. \\
-    REQ-602: The system shall return an error if no officials can be found for a game. \\
-    REQ-603: The system shall assign the officials to the game and publish the schedule so the officals can see what games they need to officiate.
-
-\section{Submit Scores}
-    \subsection{Description and Priority}
-    The system shall allow officials to submit scores for games they officiate.
-    \subsection{Stimulus/Response Sequences}
-    A user must be signed in as an official. The user submits the score for the game they are officiating.
-    \subsection{Functional Requirements}
-    REQ-701: The system shall return an error if the user tries to submit a score for a game that does not exist. \\
-    REQ-702: The system shall return an error if the user tries to submit a score for a game that is not officiating. \\
-    REQ-703: The system shall submit the score to the database and publish it to an external site after the submission is complete. \\
-    REQ-704: The system shall allow administrators to change scores if they contradict the official's reported scores.
-
-    
-    \section{Generate Bracket}
-    \subsection{Description and Priority}
-    The system shall allow administrators to generate brackets for leagues.
-    \subsection{Stimulus/Response Sequences}
-    A user must be signed in as an administrator. The user submits the league they want to generate a bracket for. The system will generate the bracket along with the dates for the games. \\
-    This requirement is built off of requirement 2.
-    \subsection{Functional Requirements}
-    REQ-801: The system shall return an error if the user tries to generate a bracket for a league that does not exist. \\
-    REQ-802: The system shall generate the bracket and proceed to generate the schedule according to Requirement 2. \\
-    REQ-803: The system shall return an error if the system cannot generate the bracket requested. \\
-    
-    \section{View Schedules}
-    \subsection{Description and Priority}
-    The system shall allow users to view schedules for leagues.
-    \subsection{Stimulus/Response Sequences}
-    Any user can access the schedule for a league. They do not have to be signed in to view the public schedules. Officals can view the schedule for a league they are officiating and administrators can view any schedule for any league.
-    \subsection{Functional Requirements}
-    REQ-901: The system shall return an error if the user tries to view a schedule for a league that does not exist. \\
-    REQ-902: The system shall return an error if an unauthenticated user tries to view a schedule for a league that is not public. \\
-    REQ-903: The system shall return an error if an authenticated user tries to view a schedule for a league that they do not have permission to access. \\
-    REQ-904: The system shall return the schedule for the league requested.
-
-
-\section{Appendix A: Glossary}
-%see https://en.wikibooks.org/wiki/LaTeX/Glossary
-SLAM: The Sports League Administration Manager
-Staff: The people who run the league, working for the Municipal Parks and Recreation Department.
-Administrators: People with administrative privileges.
-Officals: People who officiate games.
-Coaches: People who create teams.
-Athletes: People who play in the leagues.
-The Public: Everyone else.
-
-
-\section{Appendix B: To Be Determined List}
-TODO: specifications, testing, the rest of the document
-\end{document}
\ No newline at end of file
diff --git a/OLD/csci5801/a1_usecase.tex b/OLD/csci5801/a1_usecase.tex
deleted file mode 100644
index 1856efb..0000000
--- a/OLD/csci5801/a1_usecase.tex
+++ /dev/null
@@ -1,474 +0,0 @@
-%% Use Cases Template File
-%% Created by Tom Desair (http://www.tomdesair.com)
-%% Downloadable at: http://www.tomdesair.com/downloads/use-case-latex-template.zip
-%% Date Modified: 03/04/2012
-%
-% This work may be distributed and/or modified under the
-% conditions of the LaTeX Project Public License, either version 1.3
-% of this license or (at your option) any later version.
-% The latest version of this license is in
-%   http://www.latex-project.org/lppl.txt
-% and version 1.3 or later is part of all distributions of LaTeX
-% version 2005/12/01 or later.
-
-\documentclass[a4paper, 10pt, oneside, draft]{article}
-
-%include the usecases package
-\usepackage{usecases}
-
-\begin{document}
-
-%Sometimes it is a good idea to put domain objects in \texttt{}
-%The template and the descriptions are based on the book Applying UML and Patterns: 
-%An Introduction to Object-Oriented Analysis and Design and Iterative Development
-%(3rd Edition) by Craig Larman.
-\begin{usecase}
-
-\addtitle{Use Case 1}{Creating a League} 
-
-%Scope: the system under design
-\addfield{Scope:}{System-wide}
-
-%Level: "user-goal" or "subfunction"
-\addfield{Level:}{User-goal}
-
-%Primary Actor: Calls on the system to deliver its services.
-\addfield{Primary Actor:}{Administrator}
-
-\addfield{Trigger:}{An administrator wants to create a new league.}
-
-%Preconditions: What must be true on start and worth telling the reader?
-\addfield{Preconditions:}{The user must be signed in as an administrator.}
-%when multiple
-%\additemizedfield{Preconditions:}{} 
-
-%Postconditions: What must be true on successful completion and worth telling the reader
-\addfield{Postconditions:}{The league will be created.}
-%when multiple
-%\additemizedfield{Preconditions:}{}
-
-%Main Success Scenario: A typical, unconditional happy path scenario of success.
-\addscenario{Main Success Scenario:}{
-	\item The administrator creates a new league.
-	\item The league is created
-}
-
-%Extensions: Alternate scenarios of success or failure.
-\addscenario{Extensions:}{
-	\item[1.a] The user is not an administrator:
-		\begin{enumerate}
-		\item[1.] System shows permission denied
-		\item[2.] User returns to login page
-		\end{enumerate}
-	\item[2.a] The league cannot be created:
-		\begin{enumerate}
-		\item[1.] System shows failure message
-		\item[2.] User returns to step 1
-		\end{enumerate}
-}
-\end{usecase}
-\pagebreak
-\begin{usecase}
-	
-\addtitle{Use Case 2}{Creating a Team}
-
-%Scope: the system under design
-\addfield{Scope:}{System-wide}
-
-%Level: "user-goal" or "subfunction"
-\addfield{Level:}{User-goal}
-
-%Primary Actor: Calls on the system to deliver its services.
-\addfield{Primary Actor:}{Coach}
-
-\addfield{Trigger:}{A coach wants to create a new team.}
-
-%Preconditions: What must be true on start and worth telling the reader?
-\addfield{Preconditions:}{The user must be signed in as a coach.}
-%when multiple
-%\additemizedfield{Preconditions:}{}
-
-%Postconditions: What must be true on successful completion and worth telling the reader
-% \addfield{Postconditions:}{The team will be created.}
-%when multiple
-\additemizedfield{Preconditions:}{\item The user must be signed in as a coach \item A league must already exist}
-
-
-%Main Success Scenario: A typical, unconditional happy path scenario of success.
-\addscenario{Main Success Scenario:}{
-	\item[1] The coach creates a new team.
-	\item[2] The team is created
-}
-
-%Extensions: Alternate scenarios of success or failure.
-\addscenario{Extensions:}{
-	\item[1.a] The user is not a coach:
-		\begin{enumerate}
-		\item[1.] System shows permission denied
-		\item[2.] User returns to login page
-		\end{enumerate}
-	\item[2.a] The team cannot be created:
-		\begin{enumerate}
-		\item[1.] System shows failure message
-		\item[2.] User returns to step 1
-		\end{enumerate}
-	\item[3.b] The league does not exist:
-		\begin{enumerate}
-		\item[1.] System shows failure message
-		\item[2.] The user returns to step 1
-		\end{enumerate} 
-}
-
-
-\end{usecase}
-
-\pagebreak
-
-\begin{usecase}
-	
-\addtitle{Use Case 3}{Generating a Schedule}
-
-%Scope: the system under design
-\addfield{Scope:}{System-wide}
-
-%Level: "user-goal" or "subfunction"
-\addfield{Level:}{User-goal}
-
-%Primary Actor: Calls on the system to deliver its services.
-\addfield{Primary Actor:}{Administrator}
-
-\addfield{Trigger:}{An administrator wants to generate a schedule.}
-
-%Preconditions: What must be true on start and worth telling the reader?
-\additemizedfield{Preconditions:}{\item The user must be singed in as an administrator \item A league must already exist}
-
-%Postconditions: What must be true on successful completion and worth telling the reader
-\addfield{Postconditions:}{The schedule will be generated.}
-
-%Main Success Scenario: A typical, unconditional happy path scenario of success.
-\addscenario{Main Success Scenario:}{
-	\item The administrator selects a league to generate a schedule for.
-	\item The administrator generates a schedule.
-	\item The schedule is generated.
-}
-
-%Extensions: Alternate scenarios of success or failure.
-\addscenario{Extensions:}{
-	\item[1.a] The user is not an administrator:
-		\begin{enumerate}
-		\item[1.] System shows permission denied
-		\item[2.] User returns to login page
-		\end{enumerate}
-	\item[2.a] The league does not exist:
-		\begin{enumerate}
-		\item[1.] System shows failure message
-		\item[2.] User returns to step 1
-		\end{enumerate} 
-	\item[3.a] The league does not have any teams:
-		\begin{enumerate}
-		\item[1.] System shows failure message
-		\item[2.] User returns to step 1
-		\end{enumerate}
-	\item[3.b] The schedule fails to be created:
-		\begin{enumerate}
-		\item[1.] System shows failure message
-		\item[2.] User returns to step 1
-		\end{enumerate}
-}
-
-\end{usecase}
-
-\pagebreak
-
-\begin{usecase}
-	
-\addtitle{Use Case 4}{Generating Statistics}
-
-
-%Scope: the system under design
-\addfield{Scope:}{System-wide}
-
-%Level: "user-goal" or "subfunction"
-\addfield{Level:}{User-goal}
-
-%Primary Actor: Calls on the system to deliver its services.
-\addfield{Primary Actor:}{Administrator}
-
-\addfield{Trigger:}{An administrator wants to generate statistics.}
-
-%Preconditions: What must be true on start and worth telling the reader?
-\additemizedfield{Preconditions:}{\item The user must be singed in as an administrator \item A league must already exist}
-
-%Postconditions: What must be true on successful completion and worth telling the reader
-\addfield{Postconditions:}{The statistics will be generated.}
-
-%Main Success Scenario: A typical, unconditional happy path scenario of success.
-\addscenario{Main Success Scenario:}{
-	\item The administrator selects a league to generate statistics for.
-	\item The administrator generates statistics.
-	\item The statistics are generated.
-}
-
-%Extensions: Alternate scenarios of success or failure.
-\addscenario{Extensions:}{
-	\item[1.a] The user is not an administrator:
-		\begin{enumerate}
-		\item[1.] System shows permission denied
-		\item[2.] User returns to login page
-		\end{enumerate}
-	\item[1.b] The league does not exist:
-		\begin{enumerate}
-		\item[1.] System shows failure message
-		\item[2.] User returns to step 1
-		\end{enumerate} 
-	\item[3.a] The league does not have any teams:
-		\begin{enumerate}
-		\item[1.] System shows failure message
-		\item[2.] User returns to step 1
-		\end{enumerate}
-	\item[3.b] The statistics fail to be generated:
-		\begin{enumerate}
-		\item[1.] System shows failure message
-		\item[2.] User returns to step 1
-		\end{enumerate}
-}
-
-\end{usecase}
-
-\pagebreak
-
-\begin{usecase}
-	
-\addtitle{Use Case 5}{Assign Officials}
-
-%Scope: the system under design
-\addfield{Scope:}{System-wide}
-
-%Level: "user-goal" or "subfunction"
-\addfield{Level:}{User-goal}
-
-%Primary Actor: Calls on the system to deliver its services.
-\addfield{Primary Actor:}{Administrator}
-
-\addfield{Trigger:}{An administrator wants to assign officials.}
-
-%Preconditions: What must be true on start and worth telling the reader?
-\additemizedfield{Preconditions:}{\item The user must be singed in as an administrator \item A league must already exist \item Officials must already exist for the league}
-
-
-%Postconditions: What must be true on successful completion and worth telling the reader
-\addfield{Postconditions:}{The officials will be assigned.}
-
-%Main Success Scenario: A typical, unconditional happy path scenario of success.
-\addscenario{Main Success Scenario:}{
-	\item The administrator selects a league to assign officials to.
-	\item The administrator assigns officials.
-	\item The officials are assigned.
-}
-
-%Extensions: Alternate scenarios of success or failure.
-\addscenario{Extensions:}{
-	\item[1.a] The user is not an administrator:
-		\begin{enumerate}
-		\item[1.] System shows permission denied
-		\item[2.] User returns to login page
-		\end{enumerate}
-	\item[2.a] The league does not exist:
-		\begin{enumerate}
-		\item[1.] System shows failure message
-		\item[2.] User returns to step 1
-		\end{enumerate} 
-	\item[3.a] There are no eligible officials:
-		\begin{enumerate}
-		\item[1.] System shows failure message
-		\item[2.] User returns to step 1
-		\end{enumerate}
-	\item[3.b] An unknown error occurs:
-		\begin{enumerate}
-		\item[1.] System shows failure message
-		\item[2.] User returns to step 1
-		\end{enumerate}
-}
-
-\end{usecase}
-
-\pagebreak
-
-
-\begin{usecase}
-	
-\addtitle{Use Case 6}{Generate Bracket}
-
-%Scope: the system under design
-\addfield{Scope:}{System-wide}
-
-%Level: "user-goal" or "subfunction"
-\addfield{Level:}{User-goal}
-
-%Primary Actor: Calls on the system to deliver its services.
-\addfield{Primary Actor:}{Administrator}
-
-\addfield{Trigger:}{An administrator wants to generate a bracket.}
-
-%Preconditions: What must be true on start and worth telling the reader?
-\additemizedfield{Preconditions:}{\item The user must be singed in as an administrator \item A league must already exist}
-
-%Postconditions: What must be true on successful completion and worth telling the reader
-\addfield{Postconditions:}{The bracket will be generated and a schedule will be created.}
-
-
-%Main Success Scenario: A typical, unconditional happy path scenario of success.
-\addscenario{Main Success Scenario:}{
-	\item The administrator selects a league to generate a bracket for.
-	\item The administrator generates a bracket.
-	\item The bracket is generated.
-	\item A schedule is created from the bracket, following Use Case 3.
-}
-
-%Extensions: Alternate scenarios of success or failure.
-\addscenario{Extensions:}{
-	\item[1.a] The user is not an administrator:
-		\begin{enumerate}
-		\item[1.] System shows permission denied
-		\item[2.] User returns to login page
-		\end{enumerate}
-	\item[2.a] The league does not exist:
-		\begin{enumerate}
-		\item[1.] System shows failure message
-		\item[2.] User returns to step 1
-		\end{enumerate} 
-	\item[3.a] The league does a cleanly divisible number of teams:
-		\begin{enumerate}
-		\item[1.] System shows failure message
-		\item[2.] User returns to step 1
-		\end{enumerate}
-	\item[3.b] The schedule fails to be created:
-		\begin{enumerate}
-		\item[1.] System shows failure message
-		\item[2.] User returns to step 1
-		\end{enumerate}
-	\item[4.b] A bracket is manually generated
-		\begin{enumerate}
-		\item[1.] The system follows all steps except step 5
-		\item[2.] The schedule is created
-		\end{enumerate}
-}
-\end{usecase}
-
-\pagebreak
-
-\begin{usecase}
-	
-\addtitle{Use Case 7}{Submit Scores}
-
-%Scope: the system under design
-\addfield{Scope:}{System-wide}
-
-%Level: "user-goal" or "subfunction"
-\addfield{Level:}{User-goal}
-
-%Primary Actor: Calls on the system to deliver its services.
-\addfield{Primary Actor:}{Official}
-
-\addfield{Trigger:}{An official wants to submit scores for a game they officiated.}
-
-%Preconditions: What must be true on start and worth telling the reader?
-\additemizedfield{Preconditions:}{\item The user must be singed in as an official \item A league must already exist \item A schedule must already exist \item A game must already exist \item The user must have permission to submit scores for that game}
-
-
-%Postconditions: What must be true on successful completion and worth telling the reader
-\addfield{Postconditions:}{The scores will be submitted.}
-
-%Main Success Scenario: A typical, unconditional happy path scenario of success.
-\addscenario{Main Success Scenario:}{
-	\item The official selects a game to submit scores for.
-	\item The official submits scores.
-	\item The scores are submitted.
-}
-
-%Extensions: Alternate scenarios of success or failure.
-\addscenario{Extensions:}{
-	\item[1.a] The user is not an official:
-		\begin{enumerate}
-		\item[1.] System shows permission denied
-		\item[2.] User returns to login page
-		\end{enumerate}
-		\item[1.b] An administrator:
-		\begin{enumerate}
-		\item[1.] System shows failure message
-		\item[2.] User returns to step 1
-		\end{enumerate}
-	\item[2.a] The league does not exist:
-		\begin{enumerate}
-		\item[1.] System shows failure message
-		\item[2.] User returns to step 1
-		\end{enumerate} 
-	\item[2.b] The schedule does not exist:
-		\begin{enumerate}
-		\item[1.] System shows failure message
-		\item[2.] User returns to step 1
-		\end{enumerate}
-	\item[2.c] The game does not exist:
-		\begin{enumerate}
-		\item[1.] System shows failure message
-		\item[2.] User returns to step 1
-		\end{enumerate}
-	\item[2.d] The user does not have permission to submit scores for that game:
-		\begin{enumerate}
-		\item[1.] System shows permission denied
-		\item[2.] User returns to step 1
-		\end{enumerate}
-	
-}
-\end{usecase}
-
-\pagebreak
-
-
-\begin{usecase}
-	
-\addtitle{Use Case 8}{View Schedule}
-
-%Scope: the system under design
-\addfield{Scope:}{System-wide}
-
-%Level: "user-goal" or "subfunction"
-\addfield{Level:}{User-goal}
-
-%Primary Actor: Calls on the system to deliver its services.
-\addfield{Primary Actor:}{End User}
-
-\addfield{Trigger:}{An end user wants to view a schedule.}
-
-
-%Preconditions: What must be true on start and worth telling the reader?
-\additemizedfield{Preconditions:}{ \item A schedule must already exist \item If the schedule is not public the user must be signed in}
-
-%Postconditions: What must be true on successful completion and worth telling the reader
-\addfield{Postconditions:}{The schedule will be displayed.}
-
-%Main Success Scenario: A typical, unconditional happy path scenario of success.
-\addscenario{Main Success Scenario:}{
-	\item The user selects a league to view a schedule for.
-	\item The schedule is displayed.
-}
-
-%Extensions: Alternate scenarios of success or failure.
-\addscenario{Extensions:}{
-	\item[1.a] The schedule is not public:
-		\begin{enumerate}
-		\item[1.] System shows failure message
-		\item[2.] User returns to step 1
-		\end{enumerate}
-		\item[2.a] The schedule does not exist:
-		\begin{enumerate}
-		\item[1.] System shows failure message
-		\item[2.] User returns to step 1
-		\end{enumerate}
-}
-\end{usecase}
-
-
-
-\end{document}
-
diff --git a/OLD/csci5801/a4.tex b/OLD/csci5801/a4.tex
deleted file mode 100644
index 3b26835..0000000
--- a/OLD/csci5801/a4.tex
+++ /dev/null
@@ -1,49 +0,0 @@
-\documentclass{article}
-\pagenumbering{gobble}
-\begin{document}
-\section{Elicitation Session}
-    \subsection{What did you learn from the elicitation session? What parts worked well? What parts did not work well?}
- The main thing to learn from the elicitation session should have been rather obvious: not everyone knows everything. Sometimes if you ask a question the customer simply does not know the answer. The main thing that did not work well was the very large number of groups potentially wasting time by having groups not show up.
-    \subsection{How might you prepare differently for a similar experience in the future, where you may only have one chance to meet and talk with the user(s)?}
- The easiest way to prepare for the next session is to have even more questions beforehand and set them by priority. Our group had questions, but did not have them sorted by priority. Sorting them by priority would allow important questions to be answered first and less important questions to be answered later if at all.
-    \subsection{When is asking the same question twice bad/unhelpful? When is asking the same question twice good/helpful?}
-The only time asking the same question is helpful is if you ask two completely different people, because then you do not waste time getting the same answer twice. Any other time would only waste valuable time that could better be used for different questions.
-
-\section{Individual Requirements}
-    \subsection{How well did capturing the requirements go?}
- Capturing requirements was straightforward for the most part. Trying to balance between being too specific and too vague was the most difficult part.
-    \subsection{How did you approach user statements/requirements which were vague or ambiguous?}
- The way I dealt with it was by attempting to make the requirement surrounding the vagary as general as possible. If the requirement needs to be tweaked to make it more specific, it can be done more easily than making something less specific.
-    \subsection{How did you approach user statements/requirements which were contradictory?}
- This did not happen when writing my requirements.
-    \subsection{Did you follow a template? Did the template help or hurt your efforts? Why?}
-The IEEE \LaTeX template made everything significantly easier to format, since dealing with Microsoft Word's and other WYSIWYG formatting has been ruled as illegal by the Geneva Conventions. The template also helped by suggesting what should be in each section, reducing time spent looking up something not talked about in class or potentially vague.
-
-\section{Team Requirements}
-    \subsection{Did you encounter any situations where you and your teammates disagreed on the definitions or process? What caused that ambiguity? What could you do next time to avoid it? If your team faced no disagreements, explain how you worked together to build the requirements to avoid them.}
-The main problem with group work is schedules. The more people you have to get together, the less time that works for everyone. The way this was mitigated was either making meetings short or filling the member not present in after the others met.
-
-\section{Final Spec and Testing}
-    \subsection{What kinds of assumptions will be necessary to ensure that meeting the specification (verification) means that you have also met the requirements (validation)?}
- The main assumption is that the external requirements (databases, etc.) are written in a way that the tests will still work.
-    \subsection{How did you translate the requirements to specification?}
- The way to turn a requirement into a specification is to take the requirement and make it more technical. Requirements are meant more for the customer, so writing specifications are meant to be more technical.
-    \subsection{What was the most difficult aspect of writing your test cases?}
- The main thing is knowing how many test cases to write. Writing too many will be time consuming on implementation while too few potentially adds places where bugs can sneak in.
-    \subsection{Did writing your test cases help you find issues in your requirements? If so, what did you find and how did test case writing help you find/fix it? If not, what kinds of work effort (man-hours/financial) is going to be necessary to implement your tests? Explain.}
- Writing some test cases showed that some of our requirements were redundant. Reducing requirements will be easier to implement, since large and unwieldy requirements documents are more likely to breed failure.
-    \subsection{How brittle are your tests? What kinds of changes could break them (provide concrete examples)?}
-    The main thing that could break the tests would be any potential API changes that would happen to the external back end. The database is assumed to work one way and provide specific items, so if those cannot be obtained anymore some tests would need to be rewritten.
-
-
-\section{Misc.}
-    \subsection{What were the most difficult parts of writing the SRS (including Assignments 1-3 in your thoughts)?}
- The most difficult part is balancing what to write and what to not write. An excessive document is unwieldy and difficult to read, while a short one is likely missing vital information that could potentially cause the system to fail.
-    \subsection{What additional experience or training would be helpful for next time?}
- The most likely experience needed would be a better way to write requirements and use cases from vague information. Thinking of requirements that may or may not be needed is a massive time sink.
-    \subsection{How sure are you that the specification you wrote meets the requirements? If you are confident that it does, what specifically gives you that confidence? If you are not confident, what would you do to fix that, and how do you know when to stop?}
- I am somewhat confident our specifications meet our requirements. We added all of our requirements together and we all checked over our specifications, so multiple eyes saw the document.
-    \subsection{What are the greatest risks in your SRS? What are the likely things that will go wrong? What makes them risky?}
- The greatest risk to this or any requirement is that the customer's needs change. If the customer's needs change, the requirements will need to be updated. Updated requirements once again eat into valuable time that could be spent implementing and optimizing the system.
-
-\end{document}
\ No newline at end of file
diff --git a/OLD/csci5801/img/diagram.png b/OLD/csci5801/img/diagram.png
deleted file mode 100644
index 06ca502..0000000
--- a/OLD/csci5801/img/diagram.png
+++ /dev/null
diff --git a/OLD/csci5801/usecases.sty b/OLD/csci5801/usecases.sty
deleted file mode 100644
index c31fd51..0000000
--- a/OLD/csci5801/usecases.sty
+++ /dev/null
@@ -1,64 +0,0 @@
-%% Use Cases Style File
-%% Created by Tom Desair (http://www.tomdesair.com)
-%% Downloadable at: http://www.tomdesair.com/downloads/use-case-latex-template.zip
-%% Date Modified: 03/04/2012
-%
-% This work may be distributed and/or modified under the
-% conditions of the LaTeX Project Public License, either version 1.3
-% of this license or (at your option) any later version.
-% The latest version of this license is in
-%   http://www.latex-project.org/lppl.txt
-% and version 1.3 or later is part of all distributions of LaTeX
-% version 2005/12/01 or later.
-
-%-------------------------------------------------------------------------------
-%                Required Packages
-%-------------------------------------------------------------------------------
-\usepackage{booktabs}
-\usepackage{multirow}
-\usepackage{longtable}
-
-%-------------------------------------------------------------------------------
-%                \addtitle command: add the title of the use case
-%-------------------------------------------------------------------------------
-\newcommand\addtitle[2]{\hline \\ [-1.5ex] \textbf{#1} &\textbf{#2}\\ [1ex] \hline \\ [-1.5ex]}
-\newcommand\tabularhead{\begin{longtable}{lp{8.9cm}}
-}
-
-%-------------------------------------------------------------------------------
-%                \addfield command: add a property of the use case
-%-------------------------------------------------------------------------------
-\newcommand\addfield[2]{\textit{#1} &#2\\ [1ex] \hline \\ [-1.3ex] }
-
-%-------------------------------------------------------------------------------
-%                \addscenario command: add the main (or alternative) scenario
-%                of the use case
-%-------------------------------------------------------------------------------
-\newcommand\addscenario[2]{ 
-\multicolumn{2}{l}{\textit{#1}} \\
-\multicolumn{2}{l}{
-\begin{minipage}[t]{13.2cm}
-    \begin{enumerate} #2   \end{enumerate}
-    \vspace{1.3ex}
-\end{minipage}
-} \\ [1ex] \hline \\ [-1.5ex] }
-
-%-------------------------------------------------------------------------------
-%                \additemizedfield command: add a field with an item list
-%-------------------------------------------------------------------------------
-\newcommand\additemizedfield[2]{ 
-	\begin{minipage}[t][][t]{3.5cm}
-		\textit{#1}
-		\vspace{1.3ex}
-	\end{minipage}% 
-   &
-    \begin{minipage}[t][][t]{8.9cm}
-    	\begin{itemize} #2   \end{itemize}
-    	\vspace{1.5ex}
-    \end{minipage}\\ [1ex] \hline \\ [-1.5ex] }
-
-%-------------------------------------------------------------------------------
-%                Definition of the use case environment
-%-------------------------------------------------------------------------------
-\newenvironment{usecase}{\tabularhead}
-{\end{longtable}}