Categories: All - documentación - requerimientos - funcionales

by fabricio coime 2 years ago

140

levantamiento de requerimientos funcionales y no funcionales

En el proceso de desarrollo de software, es crucial abordar tanto los requerimientos funcionales como los no funcionales desde las fases iniciales para evitar problemas en etapas posteriores.

levantamiento de requerimientos funcionales y no funcionales

levantamiento de requerimientos funcionales y no funcionales

You will have to choose between two options.

FUNCIONALES

· 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
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).
Modificable
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.
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
Clasificada
Discover a new planetDiscover a new animal
No todos los requisitos son igual de importantes. Los requisitos pueden clasificarse por diversos criterios:

· Estabilidad: Cambios que pueden afectar al requisito.

· Importancia: Pueden ser esenciales, condicionales u opcionales.

Consistente
Live in the counstrysideLive in a big town
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:

· 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?)

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

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

Verificable
Stay home everydayGo outside everyday
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.

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%

No verificables:

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

Completa
Read a bookWatch a movie
· Aparecen etiquetadas todas las figuras, tablas, diagramas, etc, así como definidos todos los términos y unidades de medida empleados.
· 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.
· Existe una definición de respuestas a todas las posibles entradas, tanto válidas como inválidas, en todas las posibles situaciones.
Incluye todos los requisitos significativos del software (relacionados con la funcionalidad, ejecución, diseño, atributos de calidad o interfaces externas).
· No ambigua
Have a dogHave a cat
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.
· Correcta
Live in a houseLive in an apartment
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.

REQUERIMIENTOS NO FUNCIONALES

Fly for one dayBe invisible for one day
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.