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

In order for users of an OSN to be willing to use another client for or an additional extension when using the OSN, the solution should meet certain functional and non-functional requirements.

\textbf{Functional requirements}:
\begin{itemize}
	\item The standard functionality of the OSN can be used without restrictions.
	\item The user can clearly see which way (private or OSN) the data goes and where it comes from.
	\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 OSN functionalities.
	\item Platform independence
	\item The solution is client-side, since the OSN Server cannot be influenced
	\item The OSN Service Provider can retrieve anonymized data relevant to him.
\end{itemize}

\textbf{Non-functional requirements}:
\begin{itemize}
	\item Data exchange over the private network is fast and secure.
	\item Simple, understandable user interface
	\item Attractive, modern design
	\item No violation of the guidelines and terms of use of the OSN
	\item No restrictions for classic 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}