\section{Requirements}
+\subsection{Introduction}
+As almost every other computer starts with a set of requirements so will this
+application. Requirements are a set of goals within different categories that
+will define what the application has to be able to do and they are
+traditionally defined at the start of the project and not expected to change
+much. In the case of this project the requirements were a lot more flexible
+because there was only one person doing the programming and there was a weekly
+meeting to discuss the matters and most importantly discuss the required
+changes. Because of this a lot of initial requirements are removed and a some
+requirements were added in the process. The list below shows the definitive
+requirements and also the suspended requirements.
+
+The two types of requirements that are formed are functional and non-functional
+requirements. Respectively they are requirements that describe a certain
+function and the latter are requirements that describe a certain property such
+as efficiency or compatibility. To make us able to refer to them we give the
+requirements unique codes. We also specify in the list with active requirements
+the reason for the choice.
+
+\subsection{Functional requirements}
+\subsubsection{Original functional requirements}
+\begin{itemize}
+ \item[F1:] Be able to crawl several source types.
+ \begin{itemize}
+ \item[F1a:] Fax/email.
+ \item[F1b:] XML feeds.
+ \item[F1c:] RSS feeds.
+ \item[F1d:] Websites.
+ \end{itemize}
+ \item[F2:] Apply low level matching techniques on isolated data.
+ \item[F3:] Insert the data in the database.
+ \item[F4:] User interface to train crawlers must be usable by non computer
+ science people.
+ \item[F5:] There must be a control center for the crawlers.
+\end{itemize}
+
+\subsubsection{Definitive functional requirements}
+Requirements F2 is the sole requirement that is dropped completely. All other
+definitive requirements are formed out of the original functional requirements.
+Together they make the following definitive requirements:
+\begin{itemize}
+ \item[F6:] Be able to crawl RSS feeds only.
+
+ This requirement is an adapted version of the compound requirements
+ F1a-F1d. We stripped down from crawling four different sources to only one
+ source because of the scope of the project. Most sources require an
+ entirely different strategy. The full reason why we chose RSS feeds can be
+ found in Section~\ref{sec:whyrss}.
+
+ \item[F7:] Export the data to a strict XML feed.
+
+ This requirement is an adapted version of requirement F3, this to done to
+ make the scope smaller. We chose to no interact with the database or the
+ \textit{Temporum}. The application will have to be able to output XML data
+ that is formatted following a string XSD scheme so that it is easy to
+ import the data in the database or \textit{Temporum}.
+ \item[F8:] A control center interface that is usable by non computer
+ science people.
+
+ This requirement is a combination of F4 and F5. At first the user interface
+ for adding and training crawlers was done via a webinterface that was user
+ friendly and usable for non computer science people as the requirement
+ stated. However in the first prototypes the control center that could test,
+ edit and remove crawlers was a command line application and thus not very
+ usable for the general audience. This combined requirements asks for a
+ single control center that can do all previously described task with an
+ interface that is usable by almost everyone.
+ \item[F9:] Report to the user or maintainer when a source has been changed
+ too much for successful crawling.
+
+ This requirement was also present in the original requirements and hasn't
+ changed. When the crawler fails to crawl a source, this can be due to any
+ reason, a message is sent to the people using the program so that they can
+ edit or remove the faulty crawler. This is a crucial component because the
+ program, a non computer science person can do this task and is essential in
+ shortening the feedback loop explained in Figure~\ref{fig:1.1.2}.
+\end{itemize}
+
+\subsection{Non-functional requirements}
+\subsubsection{Original functional requirements}
+\begin{itemize}
+ \item[N1:] Integrate in the original system.
+ \item[N2:] Work in a modular fashion, thus be able to, in the future, extend
+ the program.
+\end{itemize}
+
+\subsubsection{Active functional requirements}
+\begin{itemize}
+ \item[N2:] Work in a modular fashion, thus be able to, in the future, extend
+ the program.
+
+ The modularity is very important so that the components can be easily
+ extended and components can be added. Possible extensions are discussed in
+ Section~\ref{sec:discuss}.
+ \item[N3:] Operate standalone on a server.
+
+ Non-functional requirement N1 is dropped because we want to keep the
+ program as modular as possible and via an XML interface we still have a
+ very stable connection with the database but we avoided getting entangled
+ in the software managing the database.
+\end{itemize}
\section{Design}
repositories / bsc-thesis1415.git / commitdiff