levantamiento de requerimientos funcionales y no funcionales

REQUERIMIENTOS NO FUNCIONALES

Con frecuencia, los requerimientos no funcionales son ignorados o subestimados en la fase de análisis de requerimientos. El error, termina identificándose en la fase de implementación cuando remediarlos implica más trabajo y costo, pudiendo ocasionar que no sean adoptados por los usuarios y clientes.

FUNCIONALES

· Correcta

La ERS es correcta si y sólo si todo requisito que figura en ella refleja alguna necesidad real. La corrección de la ERS implica que el sistema implementado será el sistema deseado.

· No ambigua

Un documento es no ambiguo si y solo si cada requisito descrito tiene una única
interpretación. Cada característica del producto final debe ser descrita utilizando un
término único y, en caso de que se utilicen términos similares en distintos contextos, se
deben indicar claramente las diferencias entre ellos. Incluso se puede incluir un glosario
en el que indicar cada significado específicamente.

Completa

Incluye todos los requisitos significativos del software (relacionados con la funcionalidad, ejecución, diseño, atributos de calidad o interfaces externas).

· Existe una definición de respuestas a todas las posibles entradas, tanto válidas como inválidas, en todas las posibles situaciones.

· Cumple con el estándar utilizado. Si hay alguna parte del estándar que no se utiliza, se debe razonar suficientemente el porqué no se ha utilizado dicho apartado.

· Aparecen etiquetadas todas las figuras, tablas, diagramas, etc, así como definidos todos los términos y unidades de medida empleados.

Verificable

Un requisito se dice que es verificable si existe algún proceso no excesivamente costoso
por el cual una persona o una máquina pueda chequear que el software satisface dicho
requerimiento.

No verificables:

El producto debería funcionar bien El producto debería tener una buena interfaz de usuario

Verificable

La salida se suministra dentro de los 20 segundos siguientes al evento E el 60% de las veces, y en los 30 segundos siguientes en el 100%

Consistente

Una ERS es consistente si y sólo si ningún conjunto de requisitos descritos en ella son contradictorios o entran en conflicto. Se pueden dar tres casos:

Requisitos que describen el mismo objeto real utilizando distintos términos.

· Las características especificadas de objetos reales. Un requisito establece que todas las luces son verdes y otro que son azules.

· Conflicto lógico o temporal entre dos acciones determinadas. Se llega a un punto en el que dos acciones serían perfectamente válidas (¿sumar o multiplicar?)

Clasificada

No todos los requisitos son igual de importantes. Los requisitos pueden clasificarse por diversos criterios:

· Importancia: Pueden ser esenciales, condicionales u opcionales.

· Estabilidad: Cambios que pueden afectar al requisito.

Modificable

Una ERS es modificable si cualquier cambio puede realizarse de manera fácil, completa
y consistente. Para ello, es deseable tener una organización coherente y fácil de usar en
la que aparezca el índice o una tabla de contenidos fácilmente accesible

También es deseable evitar la redundancia, es decir que no aparezca un mismo
requisito en más de un lugar de la ERS. No es un error, pero si se tiene que modificar
alguna cosa será mucho más cómodo si no tenemos que buscar el mismo requisito en
varios lugares.

Explorable

Una ERS es explorable si el origen de cada requerimiento es claro tanto hacia atrás
(origen que puede ser un documento, una persona etc.) como hacia delante
(componentes del sistema que realizan dicho requisito).

· Utilizable durante las tareas de mantenimiento y uso

En ocasiones, el equipo de desarrollo supone unos conocimientos que el personal
que se encargue del mantenimiento no tiene por qué tener. Por esta razón es necesaria
una correcta documentación de las funciones, ya que si no se conoce en detalle su
origen, difícilmente podrán ser modificadas