@@ -58,86 +58,86 @@ to the template, you should explicity state what modifications were made.
\section{Project Drivers}
\subsection{The Purpose of the Project}
\subsection{The Purpose of the Project}
The goal of the project is to produce a reimplementation of the orignal Rogue computer game, originally developed by Michael Toy, Glenn Wichman, and Ken Arnold in 1980. The gameplay of the reimplementation should mimic that of the original whenever possible. The objective of the rewrite is to produce a copy in a modern language, using modern design principles, with superior documentation and a full test suite. The original Rogue is of historical interest as it forms the foundation and is the namesake of the roguelike genre of games, typified by their randomized environments, difficulty, and permadeath features. The motivation for this project is the poor condition of the original source code. The original source was not written with readability in mind, and designed for extremely low-performance systems who required some unusual design patterns. The version of C in which it was written is very old, which hinders compilation or feature extension. The intended audience for this document is the stakeholders of this project, especially Dr Smith and the 3XA3 TAs.
The goal of the project is to produce a reimplementation of the orignal Rogue computer game, originally developed by Michael Toy, Glenn Wichman, and Ken Arnold in 1980. The gameplay of the reimplementation should mimic that of the original whenever possible. The objective of the rewrite is to produce a copy in a modern language, using modern design principles, with superior documentation and a full test suite. The original Rogue is of historical interest as it forms the foundation and is the namesake of the roguelike genre of games, typified by their randomized environments, difficulty, and permadeath features. The motivation for this project is the poor condition of the original source code. The original source was not written with readability in mind, and designed for extremely low-performance systems who required some unusual design patterns. The version of C in which it was written is very old, which hinders compilation or feature extension. The intended audience for this document is the stakeholders of this project, especially Dr Smith and the 3XA3 TAs.
\subsection{The Stakeholders}
\subsection{The Stakeholders}
\subsubsection{The Client}
\subsubsection{The Client}
The client of the project is Dr Spencer Smith. Dr Smith commissioned the project and will be overseeing its production. Dr Smith provides the specifications for this document, as well as other aspects of the project, including the test suite, and all documenation. In addition he will be evaluating the final product.
The client of the project is Dr Spencer Smith. Dr Smith commissioned the project and will be overseeing its production. Dr Smith provides the specifications for this document, as well as other aspects of the project, including the test suite, and all documenation. In addition he will be evaluating the final product.
\subsubsection{The Customers}
\subsubsection{The Customers}
The project customers are the players of the game. It is expected that this will consist primarily of players of the original, as well as players and developers of later roguelike games. The roguelike community has a strong open-source tradition, so a modern, well-documented Rogue could be a valuable starting point or inspiration for projects by other teams.
The project customers are the players of the game. It is expected that this will consist primarily of players of the original, as well as players and developers of later roguelike games. The roguelike community has a strong open-source tradition, so a modern, well-documented Rogue could be a valuable starting point or inspiration for projects by other teams.
\subsubsection{Other Stakeholders}
\subsubsection{Other Stakeholders}
\subsection{Mandated Constraints}
\subsection{Mandated Constraints}
\subsection{Naming Conventions and Terminology}
\subsection{Naming Conventions and Terminology}
\subsection{Relevant Facts and Assumptions}
\subsection{Relevant Facts and Assumptions}
User characteristics should go under assumptions.
User characteristics should go under assumptions.
\section{Functional Requirements}
\subsection{The Scope of the Work and the Product}
\subsection{The Scope of the Work and the Product}
\subsubsection{The Context of the Work}
\subsubsection{The Context of the Work}
\subsubsection{Work Partitioning}
\subsubsection{Work Partitioning}
\subsubsection{Individual Product Use Cases}
\subsubsection{Individual Product Use Cases}
\subsection{Functional Requirements}
\subsection{Functional Requirements}
\section{Non-functional Requirements}
\subsection{Look and Feel Requirements}
\subsection{Look and Feel Requirements}
\subsection{Usability and Humanity Requirements}
\subsection{Usability and Humanity Requirements}
\subsection{Performance Requirements}
\subsection{Performance Requirements}
\subsection{Operational and Environmental Requirements}
\subsection{Operational and Environmental Requirements}
\subsection{Maintainability and Support Requirements}
\subsection{Maintainability and Support Requirements}
\subsection{Security Requirements}
\subsection{Security Requirements}
\subsection{Cultural Requirements}
\subsection{Cultural Requirements}
\subsection{Legal Requirements}
\subsection{Legal Requirements}
\subsection{Health and Safety Requirements}
\subsection{Health and Safety Requirements}
This section is not in the original Volere template, but health and safety are
issues that should be considered for every engineering project.
This section is not in the original Volere template, but health and safety are
issues that should be considered for every engineering project.
\section{Project Issues}
\subsection{Open Issues}
\subsection{Open Issues}
\subsection{Off-the-Shelf Solutions}
\subsection{Off-the-Shelf Solutions}
\subsection{New Problems}
\subsection{New Problems}
\subsection{Tasks}
\subsection{Tasks}
\subsection{Migration to the New Product}
\subsection{Migration to the New Product}
\subsection{Risks}
\subsection{Risks}
\subsection{Costs}
\subsection{Costs}
\subsection{User Documentation and Training}
\subsection{User Documentation and Training}
\subsection{Waiting Room}
\subsection{Waiting Room}
\subsection{Ideas for Solutions}
\subsection{Ideas for Solutions}
\newpage
...
...
@@ -152,10 +152,10 @@ issues that should be considered for every engineering project.
This section has been added to the Volere template. This is where you can place
additional information.
\subsection{Symbolic Parameters}
\subsection{Symbolic Parameters}
The definition of the requirements will likely call for SYMBOLIC\_CONSTANTS.
Their values are defined in this section for easy maintenance.
The definition of the requirements will likely call for SYMBOLIC\_CONSTANTS.
Their values are defined in this section for easy maintenance.
