UCM-ÁGORA SRS Especificación de requisitos GRUPO C 1 ÍNDICE 1. INTRODUCCIÓN................................................................................................. 3 1.1 1.2 1.3 1.4 1.5 Propósito ...................................................................................................................... 3 Alcance ......................................................................................................................... 3 Definiciones, abreviaturas y acrónimos ....................................................................... 3 Referencias ................................................................................................................... 4 Resumen / Organización del documento ..................................................................... 5 2. Descripción general ........................................................................................... 5 2.1 2.2 2.3 2.4 2.5 2.6 Perspectiva del producto.............................................................................................. 5 Funciones del producto ................................................................................................ 5 Características del usuario ........................................................................................... 6 Restricciones................................................................................................................. 7 Suspuestos y dependencias............................................ Error! Bookmark not defined. Requisitos futuros......................................................................................................... 7 3. Requisitos específicos........................................................................................ 9 3.1 Interfaces externas ....................................................................................................... 9 3.2 Funciones (Requisitos funcionales) ....................................... Error! Bookmark not defined. 3.3 Requisitos de rendimiento ......................................................................................... 16 3.4 Requerimientos lógicos de la BBDD ........................................................................... 16 3.5 Restricciones de diseño: ............................................................................................. 16 3.5.1 Estándares de cumplimiento: ................................................................................. 16 3.6 Atributos del sistema software ...................................... Error! Bookmark not defined. 3.6.1 Fiabilidad .................................................................................................................... 17 3.6.2 Disponibilidad ............................................................................................................. 17 3.6.3 Seguridad ................................................................................................................... 17 3.6.4 Capacidad de mantenimiento .................................................................................... 18 3.6.5 Portabilidad ................................................................................................................ 18 2 1. INTRODUCCIÓN 1.1 Propósito Este documento muestra la especificación de requisitos que utilizará el proyecto de UCM-ÁGORA. En él se detalla todos los aspectos que hay que tener en cuenta para crear la aplicación como también sus limitaciones y restricciones. 1.2 Alcance El objetivo del proyecto es crear una red social específica que fomente el desarrollo y la sociabilidad de todos los miembros de la comunidad universitaria de la Universidad Complutense (alumnos, profesores y personal de administración y servicios). La aplicación será un medio para compartir tanto temas académicos como sociales. También se ha decidido ofrecer distintas opciones de acceso a UCM-Ágora. Para ello se ofrecerán, al menos una interfaz vía web, otra para dispositivos móviles y una aplicación específica multiplataforma para acceder a la aplicación. Todo esto para soportar distintas necesidades de acceso de los usuarios en cada momento y lugar. 1.3 Definiciones, abreviaturas y acrónimos BDD: Base de datos. SRS: Especificación de Requerimientos de Software (SRS) define de forma precisa el producto de software que se va a construir. Las decisiones hechas escribiendo la SRS están basados en información de los documentos de la propuesta del proyecto y requerimientos del usuario. El conjunto de requerimientos de SRS deben ser satisfechos en el diseño del sistema. La SRS es verificada y validada por las actividades marcadas en el plan de QA. IEEE: En español, Instituto de Ingenieros Eléctricos y Electrónicos, una asociación técnico-profesional mundial dedicada a la estandarización. Es la mayor asociación internacional sin ánimo de lucro formada por profesionales de las nuevas tecnologías UCM: Universidad Complutense de Madrid. XML: (Extensible Markup Language) es un metalenguaje, es decir, un lenguaje para la definición de otros lenguajes. Es decir es una norma que define la sintaxis y las reglas que tenemos que seguir para crear nuestro propio lenguaje de etiquetas. 3 JVM : (máquina virtual de Java) es únicamente un aspecto del software de Java, específicamente utilizado para la interacción en la web. JSP: es un acrónimo de Java Server Pages, que en castellano vendría a decir algo como Páginas de Servidor Java. Es, pues, una tecnología orientada a crear páginas web con programación en Java. MySQL: Es un sistema de gestión de bases de datos relacional, multihilo y multiusuario. Su popularidad como aplicación web está muy ligada a PHP, que a menudo aparece en combinación con MySQL. Es una base de datos muy rápida en la lectura lo que la hace ideal para este tipo de aplicaciones. SSL: Secure Socket Layer. Protocolos criptográficos de la capa de transporte que proporcionan comunicaciones seguras por una red. HTTPS: (Hypertext Transfer Protocol Secure) En español: Protocolo seguro de transferencia de hipertexto, más conocido por sus siglas HTTPS, es un protocolo de aplicación basado en el protocolo HTTP, destinado a la transferencia segura de datos de Hiper Texto, es decir, es la versión segura de HTTP.Es utilizado principalmente por cualquier tipo de servicio que requiera el envío de datos personales o contraseñas. Protocolo TCP/IP: Describe un conjunto de guías generales de diseño e implementación de protocolos de red específicos para permitir que una computadora pueda comunicarse en una red. TCP/IP provee conectividad de extremo a extremo especificando como los datos deberían ser formateados, direccionados, transmitidos, enrrutados y recibidos por el destinatario. Backup: (copia de seguridad) Con el fin de que estas copias adicionales puedan utilizarse para restaurar el original después de una eventual pérdida de datos. Keepalive: es un mensaje enviado por un dispositivo a otro para comprobar que el vínculo entre los dos está en funcionamiento, o para evitar que este vínculo se rompa. 1.4 Referencias IEEE Std 830 1998(R2009). (Ubicado en la carpeta /Estándares del repositorio) Especificación de Requisitos según el estandar de IEEE 830. 4 1.5 Resumen / Organización del documento Este documento de especificación de requisitos consta de tres secciones: Sección 1: Introducción. Proporciona una visión general del objetivo de esta aplicación. Sección 2: Descripción de los factores generales que afectan al producto y los requisitos principales que conforman su desarrollo. Sección 3: Define específicamente los requisitos generales que satisfacen al sistema, así como las funciones y restricciones que llevará a cabo. 2. Descripción general . 2.1 Perspectiva del producto UCM-ÁGORA es una red social orientada a alumnos, personal docente e investigación y personal de administración y servicios de la Universidad Complutense de Madrid. Al igual que otras redes sociales, pretende ser un punto de encuentro de la comunidad educativa. A diferencia de otras redes sociales no es totalmente abierta, sino que se restringe a usuarios dados de alta en la base de datos de la UCM. 2.2 Funciones del producto Funcionalidades iniciales del producto a desarrollar. 2.2.1 CONTACTOS. Gestión de contactos de cada usuario, permitiendo así añadir, eliminar y bloquear temporalmente un usuario. Además se podrán organizar en grupos para realizar acciones comunes a uno o varios grupos de contactos. 2.2.2 MURO. Proporciona a cada usuario un lugar donde colgar sus publicaciones y recibir publicaciones de sus contactos. Así mismo permite eliminar las publicaciones o comentarios que se hayan realizado en su muro o en el muro de otros. 2.2.3 FOTOS. Sección específica para subir fotos que, además estará comunicada con el muro permitiendo que aparezcan fotos en él. 2.2.4 CHAT. Permite a los usuarios hablar en tiempo real con los contactos conectados en ese momento. 5 2.2.5 CORREO. Se podrán enviar mensajes a los contactos, conectados o no, de un usuario. La aplicación permitirá recibir, leer, borrar y contestar. 2.2.6 PERFIL. Cada usuario tendrá un perfil donde se mostrará su actividad reciente en la red social, información que muestra a sus contactos, notificaciones y avisos relevantes. 2.2.7 OPCIONES. Sección de opciones donde los usuarios podrá controlar todo lo relativo a la configuración de la aplicación tales, como opciones de privacidad, visualización, notificaciones, etc. 2.3 Características del usuario UCM-ÁGORA va destinada en especial a dos sectores principales, el alumnado de la UCM, ya que, sirve como herramienta social para su beneficio en los años de carrera y al profesorado, el cual tendrá un medio de comunicación directo y global para notificar cualquier dato relevante a sus alumnos o entre ellos mismos. UCM-ÁGORA está estructurado de una manera clara para que el personal que lo utilice no necesite una gran experiencia, aunque se espera un conocimiento básico de Internet para poder darle el uso más óptimo a la aplicación. El usuario preferiblemente debería estar familiarizado con redes sociales para su mejor uso, aunque la aplicación tiene una interfaz gráfica amigable e intuitiva que no resultará complicado al usuario sin experiencia. El personal encargado de administrar y gestionar UCM-ÁGORA, sí que debe tener conocimientos de administración de redes y sistemas para resolver cualquier incidencia que pueda producirse. 6 2.4 Restricciones 2.4.1 Limitaciones de hardware UCM-ÁGORA para su correcto funcionamiento deberá estar instalado en servidores dedicados, con un ancho de banda y almacenamiento suficientes para soportar el grueso de usuarios de la Universidad Complutense. 2.4.2 Limitaciones de software Será necesario tener una versión adecuada de LINUX/UNIX con Apache2, PHP5 y MySQL5 2.4.3 Funcionamiento paralelo. La aplicación soportará el acceso concurrente de un número máximo de usuarios,. De igual manera, la base de datos dará servicio a un máximo establecido de consultas, prevemos 20.000. Esto dependerá de la capacidad contratada con nuestro proveedor de servicios. Siempre con posibilidad de ampliación en caso de conexiones fuera de lo previsto. 2.4.4 Limitaciones sobre seguridad. Los datos que viajan desde los servidores de UCM-AGORA, la Universidad Complutense y los dispositivos de los usuarios se realizará encriptada y de forma segura mediante un certificado SSL. 2.4.5 Funciones de auditoría y de control La realización de respaldos ( backups ) deberá hacerse periódicamente dada la importancia de los datos alojados en UCM-AGORA y la necesidad legal de mantenerlos seguros por la LOPD 15/1999 2.4.6 Protocolos de comunicación Para realizar las conexiones que requieren un mínimo grado de seguridad se utilizará la capa SSL (Protocolo de Capa de Conexión Segura), y el protocolo HTTPS (Hypertext Transfer Protocol Secure). Las comunicaciones que no requieran de ningún tipo de seguridad especial se desarrollaran sobre el protocolo HTTP habitual. 2.5 Supuestos y dependecias El correcto funcionamiento por parte del usuario de UCM-ÁGORA está vinculado a el uso de navegadores que cumplan los estándares W3C. 2.6 Requisitos futuros 7 A continuación se enumeran las posibles funcionalidades que pudieran ser implementadas en un futuro: 2.6.1 Contactos: Incluido en el sistema de grupos, el sistema creara por defecto un grupo de favoritos en el cual se incluirán los contactos con que más interactúa el usuario. Se implementará un sistema de etiquetas el cual permitirá facilitar la identificación de contactos. 2.6.2- Muro Marcar y desmarcar una publicación como favorita. Ocultar publicaciones de un contacto específico. 2.6.3 Fotos Modificar el título o la descripción de la foto. Mover fotos de un álbum a otro. 2.6.4 Chat Permitir el uso de emoticonos. Chatear en grupo entre varios usuarios. Introducir un servicio de videollamada y transferencia de archivos. Se implementara un servicio de transferencia de archivos Se desarrollaran varios juegos multijugador los cuales podrán ser jugados por los contactos 2.6.5 Correo Al crear e-mails, sugerir direcciones mediante concordancias con el historial de direcciones a las que se ha enviado o de las que se ha recibido mensajes, además de los contactos añadidos en el perfil. Adjuntar archivos. Filtro antispam. Crear carpetas para la organización de los mensajes. 2.6.6 Perfil 2.6.7 Opciones 8 3. Requisitos específicos En este apartado se proporcionará aspectos mas detallados para que la implementación sea mas precisa. 3.1 Interfaces externas Encaminador destino No serán necesarias interfaces externas para el encaminador destino, su configuración, de ser necesaria, se hará a través de un fichero de configuración. Servidor El servidor tendrá instalado 2 aplicaciones distintas cómo mínimo: • El sistema gestor de base datos Mysql. • El servidor web Apache2 con soporte para PHP5 Resto de aplicaciones Para el buen funcionamiento de la aplicación, es necesario utilizar componentes externas al proyecto, como por ejemplo, el servidor web apache, el sistema gestor de base de datos Mysql, etc. Para el resto, al ser programas demonio, la configuración se hará exclusivamente modificando los ficheros de configuración de cada uno de ellos Todas las componentes utilizadas, se distribuyen con su propia interfaz, delegando la responsabilidad de la misma a los desarrolladores de la componente. 3.2 FUNCIONES 3.2.1. Requisitos de función de opciones generales. • Acceder a la interfaz general. Descripción: Entrada: Origen: Salida: Destino: Precondición: Permite al usuario ver la interfaz general con las distintas opciones a escoger. Ventana de interfaz general Sistema El usuario debe ser de la UCM y estar logueado en la 9 Postcondición: aplicación. Se visualiza la interfaz general. • Acceder chat. Descripción: Entrada: Origen: Salida: Destino: Precondición: Postcondición: Permite al usuario entrar a la opción de chat. Ventana de interfaz de chat. Sistema. El usuario debe haber accedido antes a la interfaz general correctamente, y por tanto este debe ser de la UCM y estar logueado en la aplicación. Se visualiza la interfaz de chat. • Crear eventos. Descripción: Entrada: Origen: Salida: Destino: Precondición: Postcondición: Permite al usuario acceder a la opción de creación de eventos. Nombre del evento. Teclado Interfaz de creación de evento. Sistema. El usuario debe haber accedido antes a la interfaz general correctamente, y por tanto este debe ser de la UCM y estar logueado en la aplicación. Se crea el evento con las características descritas por el usuario. • Acceder al perfil. Descripción: Entrada: Origen: Permite al usuario entrar a la opción de perfil. 10 Salida: Destino: Precondición: Postcondición: Ventana de interfaz de perfil. Sistema. El usuario debe haber accedido antes a la interfaz general correctamente, y por tanto este debe ser de la UCM y estar logueado en la aplicación. Se visualiza la interfaz de perfil. • Acceder a videos. Descripción: Entrada: Origen: Salida: Destino: Precondición: Postcondición: Permite al usuario acceder a la interfaz de videos. Ventana de interfaz de videos. Sistema. El usuario debe haber accedido antes a la interfaz general correctamente, y por tanto este debe ser de la UCM y estar logueado en la aplicación. Se visualiza la interfaz de videos. • Acceder a muro. Descripción: Entrada: Origen: Salida: Destino: Precondición: Postcondición: Permite al usuario entrar a la opción de muro. Ventana de interfaz de muro. Sistema. El usuario debe haber accedido antes a la interfaz general correctamente, y por tanto este debe ser de la UCM y estar logueado en la aplicación. Se visualiza la interfaz de muro. • Acceder a ayuda. Descripción: Entrada: Origen: Salida: Destino: Precondición: Postcondición: Permite al acceder entrar a la interfaz de ayuda. Ventana de interfaz de ayuda. Sistema. El usuario debe haber accedido antes a la interfaz general correctamente, y por tanto este debe ser de la UCM y estar logueado en la aplicación. Se visualiza la interfaz de ayuda o soporte técnico. 11 3.2.2. Requisitos de función de contactos. • Añadir contacto. Descripción: Entrada: Origen: Salida: Destino: Precondición: Postcondición: Permite al usuario crear un contacto para añadirlo a una lista y permitir la interacción entre ellos. Nombre del contacto. Teclado. Mensaje verificando que el contacto ha sido creado. Sistema. El nombre del contacto que se va a escribir no estaba previamente añadido a la lista del usuario. El sistema añade el contacto a la lista del usuario. • Eliminar contacto. Descripción: Entrada: Origen: Salida: Destino: Precondición: Postcondición: Permite al usuario eliminar un contacto perteneciente a la lista. Nombre del contacto. Teclado. Mensaje verificando que el contacto ha sido eliminado. Sistema. El nombre del contacto que se desea eliminar esta en la lista de contactos del usuario. El sistema elimina de la lista del usuario el contacto introducido. • Bloquear contacto. Descripción: Entrada: Origen: Salida: Destino: Precondición: Permite al usuario borrar un contacto perteneciente a la lista. Nombre del contacto. Teclado. Mensaje verificando que el contacto ha sido bloqueado. Sistema. El contacto que se desea borrar esta en la lista de contactos del usuario. 12 Postcondición: El sistema bloquea al contacto introducido por el usuario. • Crear grupos. Descripción: Entrada: Origen: Salida: Destino: Precondición: Postcondición: Permite al usuario crear un grupo de contactos Nombre de grupo que se desea crear. Teclado. Mensaje verificando que el grupo ha sido creado. Sistema. El usuario tiene mas de un contacto en su lista. El sistema crea un grupo con el nombre introducido por el usuario. 3.2.3. Requisitos de función de chat. Conexión de usuario Descripción Entrada Origen Salida Destino Precondición Postcondición Permite al usuario conectarse o desconectarse del chat cuando desee Ventana del chat Sistema El usuario debe ser de la UCM y estar logueado en la aplicación - Mostrar estado actual Descripción Entrada Origen Salida Destino Permite mostrar el estado actual del chat Muestra el estado actual del usuario Sistema 13 Precondición Postcondición El usuario debe ser de la UCM ,estar logueado en la aplicación y estar conectado al chat Muestra con distinto color el estado Mensaje de chat Descripción Entrada Origen Salida Destino Precondición Postcondición Permite escribir un mensaje instantáneo en la ventana del chat Caracteres introducidos Teclado Mensaje escrito Otro usuario El usuario debe ser de la UCM ,estar logueado en la aplicación y estar conectado al chat El mensaje enviado se muestra en la ventana Grupos de chat Descripción Entrada Origen Salida Destino Precondición Postcondición Permite crear un grupo de chat para mantener una conversación entre varios usuarios Ventana del chat común Varios usuarios El usuario debe ser de la UCM ,estar logueado en la aplicación y estar conectado al chat Se muestra ventana común donde se envían mensajes instantáneos al a vez 3.2.2. Requisitos de función de correo. Enviar correo Descripción Entrada Origen Salida Destino Permite enviar un correo a otro usuario de la aplicación Nombre del contacto, asunto de mensaje y el mensaje Teclado Usuario 14 Precondición Postcondición El usuario debe ser de la UCM y estar logueado en la aplicación. El mensaje se envía y se muestra un mensaje de éxito. Contestar al correo Descripción Entrada Origen Salida Destino Precondición Postcondición Permite contestar un mensaje recibido Asunto del mensaje y mensaje Teclado Usuario El usuario debe ser de la UCM ,estar logueado en la aplicación y tener un mensaje al que responder. El mensaje es enviado Borrar correo Descripción Entrada Origen Salida Destino Precondición Postcondición Permite borrar un mensaje recibido Sistema El usuario debe ser de la UCM ,estar logueado en la aplicación y tener un mensaje recibido. El mensaje es borrado. Adjuntar archivo Descripción Entrada Origen Salida Destino Precondición Postcondición Permite enviar archivos a otro usuario Archivo Usuario El usuario debe ser de la UCM ,estar logueado en la aplicación y estar conectado al chat El archivo se envía a otro usuario de la aplicación 15 3.3 Requisitos de rendimiento La carga esperada para la aplicación en su conjunto es muy elevada debido al alto número de usuarios de la red (aproximadamente 100.000) y a la posibilidad de concurrencia de esos usuarios. El sistema deberá soportar una carga de.50.000 usuarios conectados simultáneamente . UCM-ÁGORA deberá transcurrir sobre un servidor Intel Dual Xeon E5310, 4 GB RAM, 2X 500 GB HDD, 10 TB banda ancha, para que pueda soportar sin problemas la conexión de muchos usuarios. El tiempo de transacción por segundo de todas las operaciones se estimará en un número inferior a 1 segundo para de esta manera hacer que la interacción del usuario con la aplicación sea mucho más eficiente. 3.4 Requerimientos lógicos de la BBDD El sistema accederá a una base de datos externa (UCM) de la que extraerá los datos de los usuarios cada vez que se realiza un acceso a UCM-Ágora. Una vez logueado en el sistema, todas las interacciones del usuario se guardarán en la base de datos interna (UCM-Ágora). El almacenamiento y la actualización de los datos de UCM-Ágora se procesará de una manera periódica para evitar que en caso de caída del sistema se pierdan los datos. En caso contrario, dispondremos de unas copias de seguridad que se generan automáticamente si ocurre una caída inesperada del sistema recuperando los datos perdidos. Para el mantenimiento de este sistema de seguridad utilizaremos la tolerancia a fallos de serie en MySQL. 3.5 Restricciones de diseño: El almacemiento de los datos está sujeto a las restricciones de la Ley Orgánica de Protección de datos XXXXXX, siguiendo el siguiente estándar de cumplimiento 3.5.1 Estándares de cumplimiento: El fichero que almacena los datos de los usuarios debe seguir el siguiente estándar: sistema de notificación basado en un formato estándar que permita el intercambio de información entre diferentes plataformas (formato XML). De esta forma, tanto los responsables que desarrollen sus propios programas como los desarrolladores de paquetes ofimáticos de protección de datos para las PYME’s podrán comunicarse con la AEPD para notificar sus ficheros, pudiendo presentar sus solicitudes con y sin 16 certificado de firma electrónica. Para ello se pueden consultar las normas que deberán cumplir las aplicaciones desarrolladas por terceros para que puedan presentar validamente las notificaciones al RGPD. Estos mensajes en formato XML pueden ser presentados con y sin certificado electrónico de firma reconocido. En el caso de que se presenten firmados electrónicamente deberán utilizar el estándar de firma Xml Digital Signature, cuya especificación de sintaxis y procesamiento se encuentra en http://www.w3.org/2000/09/xmldsig# . En este caso, una vez enviadas las notificaciones al Registro Telemático de la AEPD, éste devolverá un mensaje confirmando la recepción del envío incluyendo, a su vez, los datos necesarios para que el programa desarrollado por terceros configure el acuse de recibo de acuerdo con el formato establecido en la Resolución de la Agencia Española de Protección de Datos de 12 de julio de 2006 por la que se aprueban los formularios electrónicos a través de los que deberán efectuarse las solicitudes de inscripción de ficheros en el Registro General de Protección de Datos, así como los formatos y requerimientos a los que deben ajustarse las notificaciones remitidas en soporte informático o telemático 3.6.1 Fiabilidad Se garantizará el correcto funcionamiento de todos los movimientos de los datos tanto de la base de datos externa como de la interna para proteger a los usuarios. También se preverá de una copia de seguridad (backups) para el caso de alguna pérdida. 3.6.2 Disponibilidad La disponibilidad de la aplicación estará relacionado con las garantías de seguridad y operatividad de los sistemas de la UCM. Nuestro sistema se mantendrá disponible durante las 24 horas del día. En caso de modificación o revisión se efectuará en un horario nocturno para mantener al usuario durante el tiempo diurno sin ningún problema en la aplicación. 3.6.3 Seguridad Al ser una aplicación en la que se mandarán mensajes que podrían leer terceras personas, es necesario idear un sistema que evite la suplantación de identidad, y ataques por denegación de servicio. Para ello, se asegurará que los mensajes que enviados entre cliente y servidor, así como los mensajes enviados entre el servidor y el encaminador destino, no puedan ser suplantados por terceras personas, de ahí la necesidad de utilizar passwords y un mecanismo de cifrado. Para poder cifrar mediante SSL, es necesario obtener un certificado de una autoridad o firmarse un certificado uno mismo. Muchos navegadores darán un aviso de seguridad si encuentran un certificado firmado por uno mismo. Para el desarrollo de la aplicación se utilizará este tipo de certificado a sabiendas de que no será válido para una 17 implantación real. La comunicación entre el cliente y el encaminador destino no requiere seguridad, si se desean enviar datos correrá por cuenta del usuario que vayan cifrados. El sistema deberá proporcionar la garantía de seguridad de los datos personales. Estos datos de la aplicación deberán mantenerse a salvo en caso de alteración, pérdida, uso o accesos no permitidos. Los datos personales solo podrán ser comunicados a un tercero en caso de cumplir los fines directamente relacionados con las funciones legítimas, como se fija en la normativa de protección de datos LOPD xxxxx Los usuarios obtendrán diferentes tipos de privilegios a la hora de tratar la información según el usuario necesite proteger la información hacia accesos no autorizados. 3.6.4 Capacidad de mantenimiento La aplicación se dejará estructurada para poder acometer en el futuro ampliaciones en la funcionalidad. La aplicación necesitará del mantenimento que conlleve el servidor donde está ejecutándose. Con el fin de facilitar el mantenimiento del software el sistema estará dividido en diferentes módulos y así se agilizará el proceso de mantenimiento de los desarrolladores. Asimismo, se le adjuntará la información necesaria sobre la aplicación y el modo de su desarrollo para obtener de manera más concisa el material para ajustarse de manera más próxima al sistema. 3.6.5 Portabilidad El sistema está desarrollado en software libre, por lo que podrá ser migrado a otro sistema que cumpla los requisitos mencionados en el punto 2.4.1 y 2.4.2. 18