IEEE-29148-2018-SRS-Template.tex

% Copyright 2021 Wuping Xin

% 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/>.

% This template is based on IEEE/ISO/IEC 29148-2018, Section 9.6.

% This template provides the normative content of the software requirement 
% specification (SRS). The project shall produce the following information item 
% content in accordance with the project's policies with respect to the software
% requirements specification. Organization of the content such as the order and 
% section structure may be selected in accordance with the project's information 
% management policies.

\documentclass{scrreprt}

\usepackage{comment}
%\includecomment{appendix-part}   
\excludecomment{appendix-part} 

\begin{appendix-part}
\usepackage[titletoc,title,page]{appendix}
\end{appendix-part}

\usepackage[english]{babel}
\usepackage{booktabs}
\usepackage{hyperref}
\usepackage[utf8]{inputenc}
\usepackage{listings}
\usepackage{underscore}
\usepackage[table,xcdraw]{xcolor}

\def\myauthorname{Your Name}
\def\mykeywords{SRS, ISO/IEC/IEEE 29148:2018}
\def\myorganization{Company Name\\1601 Veterans Highway, Suite 340 \\ Islandia, NY, 11749}
\def\mysubject{My Super Cool Software}
\def\mytitle{Software Requirement Specification}
\def\myversion{1.0}

%\title{ }

\hypersetup{
	pdftitle={\mytitle},          % title
	pdfauthor={\myauthorname},    % author
	pdfsubject={\mysubject},      % subject of the document
	pdfkeywords={\mykeywords},    % list of keywords
	colorlinks=true,              % false: boxed links; true: colored links
	linkcolor=blue,               % color of internal links
	citecolor=black,              % color of links to bibliography
	filecolor=black,              % color of file links
	urlcolor=purple,              % color of external links
	linktoc=page                  % only page is linked
}

\begin{document}
\thispagestyle{empty}
 
\begin{flushright}
    \rule{16cm}{5pt}\vskip 0.8cm
    \begin{bfseries}
        \LARGE{SOFTWARE REQUIREMENTS SPECIFICATION}\\
        \vspace{0.8cm}
        for \\
        \vspace{0.8cm}
        \Huge{\mysubject}\\
        \vspace{1.9cm}
        \Large{Version \myversion}\\
    \end{bfseries}        
        \vfill                
        \large 	Prepared by\\
        \vspace{0.25cm}
        \LARGE \textbf{\myauthorname}        
        \vfill        
        \large \myorganization\\        
        \vspace{0.5cm}
	    \today\\
\end{flushright}

\chapter*{Revision History}
\setcounter{page}{1}
\begin{center}
	\begin{tabular}{@{} l l p{6.5cm} l @{}}
		\toprule
		\textbf{Name}    & \textbf{Date}   & \textbf{Reason for Changes} & \textbf{Version} \\ 
		\midrule
		Wuping Xin       & 2021-10-21      & Initial draft               & 1.0              \\
		&                &                 &                                                \\
		&                &                 &                                                \\
		\bottomrule
	\end{tabular}
\end{center}

\tableofcontents

\chapter{Introduction}

% [IEEE-29148-2018 9.6.2] Delineate the purpose of the software to be specified.
\section{Purpose}

% [IEEE-29148-2018 9.6.3] Describe the scope of the softwrae under consideration by: 
%  a) identifying the software product(s) to be produced by name 
%     (e.g., Host DBMS, Report Generator, etc);
%  b). explaning what the software product(s) will do; 
%  c) describing the application of the software being specified, 
%     including relevant benefits, objectives and goals, and
%  d) being consistent with similar statements in higher-level 
%     specifications (e.g., a system requirements specification), 
%     if they exist.
\section{Scope}

% List any other documents or Web addresses to which this SRS refers. These may include
% user interface style guides, contracts, standards, system requirements specifications, 
% use case documents, or a vision and scope document. Provide enough information so that
% the reader could access a copy of each reference, including title, author, version
% number, date, and source or location.
\section{References}

% Define all the terms necessary to properly interpret the SRS. 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{Terms}

% Define abbreviations necessary to properly interpret the SRS. 
\section{Abbreviations}


\chapter{Product Overview}

% [IEEE-29148-2018 9.6.4] Define the system's relationship to other related products
% If the product is an element of a larger system, relate the requirements of that
% larger system to the functionality of the product covered by the SRS. 

