Especificaciones suplementarias La especificacin complementaria captura todos los requisitos que no se pueden expresar en los casos de uso.

La especificacin de casos de uso tambin contiene los requisitos no funcionales si se aplican a casos de uso nico. La especificacin suplementaria contiene todos los requisitos genricos funcionales que no estn asociados a ninguna especfica casos de uso. Tabla 8.1 Asignacin de Requisitos de software entre la especificacin de casos de uso y especificaciones suplementarias Tipo de requerimiento Funcional Especificacin de los casos de uso Flujo bsico y los flujos alternativos relacionados con un caso de uso especfico. Especificaciones suplementarias Requisitos funcionales relacionados a ms de un caso de uso.

No funcional

Especificaciones funcionales relacionadas al caso de uso nico.

Requisitos no funcionales relacionados con los muchos casos de uso.

Una impresin comn es que los requerimientos funcionales slo en la Especificacin de Casos de Uso y que los requisitos no funcionales se encuentran en la especificacin complementaria. Esto puede deberse a: Requisitos no funcionales por lo general se aplican al sistema en su conjunto y no a cualquier caso de uso especfico. Requisitos funcionales son a menudo relacionados con un flujo especfico de los acontecimientos (especificacin de los casos de uso).

Los requisitos suplementarios son tambin llamados los requisitos arquitectnicos o los factores de calidad. Estos conceptos no son del todo sinnimo de requisitos adicionales pero que significan casi lo mismo en el contexto del proceso de desarrollo de software. En la pirmide de las necesidades, los requisitos adicionales se encuentran en el mismo nivel que los casos de uso.

Requisitos suplementarios

La recopilacin de requisitos adicionales es una tarea muy difcil debido a lo siguiente:

Los clientes a menudo se olvidan de estos requisitos y no los proporcionan a estos a menos que les pregunten. Los clientes suelen ser conscientes del coste de la mejora de indicadores especficos. Los usuarios no tcnicos a menudo tienen problemas para entender las implicaciones de algunos requisitos tcnicos. Algunos requisitos son difciles de medir, tales como "El sistema debe ser fcil de aprender."

El siguiente enfoque sugerido por Peter Eeles se refiere a soluciones a estos problemas:

1. Crear una lista de todas las categoras de los requisitos suplementarios. 2. Para cada categora, crear una o ms preguntas. 3. Explique al cliente el impacto y el costo de cada decisin. 4. Captura de la respuesta del cliente a cada pregunta. 5. Asignar prioridad o peso a cada necesidad.

En el paso 3, al explicar el impacto, es necesario mencionar el costo (tiempo de desarrollo ya es igual a mayor costo de desarrollo).

Clasificacin de los requisitos suplementarios Tabla 8.2 Clasificacin propuesta por McCall y Matsumoto Categora Operacin Subcategora Integridad Exactitud Confidencialidad Usabilidad Eficiencia

Revisin

Capacidad de mantenimiento Capacidad de prueba Flexibilidad

Transicin

Portabilidad Interoperabilidad Reutilizacin

Clasificacin utilizada por la norma ISO

Categora Funcionalidad

Subcategora Precisin Seguridad Interoperabilidad Idoneidad Conformidad

Confiabilidad

Madurez Tolerancia a fallos Capacidad de recuperacin

Usabilidad

Usabilidad

Eficiencia

Eficiencia

Capacidad de mantenimiento

Capacidad de prueba Mutabilidad Analizabilidad Estabilidad

Portabilidad

Adaptabilidad Conformidad Intercambialidad

Este libro sigue la clasificacin propuesta por Robert Grady [GRA92] y adaptado por Rational Software. Esta clasificacin se llama FURPS +, que corresponde a la funcionalidad, usabilidad, fiabilidad, rendimiento y compatibilidad. El + es un marcador de posicin para los distintos tipos de restricciones (el + es una sea de que se relaciona con el diseo):

Diseo, Implementacin, interfaz y fsica. La plantilla de Software especificaciones se encuentran en el RUP [RUP04] tambin contiene las secciones siguientes:

Documentacin del usuario en lnea y los requisitos del sistema de ayuda. Componentes comprados. Requisitos para la licencia Parte Jurdica, derechos de autor, y otros avisos Normas aplicables

