Ingeniera del Software 1 Curso 2005-2006 13
6. Requisitos del software: tipos de requisitos
Qu son los Requisitos del Software
Es el nico lugar donde se pone por escrito la naturaleza exacta de la aplicacin
o Se elaboran a partir de los requisitos del usuario
o Son la base para el diseo y la implementacin
Diversas denominaciones: del software, del desarrollador, detallados, especficos...
El nivel de detalle debe ser completo, pero no redundante
o Lista completa de propiedades especficas y funcionalidad de la aplicacin
o A cada requisito se le sigue la pista hasta la implementacin
Diferencia con los requisitos del usuario: punto de vista del cliente, del desarrollador
Audiencia primaria, el desarrollador. El cliente puede estar interesado en ellos e
incluso entenderlos y hacer observaciones
Anctoda: en 1999 la NASA perdi un satlite porque se asumi que ciertos datos de
control estaban en unidades mtricas en lugar de anglosajonas. El defecto se identific
pocos das despus del desastre... (poda haberse identificado durante el anlisis)
No es una tarea estpida: organizar todos los requisitos bien detallados es una tarea
difcil que requiere saber organizar personas y documentacin
Clasificacin de requisitos del software
Requisitos inversos: lo que la aplicacin no debe hacer (son infinitos...)
o Pueden aclarar posibles malentendidos, el alcance del sistema
o Seleccionar aquellos que sirven para aclarar los verdaderos requisitos
o Ejemplo: la aplicacin no asesorar al usuario sobre...
o Dnde? Alcance del software (RU/RS). Anotacin a un requisito concreto
Requisitos funcionales (derivados de los requisitos de capacidad)
o Especifican la funcionalidad o servicios que la aplicacin debe proporcionar
Ejemplo: un tiempo de respuesta no es un requisito funcional
o Acompaados de un modelo de anlisis (Platform Independent Model - PIM)
Modelo conceptual: requisitos de informacin
Modelo de casos de uso: requisitos de operacin
Modelos de comportamiento que sean necesarios
Requisitos no funcionales (derivados de los requisitos de restriccin)
o Imponen restricciones: en el producto desarrollado, en el proceso de desarrollo
o Caractersticas distintivas:
cmo debe realizar algo el software, NO qu debe realizar
cortan transversalmente a los requisitos funcionales
son negociables hasta cierto punto, dentro de lmites aceptables
la medida de satisfaccin (o verificacin) no es todo/nada, sino gradual
o A veces denominados requisitos de calidad
La funcionalidad se presupone, la calidad satisface (o no)
o Ejemplos: consumo de recursos, rendimiento, fiabilidad y disponibilidad,
seguridad, portabilidad, mantenibilidad, modificabilidad, reusabilidad,
interfaces, amigabilidad, manejo de errores, uso de estndares, verificacin...
o Habitualmente peor analizados y documentados
Descritos de modo vago, informal, ambiguo (dificultan la verificacin)
Repetidos en muchos lugares (transversalidad)
Peor contemplados en los modelos
Separacin de incumbencias (separation of concerns) en los requisitos
o Definir por separado requisitos funcionales y no funcionales
o Componer los requisitos F y NF mediante tablas de referencias cruzadas
Ingeniera del Software 1 Curso 2005-2006 14
Consumo de recursos (Resource expenditure)
Especifican la cantidad de recursos que la aplicacin requiere
Ejemplos:
o Uso de memoria (voltil / permanente; o primaria / secundaria)
o Capacidad de trfico, lneas de atencin simultnea, etc.
Rendimiento (Performance)
Especifican restricciones temporales que la aplicacin debe cumplir
Son crticas en los sistemas de tiempo real
o Ejemplos: velocidad, tiempo de respuesta, etc.
Fiabilidad y disponibilidad (Reliability and availability)
En estos dos factores se reconoce que las aplicaciones difcilmente son perfectas, pero
s se exige un nivel de calidad mnimo
Fiabilidad: cuantifica los errores permisibles y su gravedad
o Ejemplo: el sistema no sufrir ms de dos fallos de nivel uno al mes
Disponibilidad: cuantifica el grado de disponibilidad de la aplicacin para los usuarios
o Ejemplo: la aplicacin no estar disponible como mximo durante 10 horas en
cualquier periodo de 30 das, y como mximo durante 2 horas seguidas
Manejo de errores (Error handling)
Cmo debe responder la aplicacin a errores de su entorno, o a errores internos
o Ejemplo: cmo reaccionar ante un mensaje en formato no reconocido
No se debe abusar del manejo de errores internos, que no deben existir (no debemos
cubrir nuestros errores con un cdigo interminable de manejo de errores)
o Ejemplo: determinar lo que hay que hacer si una funcin es llamada con
parmetros equivocados; esto slo se debe hacer si es preferible manejar el
error a la terminacin de la aplicacin
Requisitos de interfaz (Interface requirements)
Describen el formato con el que la aplicacin se comunica con su entorno
o Ejemplo (comunicacin con usuarios): El coste del envo se mostrar en la
esquina inferior derecha
o Ejemplo (comunicacin con otras aplicaciones): Los pedidos se transmitirn
en formato XML utilizando la plantilla DTD detallada en el anexo IV
Restricciones (Constraints)
Describen lmites o condiciones sobre cmo disear o implementar la aplicacin
Estos requisitos no deben suplantar el proceso de diseo, simplemente especifican
condiciones impuestas en el proyecto por el cliente, el entorno, u otras circunstancias
o Ejemplo (exactitud, precisin): las tarifas aplicadas se medirn en
diezmilsimas de euro
o Ejemplo (lenguaje, herramienta): se emplear el lenguaje Fortran, el gestor de
base de datos SQLServer...
o Ejemplo (arquitectura): se emplearn tecnologas de intranet y cliente-servidor
o Ejemplo (estndares): los informes generados se ajustarn al estndar XX-123
o Ejemplo (plataformas): la aplicacin deber funcionar sobre Windows 95
Seguridad (Security / Safety)
Security: seguridad del sistema frente a amenazas externas (confidencialidad,
integridad, disponibilidad, etc.)
Safety: seguridad de las personas frente a fallos del sistema