% [IEEE-29148-2018 9.6.4] If the product is an element of a larger system, identify the
% interfaces between the product covered by the SRS and the larger system of which the
% product is an element.

% [IEEE-29148-2018 9.6.4] Consider a block diagram showing the major elements of the
% larger system, interconnectiosn and external inerfaces.

% [IEEE-29148-2018 9.6.4] Describe how the software operates with the 
% following constraints:
%  a) system interfaces
%  b) user interfaces; 
%  c) hardware interfaces; 
%  d) software interfaces; 
%  e) communications interfaces; 
%  f) memory; 
%  g) operations; 
%  h) site adaptation requirements; and 
%  i) interfaces with services.
\section{Product Perspective}

% [IEEE-29148-2018 9.6.4.1] List each system interface and identify the functionality
% of the software to accomplish the system requirement and the
% interface description to match the system.
\subsection{System Interfaces}

% [IEEE-29148-2018 9.6.4.2] Specify the logical characteristics of each interface
% between the software product and its users.

% [IEEE-29148-2018 9.6.4.2] NOTE A style guide for the user interface can provide
% consistent rules for organization, coding, and interaction of the user with the system.
\subsection{User Interfaces}

% [IEEE-29148-2018 9.6.4.3] Specify the logical characteristics of each interface
% between the software product and the hardware elements of the system. 
% This includes configuration characteristics (num of ports, instruction sets, etc).
% It also covers such matters as what devices are to be supported, 
% how they are to be supported, and protocols. 
% For example, terminal support may specify full-screen support as opposed
% to line-by-line support.
\subsection{Hardware Interfaces}

% [IEEE-29148-2018 9.6.4.4] Specify the use of other required software products
% (e.g., a data management system, an operating system or a mathematical package),
% and interfaces with other application systems (e.g., the linkage between an accounts
% receivable sytem and a general ledger system).
 
% For each required software product, specify:
%  a) name; 
%  b) mnemonic; 
%  c) specification number; 
%  d) version number; and 
%  e) source.

% [IEEE-29148-2018 9.6.4.4] NOTE it is acceptable to specify required
% platforms or operating systems, but rarely feasible to require
% a specific version. Typically, a version number of the most recent version
% or any currently maintain version can be specified for the software.

% [IEEE-29148-2018 9.6.4.4] For each interface, specify: 
%  a) discussion of the purpose of the interfacing software as related
%     to this software product;
%  b) definition of the interface in terms of message content and format. 
%     It is not necessary to detail any well-documented interface, but a 
%     reference to the document defining the interfaces is required.
\subsection{Software Interfaces}

% [IEEE-29148-2018 9.6.4.5] Specify the various interfaces to communications such
% as local network protocols.
\subsection{Communication Interfaces}

% [IEEE-29148-2018 9.6.4.6] Specify any applicable characteristics and limits
% on primary and secondary memory.
\subsection{Memory Constraints}

% [IEEE-29148-2018 9.6.4.7] Specify the normal and special operations
% required by the user such as:
%  a) the various modes of operations in the user organization
%     (e.g., user-initiated operations); 
%  b) periods of interactive operations and periods of unattended operations; 
%  c) data processing suport functions; and 
%  d) backup and recovery operations.

% [IEEE-29148-2018 9.6.3] NOTE This is sometimes specified as part
% of the User Interfaces section.
\subsection{Operations}

% [IEEE-29148-2018 9.6.4.8] The site adaptation requirements include: 
%   a) definition of the requirements for any data or initialization sequences that are 
%      specific to a given site, mission, or operational mode 
%      (e.g., grid values, safety limits, etc.); 
%   b) specification of the site or mission-related features that should be modified to 
%      adapt the software to aparticular instalation.
\subsection{Site Adaptation Requirements}

% [IEEE-29148-2018 9.6.4.9] Specify interactions with sevices, e.g., 
% Software as a Service (SaaS) or cloud services.
\subsection{Interface with Services}

% [IEEE-29148-2018 9.6.5] Provide a summary of the major functions that the
% software will perform, without mentioning the vast amount of detail
% of each of those functions requires. Use cases, user stories and scenarios
% are also used to describe product functions.
 
% Note that for the sake of clarity: 
%   a) the product functions should be organized in a way that makes the list of
%      functions understandable to the acquirer or to anyone else reading the document 
%      for the first time.
%   b) textual or graphical metods can be used to show the different functions and their
%      relationships. Such a diagram is not intended to show a desin of a product,
%      but simply shows the logical relationships among variables.
\section{Product Functions}

