% ==============================================================================================================
% Section 3: Specific requirements
%
%
% -------------- To do --------------
% - the whole thing
% ==============================================================================================================
\section{Specific Requirements}
    \subsection{Functional Requirements}
    To do.

    \subsection{Non-Functional Requirements}
    To do.

    \subsection{Design Constraints}
    \begin{itemize}
        \item The module will be written in C++.
        \item Existing S2PLOT code is able to run on the new Omegalib module.
        \item Full S2PLOT API must be replicated in the new Omegalib module.
        \item Must remove global variables from the source code.
        \item Project management documentation is to comply with the Documentation Standards Document (delivered by 25/4).
        \item Design documentation is to comply with IEEE and SWEBOK guidelines.
    \end{itemize}

    \subsection{Maintainability}
    The system will be maintained regularly and will be updated every two weeks as we will be following the SCRUM development cycle. The documentation including Project Plan, Software Requirements Specification, Test plan will be modified and added upon as we progress with porting the code. This approach has to be followed as new functionalities will be added regularly hence the documents will evolve as the code evolves. As for maintaining the code as new functionalities are added they will be combined with the old ones and then be tested to see if the entirety of the code works and whether the new functionalities are able to work with the old ones. Another way the code would be maintained is by using the GNU C++ coding format and good Object Oriented practises with proper incode comments to help further developers and code extenders understand the functions and modules.

\end{document}