Ing De Software

INGENIERÍA DE SOFTWARE II
Requerimientos

Requerimientos
Solicitud Definición

2

Especificación

Análisis

Requerimientos
Características
• • • • • • • • • • • • Necesario: Su omisión provoca una deficiencia. Conciso: Fácil de leer y entender Completo: No necesita ampliarse Consistente: No contradictorio con otro No ambiguo: Tiene una sola implementación Verificable: Puedetestearse a través de inspecciones, pruebas, etc. No son obvios Provienen de muchas fuentes Están interrelacionados Pueden ser muchos Pueden cambiar a lo largo del desarrollo Son particulares para cada proyecto

Dificultades para definir los requerimientos

Participantes
• Los clientes, Usuarios, gerentes de negocio, supervisores de contrato, analistas, diseñadores, verificadores

Defectos enlos requerimientos
Estimación
• No es posible estimar los costos y recursos necesarios para desarrollar algo que no se conoce.

Planificación
• No se puede confiar en la planificación para el desarrollo de algo que no se sabe bien como es.

Diseño
• Los errores en requisitos, las modificaciones frecuentes, las deficiencias en restricciones o futuras evoluciones, producen arquitecturas quemás tarde se confirmarán como erróneas y serán modificadas.
REQUISITOS Estimación Planificación Diseño Construcción V&V

Defectos en los requerimientos
Construcción
• Las deficiencias en los requisitos obligan a programar en ciclos de prueba y error que derrochan horas y paciencia de programación sobre patrones de “recodificación continua” y “programación heroica”.

Validación y verificación• Terminado el desarrollo del sistema, si las especificaciones tienen errores grandes o no están reflejadas en una especificación de requisitos, no será posible validar el producto con el cliente.

REQUISITOS Estimación Planificación Diseño Construcción V&V

Buenos requerimientos
Acuerdo entre desarrolladores, clientes y usuarios sobre el trabajo que debe realizarse.
• Unos requisitos bienelaborados y validados con el cliente evitan descubrir al terminar el proyecto que el sistema no era lo que se pedía.

Acuerdo entre desarrolladores, clientes y usuarios sobre los criterios que se emplearán para su validación.
• Resulta muy difícil demostrar al cliente que el producto desarrollado hace lo que el pidió si su petición no está documentada y validada por él.

Base objetiva parala estimación de recursos (costo, personal en número y competencias, equipos y tiempo)
• Si los requisitos no comprenden necesidades reales, las estimaciones no dejan de ser meras apuestas. Las estimaciones en el fondo son cálculos de probabilidad que siempre implican un margen de error; por esta razón disponer de la mayor información posible reduce el error.

Buenos requerimientos
Concreciónde los atributos de calidad (ergonomía, mantenibilidad, etc.)
• Más allá de funcionalidades precisas, los requisitos recogen atributos de calidad necesarios que en ocasiones son desconocidos por los desarrolladores, produciendo finalmente sistemas sobredimensionados o con serias deficiencias de rendimiento.

Eficiencia en el consumo de recursos: reducción de la recodificación, reducción deomisiones y malentendidos.
• Tener un conocimiento preciso de lo que hay que hacer evita la prueba y error, repetición de partes ya desarrolladas, etc.

Tipos de Requerimientos
Requerimiento Funcionales
• Definen el comportamiento del sistema. • Describen las tareas que el sistema debe realizar. • Al definir un requisito funcional es importante mantener el equilibrio entre la excesivageneralidad, insuficiencia de detalle o ambigüedad, y el exceso de detalle con precisiones o descripciones innecesarias o redundantes.

Requerimiento No Funcionales
• Definen aspectos, que sin ser funcionalidades, (tareas que el sistema debe realizar) resultan deseables desde el punto de vista del usuario. Generalmente comprenden atributos de calidad: • Tiempos de respuesta. • Características de...