La clasificacin propuesta en este captulo es un intento de cubrir muchos tipos de requisitos (obtenidos de varias clasificaciones) y el presente de forma coherente con la estructura FURPS + (cuadro 8.4). Esta clasificacin incluye cinco categoras cubiertas por FURPS, cuatro categoras cubiertas por +, y dos categoras de la plantilla de RUP.

Categoras: subcategoras

Funcionalidad Usabilidad: accesibilidad, esttica, ergonoma, facilidad de uso. Confiabilidad: disponibilidad, robustez, precisin, la capacidad de recuperacin, tolerancia a fallos, seguridad. Rendimiento: rendimiento, tiempo de respuesta, tiempo de recuperacin, Arranque / apagado tiempo, capacidad, utilizacin de los recursos. Compatibilidad: la capacidad de prueba, adaptabilidad, capacidad de mantenimiento, compatibilidad, configurabilidad, capacidad de actualizacin, facilidad de instalacin, escalabilidad, portabilidad, reutilizacin, interoperabilidad, conformidad, intercambiabilidad, mutabilidad, analizabilidad, localizacin. Restricciones de diseo Requisitos para la aplicacin Requisitos de la interfaz Requisitos fsicos Requisitos de documentacin Los requisitos de licencia y legales

Las siguientes secciones describen cada categora. Ninguno de ellos es obligatorio. Muchos de ellos pueden ser omitidos si no son aplicables. Sin embargo, un requisito debe ser excluido como resultado de una decisin planificada de un cliente y un analista de sistemas, no porque su importancia no fue analizada.

Funcionalidad: Esta seccin contiene los requisitos funcionales que no fueron capturadas en cualquiera de los casos de uso Usabilidad: Es multifactico. En esta seccin se define los requisitos de facilidad de uso en varias reas: Accesibilidad: Facilidad de acceso y uso de funcionalidad especfica. Ejemplo: Reservar un billete de avin de la funcionalidad estar disponible en el hogar desde la pgina. Esttica: La esttica de la interfaz de usuario y la descripcin de "look and feel". Ejemplo: los campos de entrada mltiple en una pgina se alinean verticalmente. IU coherencia: La consistencia de la interfaz de usuario, tanto en el sistema y con otros sistemas. Ejemplo: La interfaz de usuario debern ser compatibles con IBM CUA estndar. Para evitar ambigedades, cuando mencionamos una norma, vale la pena es hacer referencia a una fuente donde se describe esta norma. Ergonoma: Aspectos ergonmicos de la interfaz de usuario (para evitar clics innecesarios, evitando los movimientos incmodos con el ratn, y as sucesivamente). Ejemplo: Cuando un cuadro de dilogo que se abre, el foco estar en el primer campo de entrada en el cuadro de dilogo. Facilidad de uso: Facilidad de aprendizaje y el uso del sistema. Ejemplo: No se requieren conocimientos tcnicos (excepto para el uso del navegador) estarn obligados a utilizar el sistema. Ejemplo: El proveedor de servicios ser capaz de aprender a utilizar el sistema en una hora. Si no desea crear esta seccin especial, estos requisitos tambin pueden ser insertados en la seccin de accesibilidad.

Confiabilidad: Esta seccin abarca los distintos aspectos de la fiabilidad del sistema: Disponibilidad: Porcentaje de tiempo que el sistema est disponible, el tiempo medio entre errores. Ejemplo: El sistema estar disponible el 99,93% de las veces. Robustez: Capacidad del sistema para resistir las perturbaciones externas, tales como la entrada no vlida o escasez de recursos. Ejemplo: Por cada entrada no es vlida para el usuario, el sistema mostrar un mensaje de errores significativos que explican lo que el formato de entrada que se espera. Precisin: La precisin con la que el sistema calcula los valores. Ejemplo: las cantidades de divisas se calculan y se almacenan con una precisin de dos decimales. La capacidad de recuperacin: Cmo elegantemente el sistema se recupera de un fracaso. En esta seccin se preocupan por la elegancia y la ausencia de efectos secundarios, mientras que el tiempo de recuperacin se describe en la seccin Rendimiento. Sin embargo, tambin es bien combinar ambos aspectos de la recuperacin en un solo lugar. Tolerancia a fallos: Sensibilidad del sistema al fracaso de algunas de sus partes. Seguro: Toda amenaza a los usuarios, los datos, los componentes del sistema, o sistemas de interoperabilidad que presenta el uso del sistema. Seguridad: Nivel de proteccin en relacin con el acceso a partes especficas del sistema. Ejemplo: clave de acceso ser necesario para acceder a las pantallas de administrador Exactitud: Cmo de errores o sin defectos, el sistema se efectuarn. Ejemplo: Si va a enviar una lista de los vuelos, el sistema no se puede perder ningn vuelo directo o de cualquier vuelo con una sola escala. Rendimiento: Esta seccin cubre los diversos indicadores de rendimiento del sistema.

