Resumen Final - Gestión de Requerimientos - Sistemas 2

Gestión de Requerimientos

El proceso de Software

Es un conjunto estructurado de actividades requeridas para desarrollar un sistema de software:

• Especificación
• Diseño
• Validación
• Evolución

Las actividades varían de acuerdo al tipo de sistema.

Ingeniería de requerimientos

Es el proceso de establecer lo que el cliente necesita del sistema y los límites bajo los cuales opera y se desarrolla.

Requerimiento

Es un conjunto de necesidades de alto nivel de un servicio o sistema.

Pueden ser:

• Funcionales: Describen servicio o funciones.
• No funcionales: Son un límite en el sistema o proceso de desarrollo.
• De dominio: Tiene que ver con aspectos legales y/o normas de la organización.

Pueden servir para:

• Ser la base de un contrato, por lo que debe estar abierto a interpretaciones.
• Ser la base del contrato en si, por lo que debe estar bien detallado.

Definición de requerimientos

Una declaración en lenguaje natural, incluye los diagramas de servicios del sistema y sus límites operacionales. Debe ser comprensible para el cliente/usuario.

Especificación de requerimiento

Documento estructurado con la descripción o detalle de los servicios del sistema.
Se debe escribir como un contrato entre el cliente y el contratista.

Especificación de software

Descripción detallada de software que puede servir como base de diseño o implementación. La usan los desarrolladores.

Características de la especificación de requerimientos

Mediante los casos de uso se muestran cuatro niveles de descripción:

• División del trabajo: Casos de uso que describen los procesos de trabajo de los usuarios. Define las fronteras entre usuarios y el sistema.
• Funciones del sistema específicas de la aplicación.
• Funciones del sistema específicas del trabajo (funciones de apoyo, seguridad, etc)
• Diálogo: Casos de uso que describen las interacciones entre usuarios y la GUI.

La validación de requerimientos es continua para asegurarse que la especificación es:

• Correcta: Debe representar la visión que el cliente tiene del sistema.
• Completa: Describe todos los escenarios posibles, incluidos los excepcionales.
• Consistente: No se contradice a sí misma.
• No ambigua: No se pueden tener diferentes interpretaciones de lo allí especificado.
• Realista: El sistema se debe implementar con las restricciones documentadas.
• Verificable: Una vez que se construye el sistema se pueden diseñar pruebas para demostrar que se cubren los requerimientos.
• Rastreable: Se debe organizar de modo que cada función se pueda rastrear hasta su conjunto de requerimientos.

Requisitos no funcionales

Son aspectos del sistema que no afectan el comportamiento funcional del sistema. Pueden ser:

• GUI
• Documentación
• Consideraciones de Hardware
• Cuestiones de calidad, etc.

Validación de requerimientos

Pruebas de utilidad:

• Examinan la comprensión que tiene el usuario de los casos de uso.
• Localizan problemas en la especificación
• Etc.

Documento de Análisis de Requerimientos (DAR)

• En él se documentan los resultados de la actividad de obtención de requerimientos y análisis.
• Describe todo el sistema desde el punto de vista de los requerimientos funcionales y no funcionales.
• Debe escribirse cuando el modelo de casos de uso sea estable.