REQUERIMIENTOS ESPECÍFICOS.Los requerimientos deben exponerse en la forma más precisa posible, pero sin que la descripción de un requisito individual resulte demasiado extensa. Si fuera necesario, puede darse una descripcion resumida y hacer referencia a un apéndice con la descripción detallada.

Es importante no incluir en los requerimientos aspectos de desarrollo o diseño. Los requerimientos son lo mínimo que se impone al sistema, y no hay que describir soluciones particulares que no sea obligatorio utilizar (excepto como aclaración o sugerencia).

Es ventajoso enunciar los requerimientos en forma de una lista numerada, para facilitar su seguimiento y la validación de sistema. Cada requerimiento debe ir acompañado de una indicación del grado de cumplimiento necesario, es decir, si es obligatorio, recomendable o simplemente opcional.

• Funcionales. Lo que el software debe de hacer. Se encuentran muy ligados al modelo conceptual propuesto. Se concretarán las operaciones de tratamiento de información que realiza el sistema, tales como almacenamiento de información, generación de informes, cálculos, estadísticas, operaciones, etc.

¿Qué hará el sistema?
¿Cuándo lo hará?
¿Existen varios modos de operación?
¿Cómo y cuándo puede cambiarse o mejorarse el sistema?
¿Existen restricciones de la velocidad de ejecución, tiempo de respuesta o rendimiento?

• Ambiente físico.

¿Dónde está el equipamiento que necesita el sistema para funcionar?
¿Existe una localización o varias?
¿Existen restricciones ambientales, tales como temperatura, humedad o interferencia magnética?

• Usuarios y factores humanos.

¿Quién usará el sistema?
¿Habrá varios tipos de usuario?
¿Cuál es el nivel de habilidad de cada tipo de usuario?
¿Qué clase de entrenamiento requerirá cada tipo de usuario?
¿Qué tan fácil le será a un usuario comprender y utilizar el sistema?

• Desempeño. Velocidad, disponibilidad, tiempo de respuesta, tiempo de recuperación, etc.

• Interfaz. Elemento de interacción con la gente, hardware u otro software. Se incluyen por lo tanto, bases de datos, protocolos, formatos de ficheros, sistemas operativos, datos, etc.

¿La entrada proviene de uno o más sistemas?
¿La salida va a uno o más sistemas?

• Restricciones de diseño. Estándares establecidos para el desarrollo.

• Operación. Son los referentes al uso del sistema en general e incluyen los requisitos de la interfase de usuario (menús de pantalla, manejo de mouse, teclado, etc.). el inicio y fin, copias de seguridad, requisitos de instalación y configuración.

• Recursos. Son los referentes a elementos de hardware, software, instalaciones, etc., necesarios para el funcionamiento del sistema. Es muy importante estimar los recursos con cierto coeficiente de seguridad en previsión de necesidades de última hora no provistas inicialmente.

• Verificación. Son los que debe cumplir el sistema para que sea posible verificar y certificar que funciona correctamente el sistema (funciones de autotest, emulación, simulación, etc.).

• Prueba de aceptación. Son los que deben cumplir las pruebas de aceptación a que se someterá el sistema.

• Documentación. Son los referentes a la documentación que debe formar parte del producto a entregar.

• Seguridad. Son los referentes a la protección del sistema contra cualquier manipulación o utilización indebida (confidencialidad, integridad, virus, etc.).

• Transportabilidad. Son los referentes a la posible utilización del sistema en diversos entornos o sistemas operativos de una forma sencilla y barata.

• Calidad. Son los referentes a aspectos de calidad que no se incluyan en otros apartados

• Fiabilidad. Son los referentes al límite aceptable de fallos o caídas durante la operación del sistema.

• Mantenibilidad. Son los que debe cumplir el sistema para que se pueda realizar adecuadamente su mantenimiento durante la fase de explotación.

• Capacidad. Son los referentes a los volúmenes de información a procesar, tiempo de respuesta, tamaños de ficheros o discos, etc. Estos requerimientos deben expresarse mediante valores numéricos e incluso, cuando sea necesario, se darán valores para el peor, el mejor y el caso más habitual.

• No funcionales. Describen atributos del sistema o atributos del ambiente del sistema y generalmente no son establecidas por el usuario.

• Implícitos. Son los que se asumen que el software debe de tener.

• Extras. Agregados que generan valor al producto de software.

rafa:

REQUERIMIENTOS FUNCIONALES Y NO FUNCIONALES

A menudo, los requerimientos de sistemas software se clasifican en funcionales y no funcionales, o como requerimientos del dominio:

1. Requerimientos funcionales. Son declaraciones de los servicios que debe proporcionar el sistema, de la manera en que éste debe reaccionar a entradas particulares y de cómo se debe comportar en situaciones particulares. En algunos casos, los requerimientos funcionales de los sistemas también pueden declarar explícitamente lo que el sistema no debe hacer.

2. Requerimientos no funcionales. Son restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo y estándares. Los requerimientos no funcionales a menudo se aplican al sistema en su totalidad. Normalmente apenas se aplican a características o servicios individuales del sistema.

3. Requerimientos del dominio. Son requerimientos que provienen del dominio de aplicación del sistema y que reflejan las características y restricciones de ese dominio. Pueden ser funcionales o no funcionales.

En realidad, la distinción entre diferentes tipos de requerimientos no es tan clara como sugieren estas definiciones. Por ejemplo. un requerimiento del usuario sobre seguridad podría parecer un requerimiento no funcional. Sin embargo, cuando se desarrolla en detalle, puede generar otros requerimientos que son claramente funcionales, como la necesidad de incluir en el sistema recursos para la autentificación del usuario.