Rendimiento: La velocidad a la que el sistema lleva a cabo sus tareas. Esto se puede expresar, por ejemplo, en el nmero de transacciones por minuto. Ejemplo: El sistema debe adaptarse a 1.000 vuelos reservados por minuto. Tiempo de respuesta: Qu tan rpido el sistema responde a los eventos? Ejemplo: sistema de tiempo medio de respuesta debe ser menos de dos segundos.

Tiempo de recuperacin: A qu velocidad el sistema se recupera del fracaso. Es importante distinguir entre la momento en que el sistema entre en funcionamiento desde el punto de vista del usuario (por lo general porque un sistema redundante reanuda sus operaciones) y el momento en que el problema es en realidad fija. Aunque el cambio a un sistema redundante se suele hacer de forma automtica, de resolver el problema original, muy a menudo requiere intervencin humana. Ejemplo: En el caso de un fallo del sistema, un sistema redundante se reanudar operaciones en 30 segundos. Arranque / apagado tiempo: La cantidad de tiempo que se tarda en poner en marcha y parada. Ejemplo: El sistema estar en marcha dentro de un minuto de la puesta en marcha. Capacidad: El nmero de usuarios que el sistema puede acomodar. Ejemplo: El sistema deber albergar a 5.000 usuarios concurrentes. Utilizacin de los recursos: Utilizacin de la memoria, espacio en disco, almacenamiento de bases de datos, y as sucesivamente. Ejemplo: El sistema deber almacenar en la base de datos no ms de un milln de transacciones. Compatibilidad La compatibilidad se refiere a numerosos aspectos de mantenimiento y modificacin del sistema. La capacidad de prueba: Lo fcil que es poner a prueba el sistema. Es la integracin con las herramientas de pruebas. Ejemplo: La interfaz de usuario no contiene ningn componente que impida las pruebas automatizadas con IBM Rational Robot y IBM Rational Functional Tester. Adaptabilidad: La facilidad con que el sistema se adapta a nuevos entornos. Ejemplo: El tiempo de despliegue de una nueva versin de WebSphere Application Server no podr ser superior a un da. Capacidad de mantenimiento: Qu tan fcil es localizar y reparar los errores. Ejemplo: un registro de errores que contiene informacin sobre todos los errores crticos debern ser accesibles al administrador del sistema a travs de Internet a fin de que se puede comprobar de forma remota en cualquier momento. Compatibilidad: El sistema de grado de compatibilidad con versiones anteriores del sistema, con el sistema que est reemplazando, y con interfaces. Ejemplo: Despus de que el sistema est en produccin, las versiones posteriores del sistema debe ser compatible con versiones anteriores. Todas las operaciones realizadas en las versiones anteriores estarn disponibles en la nueva versin.

Configurabilidad: Cmo configurar el sistema una vez instalado. Qu caractersticas deber ser configurable? Capacidad de actualizacin: Lo fcil que es para ampliar el sistema con nuevas caractersticas. Ejemplo: No requiere instalacin de estacin de trabajo del cliente debe ser requerido. Todo el sistema de actualizaciones y nuevas versiones se debe hacer en el servidor. De configuracin y capacidad de actualizacin a veces se llama flexibilidad. Facilidad de instalacin: Facilidad de instalacin del sistema. Ejemplo: Instalacin de una nueva versin del sistema no se requiere ninguna instalacin en estaciones de trabajo de los usuarios. Escalabilidad: Qu tan fcil las escalas del sistema de datos de volumen o los usuarios. Qu volumen de usuarios del sistema se soporte en el tiempo. Ejemplo: Despus de seis meses de funcionamiento, el sistema deber ser capaz de acomodar un adicional de 5.000 usuarios. Portabilidad: Qu tan fcil es mover a otra plataforma de software o hardware. Ejemplo: Cambiar la base de datos del sistema en el futuro no ser necesario volver a escribir la lgica de aplicacin. Reutilizacin: Lo fcil que es volver a utilizar partes de otros sistemas. Ejemplo: La funcin principal del sistema (la reserva del vuelo, la compra de un billete de avin, reservar una habitacin de hotel, reservar un coche) se en capsula en los componentes que pueden ser reutilizados en un entorno cliente / servidor (no por Internet) de la aplicacin Interoperabilidad: Qu tan fcil es la de cooperar con otros sistemas. La interoperabilidad es la capacidad de los productos, sistemas o procesos de negocio para el trabajo juntos para realizar una tarea comn. Ejemplo: El sistema deber reservar un billete con la reserva de vuelos Sistema sin necesidad de intervencin humana. Conformidad: Qu tan bien el sistema cumple con las normas y los reglamentos. Ejemplo: La recopilacin de informacin personal de una persona que compra boletos de avin deber estar en conformidad con la Ley Patriota. Intercambiabilidad: Qu tan fcil es reemplazar los componentes del sistema Mutabilidad: Lo fcil que es cambiar la funcionalidad del sistema. Analizabilidad: Lo fcil que es para analizar el sistema. Auditabilidad: Qu tan fcil es el control de la operacin del sistema.