% [IEEE-29148-2018 9.6.6] Describe those general characteristics of the 
% intended groups of users of the product including characeristics that
% may influence usability, such as educational level, experience, 
% disabilities and technical expertise. This description should not state
% specific requirements, but rather should state the reasons why certain specific
% requiremetns are later specified in specific requirements.

% [IEEE-29148-2018 9.6.6] NOTE1 Where appropriate, the user characteristcs of
% the System Requirement Specification (SyRS) and SRS are consistent.

% [IEEE-29148-2018 9.6.6] NOTE2 For additional information on context of use
% and user needs, see ISO/IEC 25063 and ISO/IEC 25064
\section{User Characteristics}

% [IEEE-29148-2018 9.6.7] Provide a general description of any other items
% that will limit the supplier's options, including:
%   a) regulatory requirements and policies
%   b) hardware limitations (e.g., signal timing requirements);
%   c) interfaces to other applications;
%   d) parallel operations;
%   e) audit functions;
%   f) control functions;
%   g) higher-order language requiremetns;
%   h) signal handshake protocols (e.g., XON-XOFF, ACK-NACk);
%   i) quality requiremtns (e.g., reliability);
%   j) criticality of the application;
%   k) safety and security considerations;
%   l) physical/mental consideratios; and
%   m) limitations that are sourced from other systems, including real-time
%      requirements from the controlled system through interfaces.
\section{Limitations}

% [IEEE-29148-2018 9.6.8] List each of the factors that affect the requirements
% stated in the SRS. These factors are not design constraints on the software
% but any changes to these factors can affect the requirements in the SRS.
% For example, an assumption may be that a specific operating system will be 
% available on the hardware designated for the software product. If, in fact, 
% the operating system is not available, the SRS would have to change accordingly. 
\section{Assumptions and Dependencies}

% [IEEE-29148-2018 9.6.9] Apportion the software requirements to software elements.
% For requirements that will requirement implementation over multiple software elements,
% or when allocation to a software element is initially undefined, this should
% be so stated. A cross-reference table by function and software element
% should be used to summarize the apportionment.

% [IEEE-29148-2018 9.6.9] Identify requirements that may be delayed until future
% version of the system (e.g., blocks and/or increments).
\section{Apportioning of Requirements}

% [IEEE-29148-2018 9.6.10] Specify the software system requirements to a level of detail
% sufficient for software design, development and verification of the software increment
% of release in process. The requirements should: 
%   a) be stated in conformance with all the characteristics described in 
%      ISO/IEC/IEEE 29148:2018 Section 5.2;
%   b) be cross-referenced to earlier versions or related documents; 
%   c) be uniquely identifiable; 
%   d) describe every input (stimulus) into the software system, every output (response) 
%      from the software system, and all functions performed by the software
%      system in response to an input or in support of an output.
\section{Specified Requirements}

\chapter{Specific Requirements}

% [IEEE-29148-2018 9.6.11] Define all inputs into and outputs from the software system.
% The description should complement the interface descriptions in 9.6.4.1 through 9.6.4.5, 
% and should not repeat information there. Each interface defined should include
% the following content: 
%   a) name of item; 
%   b) description of purpose; 
%   c) source of inut or destination of output; 
%   d) valid range, accuracy and/or tolerance; 
%   e) units of measure; 
%   f) timing; 
%   g) relationships to other inputs/outputs; 
%   h) data formats; 
%   i) command formats; and 
%   j) data items or information included in the input and output.
\section{External Interfaces}

% [IEEE-29148-2018 9.6.12] Define the fundamental actions that have to take place
% in the software in accepting and processing the inputs and in procesing 
% and generating the outputs, including: 
%   a) validity checks on teh inputs;
%   b) exact sequence of operations; 
%   c) responses to abnormal situations, including: 
%       1) overflow 
%       2) communication facilities 
%       3) hardware faults and failures and 
%       4) error handling and reecovery
%  d) effect of parameters; 
%  e) relationship of outputs to inputs, incuding: 
%       1) input/output sequences and 
%       2) formulas for input to output conversion.
% It may be appropriate to partition the functional requirements into sub-functions or sub-processes. 
% This does not imply that the software design will also be partitioned that way.
\section{Functions}

% [IEEE-29148-2018 9.6.13] Define usability and quality in use requirements
% and objectives for the software system that can include measurable
% effectiveness, efficiency, satisfaction criteria and avoidance of 
% harm that could arise from use in specific contexts of use. 

