1234567891011121314151617181920212223 |
- 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 OSN is usable without restrictions.
- \item The user can see which way (private P2P or public 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 OSN functionalities.
- \item The solution is client-side since there is no control over the OSN server.
- \item The 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 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}
|