Projecte d’Enginyeria del Software i Bases de Dades Departament de Llenguatges i Sistemes Informàtics Facultat d’Informàtica Advanced PFC management Requisitos no funcionales Nº Equipo: Versión: Fecha: Primavera 06/07 15 <1.4> 30/03/2007 Advanced PFC management Requisitos no funcionales Llenguatges i Sistemes Informàtics PESBD Equipo : 15 Primavera 06/07 Revisiones Versión Fecha Nombre Descripción/Cambios 1.1 21/03/07 Jonás Mate Granado Primera versión 1.2 23/03/07 Jonás Mate Granado Actualización de funcionamiento, utilidad y confiabilidad 1.3 30/03/07 Jonás Mate Granado Actualización de interfaces, definiciones y licencia Control de Participantes Nombre Jonás Granado Dni % Mate 47834813 100 Descripción trabajo realizado Requisitos no funcionales Nombre/Apellidos Nombre/Apellidos 2 Advanced PFC management Llenguatges i Sistemes Informàtics PESBD Requisitos no funcionales Equipo : 15 Primavera 06/07 CONTENIDO 1 INTRODUCCIÓN...................................................................................................................... 4 1.1 1.2 1.3 1.4 2 FUNCIONALIDAD.................................................................................................................... 4 2.1 3 TIEMPO DE RESPUESTA ........................................................................................................ 7 RENDIMIENTO ...................................................................................................................... 7 CAPACIDAD ......................................................................................................................... 7 UTILIZACIÓN DE RECURSOS .................................................................................................. 7 SOPORTE ................................................................................................................................ 8 6.1 7 DISPONIBILIDAD ................................................................................................................... 6 MTBF ................................................................................................................................. 6 MTTR ................................................................................................................................. 6 TASA DE FALLOS .................................................................................................................. 6 EXACTITUD .......................................................................................................................... 7 FUNCIONAMIENTO ................................................................................................................. 7 5.1 5.2 5.3 5.4 6 FACILIDAD DE APRENDIZAJE.................................................................................................. 5 FIABILIDAD EN EL USO .......................................................................................................... 5 CONFIABILIDAD ..................................................................................................................... 6 4.1 4.2 4.3 4.4 4.5 5 CAPACIDAD DE AUTOMATIZAR LOS PROCESOS DE GESTIÓN DE UN PFC ................................... 5 UTILIZACIÓN ........................................................................................................................... 5 3.1 3.2 4 PROPÓSITO ......................................................................................................................... 4 ÁMBITO ............................................................................................................................... 4 DEFINICIONES, ACRÓNIMOS Y ABREVIACIONES ...................................................................... 4 VISIÓN GENERAL ................................................................................................................. 4 ESTÁNDARES DE CÓDIGO ..................................................................................................... 8 RESTRICCIONES DE DISEÑO................................................................................................ 8 7.1 7.2 7.3 7.4 LENGUAJES DE PROGRAMACIÓN ........................................................................................... 8 PROCESO DE SOFTWARE ..................................................................................................... 8 RESTRICCIONES ARQUITECTÓNICAS ...................................................................................... 8 COMPONENTES DE PROVEEDORES EXTERNOS ....................................................................... 9 8 DOCUMENTACIÓN ONLINE DE USUARIO Y REQUISITOS DEL SISTEMA DE AYUDA ...... 9 9 COMPONENTES COMPRADOS ............................................................................................. 9 10 INTERFACES .......................................................................................................................... 9 10.1 INTERFACES DE USUARIO ..................................................................................................... 9 10.2 INTERFAZ DE SOFTWARE ...................................................................................................... 9 10.3 INTERFACES DE COMUNICACIÓN............................................................................................ 9 11 REQUISITOS DE LICENCIA.................................................................................................... 9 12 LEGALIDAD, COPYRIGHT Y OTROS AVISOS .................................................................... 10 13 ESTÁNDARES APLICABLES ............................................................................................... 10 3 Advanced PFC management Llenguatges i Sistemes Informàtics PESBD Requisitos no funcionales Equipo : 15 Primavera 06/07 1 Introducción Los Requisitos no Funcionales capturan los requerimientos del sistema que no han sido capturados en el modelo de casos de uso. Los requerimientos incluyen: - 1.1 Requerimientos legales y regulatorios, incluyendo aplicaciones estándar. La calidad de los atributos del sistema a construir, incluyendo usabilidad, confiabilidad, funcionamiento, y requisitos de soportabilidad. Otros requerimientos como los sistemas operativos y entornos, requerimientos de compatibilidad, y apremios del diseño. Propósito El propósito de este documento es especificar los requisitos no funcionales del nuevo sistema que vamos a diseñar, Advanced PFC Management. Estos requisitos son todos los que no se pueden expresar en función de los casos de uso. 1.2 Ámbito El proyecto en cuestión es un gestor avanzado de PFCs que facilite y automatice la mayor parte de la faena que actualmente gestiona secretaría. Éste documento especifica los requisitos no funcionales que deberá tener el sistema como capacidad, interfaces, etc. 1.3 Definiciones, Acrónimos y Abreviaciones Ver Glosario 1.4 Visión General Este documento se organiza en subdivisiones que explican los diferentes requisitos no funcionales del sistema. 2 Funcionalidad Esta sección describe los requerimientos funcionales del sistema para todos esos requerimientos que son expresados con el estilo natural del lenguaje. Para muchas aplicaciones, esto debe constituir la parte principal del paquete SRS y se deben dar a la organización de esta sección. Esta sección esta típicamente organizada por características, pero métodos alternativos de organización, por ejemplo organización por usuario u organización por subsistema, puede ser también apropiada. Los requisitos funcionales pueden incluir características, capacidades, y seguridad. Donde las herramientas de desarrollo de aplicaciones, como requisitos de herramientas, herramientas de modelado, etc., están empleados para capturar las funcionalidades, esta 4 Advanced PFC management Llenguatges i Sistemes Informàtics PESBD Requisitos no funcionales Equipo : 15 Primavera 06/07 sección del documento se referirá a la disponibilidad de este dato, indicando la localización y el nombre de la herramienta utilizada para capturar el dato. 2.1 Capacidad de automatizar los procesos de gestión de un PFC Automatizar los procesos de negocio tales como búsqueda de PFC por parte de los alumnos, como la búsqueda de alumnos que deseen realizar un PFC por parte de empresas y profesores. También debe automatizar el proceso de inscripción del PFC ahorrando tiempo y papeleo. Gestión de la petición de requisitos para el PFC, modificación del mismo y gestión de la búsqueda de fecha y hora para la lectura y defensa del PFC. En ultimo lugar también automatizará la propuesta de un PFC para matricula de honor. 3 Utilización Esta sección debe incluir todos los requisitos que afectan a la utilización. Por ejemplo: 3.1 - Especificación de los requisitos del tiempo de aprendizaje para un usuario normal y para un usuario avanzado para empezar a producir operaciones particulares. - Especificación de los tiempos mesurables para la tarea típica, o - Especificación de los requisitos para cumplir con los estándares comunes de utilización, por ejemplo, IBM’s CUA estándares o Microsoft’s GUI estándar. Facilidad de aprendizaje El sistema necesitará una gran facilidad de aprendizaje cosa que se conseguirá gracias que estará integrado en un sistema ya conocido por los usuarios (el Racó). 3.2 Fiabilidad en el uso Con fiabilidad en el uso nos referimos al porcentaje de errores cometidos por el usuario en el uso del sistema y el tiempo que se tarda en recuperarse de estos errores La fiabilidad en el uso de nuestro sistema deberá ser alta ya sea a través de su sencillo uso o a múltiples mensajes de confirmación. Lo más importante en la fiabilidad de uso es que el sistema estará integrad con un sistema ya conocido por los usuarios, cosa que aumenta en gran medida la fiabilidad de uso de nuestro sistema. 5 Advanced PFC management Llenguatges i Sistemes Informàtics PESBD Requisitos no funcionales Equipo : 15 Primavera 06/07 4 Confiabilidad Requisitos para la confiabilidad del sistema deben ser especificados aquí. Algunas sugerencias: - - 4.1 Disponibilidad – especifica el porcentaje del tiempo disponible (xx.xx%), horario de utilización, condiciones de mantenimiento, operaciones a efectuar en caso de degradación, etc. Mean Time Between Failures (MTBF) – esto es normalmente especificado en horas pero podría estar especificado en base a días, meses o años. Mean Time To Repair (MTTR) – ¿Cuanto tiempo esta el sistema caído después de que haya fallado? Exactitud – Especificación de la precisión (resolución) y exactitud (por algunos estándares conocidos) que son requeridos en la salida del sistema. Máximo número de errores – normalmente expresado en términos como bugs/KLOC (miles de líneas de código), o bugs/function-point. Bugs o tasa de fallos – clasificados en términos de mínimos, significativos, y críticos: los requisitos deben definir que significa error crítico (por ejemplo, perdida completa de los datos o completa inoperancia para usar ciertas partes de la funcionalidad del sistema) Disponibilidad El sistema tiene que estar disponible 100% del tiempo. Las 24 horas del día los 7 días de la semana. 4.2 MTBF El tiempo medio entre fallos debería de ser bastante alto. Estaríamos hablando de un mes o dos entre fallo y fallo. 4.3 MTTR El sistema tendría que poder recuperarse de una caída en uno o dos días. 4.4 Tasa de fallos Error crítico o fatal – Perdida completa de los datos acerca de PFCs y propuestas de PFC. Error significativo – Inoperancia del sistema. Error mínimo – Lenta respuesta del sistema. 6 Advanced PFC management Llenguatges i Sistemes Informàtics PESBD Requisitos no funcionales Equipo : 15 Primavera 06/07 4.5 Exactitud La exactitud del sistema tiene que ser muy alta ya que no es permisible que se de información errónea a los usuarios. 5 Funcionamiento Las características de funcionamiento del sistema deben estar definidas en esta sección. Incluyendo tiempos de respuesta específicos. Cuando sea aplicable, referirse a los casos de uso por el nombre. 5.1 - Tiempo de respuesta para una transacción (medio, máximo) - Rendimiento (por ejemplo, transacciones por segundo) - Capacidad (por ejemplo, el número de usuarios o transacciones que el sistema puede soportar) - Modos de degradación (cual es el modo aceptable del sistema cuando éste ha sido degradado de alguna manera) - Utilización de recursos: memoria, disco, comunicaciones, etc. Tiempo de respuesta El sistema que estamos diseñando será un sistema distribuido que interactuará con otros sistemas lo que dificultará un buen tiempo de respuesta, en todo caso dicho tiempo de respuesta no puede ser superior a 2 segundos y sería ideal que fuera de un solo segundo. 5.2 Rendimiento La carga del sistema en algunos momentos puede ser bastante alta con lo cual se esperará un buen rendimiento del mismo. 5.3 Capacidad El sistema tiene que poder soportar la carga de usuarios correspondiente al número medio de estudiantes que cursan el PFC cada año. 5.4 Utilización de recursos Utilizará principalmente recursos de comunicación ya que será un sistema Web y tendrá que comunicarse con otras aplicaciones como por ejemplo prisma, tendrá que disponer de líneas de atención simultáneas. 7 Advanced PFC management Llenguatges i Sistemes Informàtics PESBD Requisitos no funcionales Equipo : 15 Primavera 06/07 El sistema no tendrá funcionalidades que requieran de un gran procesamiento pero si que necesitará una memoria capaz de mantener mucha información como sería el estado de los PFCs que están inscritos. El sistema ya se conectará a un sistema de almacenaje de datos persistente, como por ejemplo una base de datos, con lo cual las necesidades de disco no serán significativas. 6 Soporte Esta sección indica los requisitos que realzan el soporte o el mantenimiento del sistema a construir, incluyendo estándares de código, convención de nombres, librerías de clases, mantenimiento del acceso, mantenimiento de las utilidades. 6.1 Estándares de código El sistema estará basado en tecnología J2EE ya que el sistema será distribuido y organizado de forma modular (ver Visión). El estándar de código que se utilizará será el mismo que se utiliza en la FIB. 7 Restricciones de diseño Esta sección debe indicar cualquier restricción de diseño en el sistema que vamos a construir. Las restricciones de diseño representan las decisiones de diseño que se han asignado por mandato y que se deben adherir. Ejemplos incluyen lenguajes de software, requisitos del proceso de software, restricciones de arquitectura y diseño, componentes comprados, librerías de clases, etc. 7.1 Lenguajes de programación El lenguaje de programación que se utilizará será java que nos aportará beneficios en seguridad, portabilidad, escalabilidad y seguridad. 7.2 Proceso de Software El proceso de software que se seguirá para desarrollar el sistema será RUP 7.3 Restricciones arquitectónicas El sistema tiene que ser distribuido y estar integrado en el Racó. 8 Advanced PFC management Llenguatges i Sistemes Informàtics PESBD Requisitos no funcionales Equipo : 15 Primavera 06/07 7.4 Componentes de proveedores externos Como componentes externos tendríamos el Racó, en el cual nuestro sistema tendrá que integrarse aprovechando las interfaces de usuario de que éste ya dispone. 8 Documentación online de usuario y requisitos del sistema de ayuda El sistema deberá incorporar un sistema de ayuda en línea que explique las funcionalidades del sistema y un mecanismo de notificación de incidencias. 9 Componentes comprados El sistema necesitará de la compra o alquiler de un servidor externo que se utilizará de forma exclusiva para nuestro sistema. 10 Interfaces Esta sección define la interfaz que tiene que ser soportada por la aplicación. Ésta debe contener una adecuada especificación, protocolos, puertos y direcciones lógicas, etc., así que el software puede ser desarrollado y verificado contra los requisitos de la interfaz. 10.1 Interfaces de usuario Los interfaces de usuario de nuestro sistema estarán integrados en el ya existente Racó 10.2 Interfaz de software La principal interfaz de software que necesitará nuestro sistema será una interfaz de comunicación con prisma. 10.3 Interfaces de comunicación Nuestro sistema tiene que poder soportar redes de área local y sistemas Web. 11 Requisitos de licencia La aplicación será software libre con licencia BSD. 9 Advanced PFC management Llenguatges i Sistemes Informàtics PESBD Requisitos no funcionales Equipo : 15 Primavera 06/07 12 Legalidad, Copyright y otros avisos Esta sección describe cualquier queja legal, garantías, avisos de copyright, avisos de patentes, marca comercial o logo del software. 13 Estándares Aplicables El sistema tendrá que ser compatible con los sistemas operativos que utilicen en la FIB, y también tendrá que estar bajo sus estándares reguladores y de legalidad. 10