Localizacin: Los idiomas que el sistema soportar. Lo fcil que es para ampliar el sistema con un nuevo lenguaje. Ejemplo: La aplicacin estar disponible en Ingls, francs y espaol

Restricciones de diseo Los requisitos relacionados con el diseo del sistema y la arquitectura. Ejemplo: El sistema se basar en la arquitectura J2EE Requisitos para la aplicacin. Ejemplos de requisitos de aplicacin son los siguientes:

Lenguajes de programacin utilizado para desarrollar el sistema Los sistemas operativos y sus versiones Bases de datos que se utilizan Componentes de terceros Los lmites de recursos: memoria, espacio en disco Los estndares de codificacin

Requisitos de la interfaz Esta seccin describe las diferentes interfaces:

Las interfaces de usuario Las interfaces de hardware Interfaces de Software Interfaces de comunicaciones

Requisitos fsicos Los requisitos fsicos son por lo general se refieren nicamente a hardware en el que se ha implementado el sistema. Se puede especificar, por ejemplo, la forma del dispositivo, el tamao o peso. No es aplicable a aplicaciones basadas en Web.

Requisitos de documentacin Los requisitos relacionados con la documentacin pueden contener

Documentacin impresa Documentacin disponible en CD

Los documentos disponibles en lnea Ayuda en lnea

Ejemplo: La Gua del administrador deber estar disponible como documento PDF. La parte en lnea de estas necesidades (incluyendo la ayuda) es algunas veces, de la seccin de Funciones de la especificacin complementaria.

Requisitos de licencia y Legales Esta seccin contiene los requisitos legales, reglamentarios y de licencia. Ejemplo: En las pginas que recogen los datos personales del usuario, habr un enlace a una pgina que describe la poltica de privacidad.

Atributos del requisito suplementario

Los atributos por omisin de los requisitos suplementarios son: Prioridad Estado Dificultad para Estabilidad Riesgo Nombre del contacto Autor Ubicacin Mejora de Solicitud Defecto Obsoletos

Esta lista puede variar ligeramente dependiendo de la versin de RequisitePro y del nmero de usuarios y su rendimiento .
En fin como conclusin podemos decir que dependiendo del alcance, los

requisitos de software puede residir en las Especificaciones de Casos de Uso o en las especificaciones suplementarias .Los Requisitos complementarios, junto con los casos de uso capturan todos los requisitos de software del sistema. La mayora de los requisitos suplementarios no son funcionales. Se refieren a la facilidad de uso, fiabilidad, rendimiento, compatibilidad y restricciones de diseo. Una forma comn de provocar requisitos adicionales es a travs de entrevistas y cuestionarios utilizando una lista predefinida de preguntas. La lista de requisitos se organiza de acuerdo a una clasificacin elegida, como FURPS +[GRA92]. Debido a que una pequea mejora en el rendimiento o la confiabilidad puede ser muy costosa en trminos de recursos necesarios, es importante captar la importancia y la forma de satisfaccin de cada necesidad. El anlisis de estos atributos pueden ayudar de manera ptima a la asignacin de los recursos y dirigir los esfuerzos que se les exija ms. Despus de capturar todos los requerimientos en RequisitePro, deberamos establecer la trazabilidad de las caractersticas .