From 6cf8184cf6b8296bf66be59fa33fc868f4e6d0c2 Mon Sep 17 00:00:00 2001
From: Matt Strapp <matt@mattstrapp.net>
Date: Wed, 6 Oct 2021 16:46:28 -0500
Subject: Start 5801a1

---
 csci5801/a1.tex | 87 +++++++++++++++++++++++++++++++++++++++++++++++----------
 1 file changed, 72 insertions(+), 15 deletions(-)

(limited to 'csci5801/a1.tex')

diff --git a/csci5801/a1.tex b/csci5801/a1.tex
index 3f8704f..d1cb861 100644
--- a/csci5801/a1.tex
+++ b/csci5801/a1.tex
@@ -21,6 +21,8 @@
 \usepackage[bookmarks=true]{hyperref}
 \usepackage[utf8]{inputenc}
 \usepackage[english]{babel}
+\usepackage{graphicx}
+\graphicspath{{./img/}}
 \def\myversion{1.0 }
 \date{}
 %\title{%
@@ -53,31 +55,31 @@
 
 \section{Purpose}
 
-$<$Identify the product whose software requirements are specified in this 
-document, including the revision or release number. Describe the scope of the 
-product that is covered by this SRS, particularly if this SRS describes only 
-part of the system or a single subsystem.$>$
+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}
-$<$Describe the different types of reader that the document is intended for, 
-such as developers, project managers, marketing staff, users, testers, and 
-documentation writers. Describe what the rest of this SRS contains and how it is 
-organized. Suggest a sequence for reading the document, beginning with the 
-overview sections and proceeding through the sections that are most pertinent to 
-each reader type.$>$
+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 the Minneapolis Municipal Parks and Recreation to organize 
-$<$Provide a short description of the software being specified and its purpose, 
-including relevant benefits, objectives, and goals. Relate the software to 
-corporate goals or business strategies. If a separate vision and scope document 
-is available, refer to it rather than duplicating its contents here.$>$
+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 Administation 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 
@@ -96,6 +98,25 @@ 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 as follows: \\
+Adminisrators:
+\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
+    \item Accept sponsorships
+\end{itemize}
+Officials:
+\begin{itemize}
+    \item Submit their availability to official games
+    \item View the schedule of games they need to attend
+\end{itemize}
+Coaches:
+\begin{itemize}
+    \item Create teams
+    \item 
+\end{itemize}
 $<$Identify the various user classes that you anticipate will use this product.  
 User classes may be differentiated based on frequency of use, subset of product 
 functions used, technical expertise, security or privilege levels, educational 
@@ -200,7 +221,43 @@ Include how the product should respond to anticipated error conditions or
 invalid inputs. Requirements should be concise, complete, unambiguous, 
 verifiable, and necessary. Use “TBD” as a placeholder to indicate when necessary 
 information is not yet available.$>$
+$<$This template illustrates organizing the functional requirements for the 
+product by system features, the major services provided by the product. You may 
+prefer to organize this section by use case, mode of operation, user class, 
+object class, functional hierarchy, or combinations of these, whatever makes the 
+most logical sense for your product.$>$
+
+\section{League Creation}
 
+\subsection{Description and Priority}
+
+
+\subsection{Stimulus/Response Sequences}
+$<$List the sequences of user actions and system responses that stimulate the 
+behavior defined for this feature. These will correspond to the dialog elements 
+associated with use cases.$>$
+
+\subsection{Functional Requirements}
+$<$Itemize the detailed functional requirements associated with this feature.  
+These are the software capabilities that must be present in order for the user 
+to carry out the services provided by the feature, or to execute the use case.  
+Include how the product should respond to anticipated error conditions or 
+invalid inputs. Requirements should be concise, complete, unambiguous, 
+verifiable, and necessary. Use “TBD” as a placeholder to indicate when necessary 
+information is not yet available.$>$
+
+$<$Each requirement should be uniquely identified with a sequence number or a 
+meaningful tag of some kind.$>$
+
+REQ-1:	REQ-2:
+
+\section{Team Creation}
+    
+    \subsection{Description and Priority}   
+        
+        \subsection{Stimulus/Response Sequences}    
+
+        \subsection{Functional Requirements}
 $<$Each requirement should be uniquely identified with a sequence number or a 
 meaningful tag of some kind.$>$
 
-- 
cgit v1.2.3

