“Tipos de requisitos para el desarrollo de software y sus características”
Los requisitos software son la descripción de las características y las funcionalidades del sistema. Los requisitos nos comunican las expectativas de los consumidores de productos software. Los requisitos pueden ser obvios o estar ocultos, conocidos o desconocidos, esperados o inesperados, desde el punto de vista del cliente.
En líneas generales los requisitos de software se deben caracterizar en dos categorías:
Requisitos funcionales:
Son declaraciones de los servicios que proveerá el sistema, de la manera en que éste reaccionará a entradas particulares. En algunos casos, los requerimientos funcionales de los sistemas también declaran explícitamente lo que el sistema no debe hacer.
Los requerimientos funcionales de un sistema describen la funcionalidad o los servicios que se espera que éste provea. Estos dependen del tipo de software y del sistema que se desarrolle y de los posibles usuarios del software. Cuando se expresan como requerimientos del usuario, habitualmente se describen de forma general mientras que los requerimientos funcionales del sistema describen con detalle la función de éste, sus entradas y salidas, excepciones, etc.
Muchos de los problemas de la ingeniería de software provienen de la imprecisión en la especificación de requerimientos. Para un desarrollador de sistemas 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 tienen que estipular nuevos requerimientos y se deben hacer cambios al sistema, retrasando la entrega de éste e incrementando el costo.
En principio, la especificación de requerimientos funcionales de un sistema debe estar completa y ser consistente. La compleción significa que todos los servicios solicitados por el usuario están definidos. La consistencia significa que los requerimientos no tienen definiciones contradictorias. En la práctica, para sistemas grandes y complejos, es imposible cumplir los requerimientos de consistencia y compleción.
La razón de esto se debe parcialmente a la complejidad inherente del sistema y parcialmente a que los diferentes puntos de vista tienen necesidades inconsistentes. Estas inconsistencias son obvias cuando los requerimientos se especifican por primera vez. Los problemas emergen después de un análisis profundo. Una vez que éstos se hayan descubierto en las diferentes revisiones o en las fases posteriores del ciclo de vida, se deben corregir en el documento de requerimientos.
Ejemplos:
Buscar una opción dada al usuario para buscar desde varias facturas.
El usuario debe ser capaz de enviar por correo electrónico cualquier informe a la Dirección.
Los usuarios se pueden dividir en grupos y los grupos pueden tener derechos diferentes.
Debe cumplir reglas empresariales y funciones administrativas.
El Software se desarrolla manteniendo intacta la compatibilidad en descenso.
El sistema debe emitir un comprobable al generar la entrega de mercadería.
Requisitos no funcionales:
Son restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo, estándares, etc.
Son aquellos requerimientos que no se refieren directamente a las funciones específicas que entrega el sistema, sino a las propiedades emergentes de éste como la fiabilidad, la respuesta en el tiempo y la capacidad de almacenamiento. De forma alternativa, definen las restricciones del sistema como la capacidad de los dispositivos de entrada/salida y la representación de datos que se utiliza en la interface del sistema.
Muchos requerimientos no funcionales se refieren al sistema como un todo más que a rasgos particulares del mismo. Esto significa que a menudo con más críticos que los requerimientos funcionales particulares. Mientras que el incumplimiento de este último degradará el sistema, una falla en un requerimiento no funcional del sistema lo inutiliza.
Los requerimientos no funcionales surgen de la necesidad del usuario, debido a las restricciones en el presupuesto, a las políticas de la organización, a la necesidad de interoperabilidad con otros sistemas de software o hardware o a factores externos como los reglamentos de seguridad, las políticas de privacidad, etc.
Ejemplos:
Seguridad
Acceso
Almacenaje
Configuración
Actuación
Coste
Inter operabilidad
Flexibilidad
Recuperación de desastre
Accesibilidad
Características de los requerimientos.
1. Correcta:
Una SRS es correcta, sí y solo sí, cada requisito especificado es un requisito que el software debe cumplir.
2. No ambigua:
Una SRS no es ambigua sí y solo sí cada requisito especificado tiene sólo una interpretación.
3. Completa:
Una SRS es completa, sí y solo sí, incluye los siguientes elementos:
a) Todos los requisitos significativos, ya sea que se relacionen a funcionalidad, desempeño, restricciones de diseño, atributos o interfaces externas.
En particular cualquier requisito externo impuesto por una especificación del sistema debe ser reconocido y tratado.
b) Definición de las respuestas del software a todos los tipos posibles de clases de datos de entrada en todos los tipos posibles de clases de situaciones. Notar que es importante especificar las respuestas tanto para valores de entrada válidos como inválidos.
c) Etiquetas y referencias completas a todas las figuras, tablas y diagramas en la SRS, así como la definición de todos los términos y unidades de medida.
4. Consistente:
Una SRS es consistente, sí y solo sí, no se contradice a sí misma, es decir, si ningún subconjunto de requisitos ahí descritos se contradice o entran en conflicto.
5. Jerarquizada de acuerdo a la importancia y/o estabilidad:
Una SRS está calificada de acuerdo a la importancia y/o estabilidad si cada requisito tiene un identificador que indique la importancia o estabilidad del requisito.
6. Verificable:
Una SRS es verificable, sí y solo sí, cada requisito especificado es verificable. Un requisito es verificable sí y solo sí existe un proceso finito de costo-efectivo con el cual una persona o una máquina puede verificar que el producto de software cumple el requisito. En general cualquier requisito ambiguo no es verificable.
7. Modificable:
Una SRS es modificable, sí y solo sí, su estructura y estilo son tales que, cualquier cambio a los requisitos pueden ser hechos fácil, completa y consistentemente sin perder la estructura y el estilo.
La modificabilidad generalmente requiere que una SRS:
a) Tenga una organización coherente y fácil de usar con una tabla de contenido, un índice y referencias cruzadas explícitas.
b) No sea redundante (esto es, el mismo requisito no debe aparecer en más de una parte en la SRS).
c) Expresa cada requisito de manera separada, en vez de hacerlo mezclado con otros requisitos
8. Rastreable:
Una SRS es rastreable si el origen de cada uno de sus requisitos es claro y si facilita la referencia de cada requisito en el desarrollo futuro o mejora de la documentación.
Se recomiendan los siguientes dos tipos de rastreabilidad:
a) Rastreabilidad hacia atrás (esto es, a estados previos del desarrollo). El requisito tiene referencias explícitas a sus fuentes en documentos anteriores.
b) Rastreabilidad hacia enfrente (esto es, a todos los documentos derivados del SRS). Depende de que cada requisito en la SRS tenga un nombre único o número de referencia. Es particularmente importante cuando el software entra en operación y mantenimiento. Cuando el código y los documentos de diseño son modificados, es esencial contar con la capacidad para conocer el conjunto completo de requisitos que pueden ser afectados por esas modificaciones.
Comentarios
Publicar un comentario