1234567891011121314151617181920212223 |
- 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}
|