aboutsummaryrefslogtreecommitdiffstats
path: root/csci5801
diff options
context:
space:
mode:
authorMatt Strapp <matt@mattstrapp.net>2021-10-06 11:58:57 -0500
committerMatt Strapp <matt@mattstrapp.net>2021-10-06 11:58:57 -0500
commitdeb0f1787367437852825c09c09ad225b9b1b49b (patch)
tree4406db63f11512c987ce1553ab0acfef8ad097fb /csci5801
parentfinish hw (diff)
downloadhomework-deb0f1787367437852825c09c09ad225b9b1b49b.tar
homework-deb0f1787367437852825c09c09ad225b9b1b49b.tar.gz
homework-deb0f1787367437852825c09c09ad225b9b1b49b.tar.bz2
homework-deb0f1787367437852825c09c09ad225b9b1b49b.tar.lz
homework-deb0f1787367437852825c09c09ad225b9b1b49b.tar.xz
homework-deb0f1787367437852825c09c09ad225b9b1b49b.tar.zst
homework-deb0f1787367437852825c09c09ad225b9b1b49b.zip
add templates
Signed-off-by: Matt Strapp <matt@mattstrapp.net>
Diffstat (limited to '')
-rw-r--r--csci5801/a1.tex282
-rw-r--r--csci5801/usecase-template.tex94
2 files changed, 376 insertions, 0 deletions
diff --git a/csci5801/a1.tex b/csci5801/a1.tex
new file mode 100644
index 0000000..3f8704f
--- /dev/null
+++ b/csci5801/a1.tex
@@ -0,0 +1,282 @@
+%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}
+\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}
+
+$<$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.$>$
+
+\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.$>$
+
+\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.$>$
+
+
+
+\chapter{Overall Description}
+
+\section{Product Perspective}
+$<$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}
+$<$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
+level, or experience. Describe the pertinent characteristics of each user class.
+Certain requirements may pertain only to certain user classes. Distinguish the
+most important user classes for this product from those who are less important
+to satisfy.$>$
+
+\section{Operating Environment}
+$<$Describe the environment in which the software will operate, including the
+hardware platform, operating system and versions, and any other software
+components or applications with which it must peacefully coexist.$>$
+
+\section{Design and Implementation Constraints}
+$<$Describe any items or issues that will limit the options available to the
+developers. These might include: corporate or regulatory policies; hardware
+limitations (timing requirements, memory requirements); interfaces to other
+applications; specific technologies, tools, and databases to be used; parallel
+operations; language requirements; communications protocols; security
+considerations; design conventions or programming standards (for example, if the
+customer’s organization will be responsible for maintaining the delivered
+software).$>$
+
+\section{User Documentation}
+$<$List the user documentation components (such as user manuals, on-line help,
+and tutorials) that will be delivered along with the software. Identify any
+known user documentation delivery formats or standards.$>$
+\section{Assumptions and Dependencies}
+
+$<$List any assumed factors (as opposed to known facts) that could affect the
+requirements stated in the SRS. These could include third-party or commercial
+components that you plan to use, issues around the development or operating
+environment, or constraints. The project could be affected if these assumptions
+are incorrect, are not shared, or change. Also identify any dependencies the
+project has on external factors, such as software components that you intend to
+reuse from another project, unless they are already documented elsewhere (for
+example, in the vision and scope document or the project plan).$>$
+
+
+\chapter{External Interface Requirements}
+
+\section{User Interfaces}
+$<$Describe the logical characteristics of each interface between the software
+product and the users. This may include sample screen images, any GUI standards
+or product family style guides that are to be followed, screen layout
+constraints, standard buttons and functions (e.g., help) that will appear on
+every screen, keyboard shortcuts, error message display standards, and so on.
+Define the software components for which a user interface is needed. Details of
+the user interface design should be documented in a separate user interface
+specification.$>$
+
+\section{Hardware Interfaces}
+$<$Describe the logical and physical characteristics of each interface between
+the software product and the hardware components of the system. This may include
+the supported device types, the nature of the data and control interactions
+between the software and the hardware, and communication protocols to be
+used.$>$
+
+\section{Software Interfaces}
+$<$Describe the connections between this product and other specific software
+components (name and version), including databases, operating systems, tools,
+libraries, and integrated commercial components. Identify the data items or
+messages coming into the system and going out and describe the purpose of each.
+Describe the services needed and the nature of communications. Refer to
+documents that describe detailed application programming interface protocols.
+Identify data that will be shared across software components. If the data
+sharing mechanism must be implemented in a specific way (for example, use of a
+global data area in a multitasking operating system), specify this as an
+implementation constraint.$>$
+
+\section{Communications Interfaces}
+$<$Describe the requirements associated with any communications functions
+required by this product, including e-mail, web browser, network server
+communications protocols, electronic forms, and so on. Define any pertinent
+message formatting. Identify any communication standards that will be used, such
+as FTP or HTTP. Specify any communication security or encryption issues, data
+transfer rates, and synchronization mechanisms.$>$
+
+
+\chapter{System Features}
+$<$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}
+
+
+
+\chapter{Other Nonfunctional Requirements}
+
+\section{Performance Requirements}
+$<$If there are performance requirements for the product under various
+circumstances, state them here and explain their rationale, to help the
+developers understand the intent and make suitable design choices. Specify the
+timing relationships for real time systems. Make such requirements as specific
+as possible. You may need to state performance requirements for individual
+functional requirements or features.$>$
+
+\section{Safety Requirements}
+$<$Specify those requirements that are concerned with possible loss, damage, or
+harm that could result from the use of the product. Define any safeguards or
+actions that must be taken, as well as actions that must be prevented. Refer to
+any external policies or regulations that state safety issues that affect the
+product’s design or use. Define any safety certifications that must be
+satisfied.$>$
+
+\section{Security Requirements}
+$<$Specify any requirements regarding security or privacy issues surrounding use
+of the product or protection of the data used or created by the product. Define
+any user identity authentication requirements. Refer to any external policies or
+regulations containing security issues that affect the product. Define any
+security or privacy certifications that must be satisfied.$>$
+
+\section{Software Quality Attributes}
+$<$Specify any additional quality characteristics for the product that will be
+important to either the customers or the developers. Some to consider are:
+adaptability, availability, correctness, flexibility, interoperability,
+maintainability, portability, reliability, reusability, robustness, testability,
+and usability. Write these to be specific, quantitative, and verifiable when
+possible. At the least, clarify the relative preferences for various attributes,
+such as ease of use over ease of learning.$>$
+
+\section{Business Rules}
+$<$List any operating principles about the product, such as which individuals or
+roles can perform which functions under specific circumstances. These are not
+functional requirements in themselves, but they may imply certain functional
+requirements to enforce the rules.$>$
+
+
+\chapter{Other Requirements}
+$<$Define any other requirements not covered elsewhere in the SRS. This might
+include database requirements, internationalization requirements, legal
+requirements, reuse objectives for the project, and so on. Add any new sections
+that are pertinent to the project.$>$
+
+\section{Appendix A: Glossary}
+%see https://en.wikibooks.org/wiki/LaTeX/Glossary
+$<$Define all the terms necessary to properly interpret the SRS, including
+acronyms and abbreviations. You may wish to build a separate glossary that spans
+multiple projects or the entire organization, and just include terms specific to
+a single project in each SRS.$>$
+
+\section{Appendix B: Analysis Models}
+$<$Optionally, include any pertinent analysis models, such as data flow
+diagrams, class diagrams, state-transition diagrams, or entity-relationship
+diagrams.$>$
+
+\section{Appendix C: To Be Determined List}
+$<$Collect a numbered list of the TBD (to be determined) references that remain
+in the SRS so they can be tracked to closure.$>$
+
+\end{document} \ No newline at end of file
diff --git a/csci5801/usecase-template.tex b/csci5801/usecase-template.tex
new file mode 100644
index 0000000..2343edd
--- /dev/null
+++ b/csci5801/usecase-template.tex
@@ -0,0 +1,94 @@
+%% 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}{Template test}
+
+%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}
+
+%Stakeholders and Interests: Who cares about this use case and what do they want?
+\additemizedfield{Stakeholders and Interests:}{
+ \item Stakeholder 1 name: his interests
+ \item Stakeholder 2 name: his interests
+}
+
+%Preconditions: What must be true on start and worth telling the reader?
+\addfield{Preconditions:}{}
+%when multiple
+%\additemizedfield{Preconditions:}{}
+
+%Postconditions: What must be true on successful completion and worth telling the reader
+\addfield{Postconditions:}{}
+%when multiple
+%\additemizedfield{Preconditions:}{}
+
+%Main Success Scenario: A typical, unconditional happy path scenario of success.
+\addscenario{Main Success Scenario:}{
+ \item The first action
+ \item The second action
+}
+
+%Extensions: Alternate scenarios of success or failure.
+\addscenario{Extensions:}{
+ \item[2.a] Invalid login data:
+ \begin{enumerate}
+ \item[1.] System shows failure message
+ \item[2.] User returns to step 1
+ \end{enumerate}
+ \item[5.a] Invalid subsriber data:
+ \begin{enumerate}
+ \item[1.] System shows failure message
+ \item[2.] User returns to step 2 and corrects the errors
+ \end{enumerate}
+}
+
+%Special Requirements: Related non-functional requirements.
+\additemizedfield{Special Requirements:}{
+ \item first applicable non-functional requirement
+ \item second applicable non-functional requirement
+}
+
+%Technology and Data Variations List: Varying I/O methods and data formats.
+\addscenario{Technology and Data Variations List:}{
+ \item[1a.] Alternative first action with other technology
+}
+
+%Frequency of Occurrence: Influences investigation, testing and timing of implementation.
+\addfield{Frequency of Occurrence:}{}
+
+%Miscellaneous: Such as open issues/questions
+%\addfield{Open Issues:}{}
+
+\end{usecase}
+
+\end{document}
+