Requisitos no funcionales

Anuncio
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
Descargar