Requisitos

Requisitos de Software

Juan Bernardo Quintero

Agenda
•
•
•
•
•

Conceptos
Ingeniería de Requisitos
Tipos de Requisitos
Atributos de Calidad
Modelos de Calidad
–
–
–
–
–

Modelo de Mc Call
Modelo FURPS
Modelo ISO/IEC 9126
Modelo de Dromey
ISO/IEC 9126 adaptado para Arq. de Software

• Referencias

Agenda
•
•
•
•
•

Conceptos
Ingeniería de Requisitos
Tiposde Requisitos
Atributos de Calidad
Modelos de Calidad
–
–
–
–
–

Modelo de Mc Call
Modelo FURPS
Modelo ISO/IEC 9126
Modelo de Dromey
ISO/IEC 9126 adaptado para Arq. de Software

• Referencias

Contexto
¿Porqué fracasan los proyectos?

Requisitos incompletos: 13%
Cambios en requisitos: 9%
No implicación de usuarios: 12%

Expectativas no realistas: 10%
Producto nonecesario: 8%
TOTAL: 52%

Contexto
50-200X
Coste de la
corrección
50-200X

Fase en la que se
detecta el fallo
Requisitos

1X
1X

Arquitectura

Diseño detallado

Construcción

Requisitos

Arquitectura

Diseño detallado

construcción

Fase en la que se soluciona el fallo

Producción

¿ Porque Gestionar Requisitos?
•
•

El coste de corrección de defectos de
requisitoses del orden de 100 a 200
veces inferior en las etapas iniciales.
La corrección de requisitos defectuosos
implica mucho retrabajo sobre otros
productos del proyecto.

¿Que es un Requisitos?
• IEEE Standard Glossary of Software Engineering
Terminology (1990)
– Una condición o capacidad necesaria por un usuario para
solucionar un problema o lograr un objetivo.
– Una condición ocapacidad que debe cumplir o poseer un
sistema o componente de un sistema para satisfacer un
contrato, estándar, especificación u otro documento
formalmente impuesto.
– Una representación documentada de una condición o
capacidad como en 1 o 2.

• Una especificación de qué se debería implementar.
Son descripciones de cómo se debe comportar el
sistema, o de un atributo o propiedad del sistema.Puede ser una restricción en el proceso de desarrollo
de un sistema (Somerville y Sawler,(1997)).

¿Que NO es un Requisitos?
• Detalles de Diseño o implementación o
pruebas.
• Información relativa a la Planificación
del Proyecto.
• Necesidades del Proyecto.
• Estos elementos se suelen llamar
“Especificaciones suplementarias”

Características
Características de las buenas descripcionesde requisitos

Requisitos

Especificación

Posibles

Completa

Necesarios

Correcta

Priorizados

Consistente

Concretos

Modificable

Verificables

Trazable

Defectos
Los defectos comunes en los requisitos y sus consecuencias.

Implicación insuficiente
del cliente

Problemas en la validación
del producto obtenido

Requisitos crecientes
y cambiantesDegradación de la estructura
y arquitectura del producto

Requisitos ambiguos

Pérdida de tiempo en
re-codificación

Requisitos
innecesarios

Trabajo innecesario

Requisitos mínimos
(insuficientes)

Problemas en la validación
del producto obtenido

Requisitos mínimos
(insuficientes)

Error en la estimación
y planificación

Omisión de las necesidades
de grupos de usuariosUsuarios insatisfechos

Técnicas
Técnicas de obtención de requisitos

ENTREVISTAS

Reuniones JAD, cuestionarios
reuniones de grupo
entrevista, lluvia de ideas

ESCENARIOS

Casos de uso, tarjetas CRC
diagramas de flujo, escenarios

PROTOTIPOS

Prototipos rápidos
prototipos evolutivos

TÉCNICAS

OBSERVACIÓN

Introspección
análisis de protocolo
documentación, otros sistemasAgenda
•
•
•
•
•

Conceptos
Ingeniería de Requisitos
Tipos de Requisitos
Atributos de Calidad
Modelos de Calidad
–
–
–
–
–

Modelo de Mc Call
Modelo FURPS
Modelo ISO/IEC 9126
Modelo de Dromey
ISO/IEC 9126 adaptado para Arq. de Software

• Referencias

Ingeniería de Requisitos

Desarrollo de Requisitos
• Proceso de Extraer, analizar, especificar y verificar
los...