% NOTE Additional guidance on usability requirements can be found in ISO/IEC TR25060
\section{Usability Requirements}

% [IEEE-29148-2018 9.6.14] Specify both the static and the dynamic numerical requirements
% placed on the software or on human interaction with the software as a whole.
 
% Static numerical requirements may include the following: 
%   a) the number of terminals to be supported;
%   b) the number of simultaneous users to be supported; and 
%   c) the amount and type of information to be handled. Static numerical requirements
%      are sometimes identified under a separate section entitled Capacity.
 
%  Dynamic numerical requirements may include, for example, the numbers of transactions
%  and tasks and the amount of data to be processed within certain time periods for both
%  normal and peak workload conditions. The performance requirements should be stated
%  in measurable terms. 

%  For example, "95% of the transactions shall be processed in less than 1s",
%  rather than, "An operator shall not have to wait for the transaction to complete". 

% NOTE Numerical limits applied to one specific function are normally specified
% as part of the processing subparagraph description of that function.
\section{Performance Requirements}

% [IEEE-29148-2018 9.6.15] Specify the logical requirements for any information that
% is to be placed into a database, including:
%   a) types of information used by various functions;
%   b) frequency of use;
%   c) accessing capabilities;
%   d) data entities and their relationships;
%   e) integrity constraints;
%   f) security; and
%   g) data retention requirements.
\section{Logical Database Requirements}

% [IEEE-29148-2018 9.6.16] Specify constraints on the system design imposed by
% external standards, regulatory requirements or project limitations.
\section{Design Constraints}

% [IEEE-29148-2018 9.6.17] Specify the requirements derived from existing 
% standards or regulations, including:
%   a) report format;
%   b) data naming;
%   c) accounting procedures; and
%   d) audit tracing.
% For example, this could specify the requirement for software to trace processing activity. 
% Such traces are needed for some applications to meet minimum regulatory or financial
% standards. An audit trace requirement may, for example, state that all changes to 
% a payroll database shall be recorded in a trace file with before and after values.
\section{Standards Compliance}

% [IEEE-29148-2018 9.6.18] Specify the required attributes of the software product. 
% The following is a partial list of examples:
%   a) Reliability - specify the factors required to establish the required reliability
%      of the software system at the time of delivery.
%   b) Availability - specify the factors required to guarantee a defined 
%      availability level for the entire system such as checkpoint, recovery and restart.
%   c) Security - specify the requirements to protect the software from 
%      accidental or malicious access, use modification, destruction or disclosure. 
%      Specific requirements in this area could include the need to:
%        1) utilize certain cryptographic techniques;
%        2) keep specific log or history data sets;
%        3) assign certain functions to different modules;
%        4) restrict communications between some areas of the programme;
%        5) check data integrity for critical variables; and
%        6) assure data privacy.
%   d) Maintainability - specify attributes of software that relate to the ease of maintenance
%      of the software itself. These may include requirements for certain modularity, 
%      interfaces or complexity limitation. Requirements should not be placed here
%      just because they are thought to be good design practices.
%   e) Portability - specify attributes of software that relate to the ease of porting
%      the software to other host machines and/or operating systems, including:
%        1) percentage of elements with host-dependent code;
%        2) percentage of code that is host dependent;
%        3) use of a proven portable language;
%        4) use of a particular compiler or language subset; and
%        5) use of a particular operating system
\section{Software System Attributes}

% [IEEE-29148-2018 9.6.10] Provide the verification approaches and 
% methods planned to qualify the software. The information items for
% verification are recommended to be given in a parallel manner
% with the information items in 9.6.10 to 9.6.18.
\chapter{Verification}

% [IEEE-29148-2018 9.6.19] Additional supporting information to be considered includes:
%   a) sample input/output formats, descriptions of cost analysis 
%      studies or results of user surveys;
%   b) supporting or background information that can help the readers of the SRS;
%   c) a description of the problems to be solved by the software; and
%   d) special packaging instructions for the code and the media to meet
%      security, export, initial loading or other requirements.
% The SRS should explicitly state whether or not these information items 
% are to be considered part of the requirements.
\chapter{Supporting Information}

\begin{appendix-part}
	
\begin{appendices}
%\renewcommand{\thechapter}{}
%\renewcommand{\autodot}{}
\chapter{Index} 
\end{appendices}

\end{appendix-part}

\end{document}