HOSN-app/thesis/content/04-concept/requirements.tex

The solution should meet specific functional and non-functional requirements so that users are willing to use another client.

\textbf{Functional requirements}:
\begin{itemize}
	\item The standard functionality of the \ac{OSN} is usable without restrictions.
	\item The user can see which way (private \ac{P2P} or public \ac{OSN}) the data comes from and where it goes.
	\item Data access should only be possible for authorized users.
	\item The data exchange should be automatically encrypted so that the data is worthless for third parties.
	\item The data format is flexible in order to map changes and new \ac{OSN} functionalities.
	\item The solution is client-side since there is no control over the \ac{OSN} server.
	\item The \ac{OSN} Service Provider can retrieve anonymized data relevant to him.
	\item The solution is platform independent.
\end{itemize}

\textbf{Non-functional requirements}:
\begin{itemize}
	\item Data exchange over the private network is fast and secure.
	\item The user interface is simple and understandable.
	\item The design of the app is modern and appealing.
	\item No violation of the guidelines and terms of use/service of the \ac{OSN}.
	\item No restrictions for standard users who do not use the hybrid solution.
	\item The additional effort for the user when using the hybrid solution should be minimal.
\end{itemize}