diff options
Diffstat (limited to 'csci5801/a1.tex')
| -rw-r--r-- | csci5801/a1.tex | 282 |
1 files changed, 282 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 |