REQUERIMIENTOS FUNCIONALES

Los requerimientos funcionales de un sistema describen lo que el sistema debe hacer. Estos requerimientos dependen del tipo de software que se desarrolle, de los posibles usuarios del software y del enfoque general tomado por la organización al redactar requerimientos. Cuando se expresan como requerimientos del usuario, habitualmente se describen de una forma bastante abstracta. Sin embargo. los requerimientos funcionales del sistema describen con detalle la función de éste, sus entradas y salidas, excepciones, etcétera.

Los requerimientos funcionales para un sistema software se pueden expresar de diferentes formas. A continuación se presentan algunos ejemplos de estos requerimientos funcionales para un sistema de biblioteca universitario, denominado LIBSYS y utilizado por estudiantes y personal docente que solicitan libros y documentos de otras bibliotecas.

l. El usuario deberá tener la posibilidad de buscar en el conjunto inicial de la base de datos o seleccionar un subconjunto de ella.

2. El sistema deberá proporcionar visores adecuados para que el usuario lea documentos en el almacén de documentos.

3. A cada pedido se le deberá asignar un identificador único (ID_PEDIDO), que el usuario podrá copiar al área de almacenamiento permanente de la cuenta.

Estos requerimientos funcionales del usuario definen los recursos específicos que el sistema debe proporcionar. Dichos requerimientos se toman del documento de requerimientos del usuario, e ilustran los diferentes niveles de detalle en que se pueden redactar los requerimientos funcionales (contraste los requerimientos l y 3).

El sistema LIBSYS es una interfaz única para diferentes bases de datos de artículos. Esto permite a los usuarios descargar copias de artículos publicados en revistas, periódicos y publicaciones científicas. Una descripción más detallada de los requerimientos para el sistema en el cual se basa LIBSYS se puede ver en mi libro con Gerald Kotonya sobre ingeniería de requerimientos (Kontonya y Sommerville, 1998).

La impresión en la especificación de requerimientos es la causa de muchos de los problemas de la ingeniería del software. Para un desarrollador de sistema es natural dar interpretaciones de un requerimiento ambiguo con el fin de simplificar su implementación. Sin embargo, a menudo no es lo que el cliente desea. Se deben establecer nuevos requerimientos y hacer cambios en el sistema. Por supuesto, esto retrasa la entrega de éste e incrementa los costes. Considere el segundo ejemplo de los requerimientos para el sistema de biblioteca que se refiere a los «visores adecuados» que debe proporcionar el sistema. El sistema de biblioteca puede mostrar documentos en diferentes formatos; la intención de este requerimiento es que los visores para todos estos formatos estén disponibles. Sin embargo, el requerimiento está ambiguamente redactado; no clarifica que se deben proporcionar los visores de cada formato.

Un desarrollador bajo la presión del tiempo sencillamente podría proporcionar un visor de texto y atinar que se ha cumplido el requerimiento. En principio, la especificación de requerimientos funcionales de un sistema debe estar completa y ser consistente. La completitud significa que todos los servicios solicitados por el usuario deben estar definidos. La consistencia significa que los requerimientos no deben tener definiciones contradictorias. En la práctica, para sistemas grandes y complejos, es prácticamente imposible alcanzar los requerimientos de consistencia y completitud.

Una razón de esto es que es fácil cometer errores y omisiones cuando se redactan especificaciones para sistemas grandes y complejos. Otra razón es que los stakeholders del sistema tienen necesidades diferentes, y a menudo contradictorias. Estas contradicciones pueden no ser obvias cuando los requerimientos se especifican por primera vez, por lo que se incluyen requerimientos contradictorios en la especificación. Es posible que los problemas surjan solamente después de un análisis más profundo o, a veces, después de que se termine el desarrollo y el sistema se entregue al cliente.

REQUERIMIENTOS NO FUNCIONALES

Los requerimientos no funcionales, como su nombre sugiere, son aquellos requerimientos que no se refieren directamente a las funciones específicas que proporciona el sistema, sino a las propiedades emergentes de éste como la fiabilidad, el tiempo de respuesta y la capacidad de almacenamiento. De forma alternativa, definen las restricciones del sistema como la capacidad de los dispositivos de entrada/salida y las representaciones de datos que se utilizan en las interfaces del sistema.

Los requerimientos no funcionales rara vez se asocian con características particulares del sistema. Más bien, estos requerimientos especifican o restringen las propiedades emergentes del sistema. Por lo tanto, pueden especificar el rendimiento del sistema, la protección, la disponibilidad, y otras propiedades emergentes. Esto significa que a menudo son más críticos que los requerimientos funcionales particulares.

Los usuarios del sistema normalmente pueden encontrar formas de trabajar alrededor de una función del sistema que realmente no cumple sus necesidades. Sin embargo. el incumplimiento de un requerimiento no funcional puede significar que el sistema entero sea inutilizable.

Por ejemplo, si un sistema de vuelo no cumple sus requerimientos de fiabilidad, no se certificará como seguro para el funcionamiento; si un sistema de control de tiempo real no cumple sus requerimientos de rendimiento, las funciones de control no funcionarán correctamente. Los requerimientos no funcionales no sólo se refieren al sistema software a desarrollar. Algunos de estos requerimientos pueden restringir el proceso que se debe utilizar para desarrollar el sistema. Ejemplos de requerimientos de procesos son la especificación de los estándares de calidad que se deben utilizar en el proceso, una especificación que el diseño debe producir con una herramienta CASE particular y una descripción del proceso a seguir.