Especificaci n y An lisis de Requerimientos

Especificación y Análisis de Requerimientos

Especificación y análisis de
requerimientos

Qué es un Requerimiento?
• Es un aspecto del contenido o comportamiento
del producto, requerido o deseado por el cliente.
– Requerimientos funcionales. (Debe hacer)
– Requerimientos no-funcionales.(Debe tener)

• Una restricción es un requerimiento que afecta a
todo el producto.

Qué es un Concepto?Ciclo de vida “V”
Why?

Verificación y Validación

Concepto

What?

Pruebas integ.

Análisis

How?

Pruebas unit.

Diseño
Do!

Pruebas acept.

Código

Concepto : conocimiento general del proceso del negocio.
entrega: diag. de contexto, diag. de Entidad-Relación, Casos de Uso

Modelo de Procesos

Fases de la especificación y análisis de
requerimientos
– Blastoff (kick off)
– Recolección derequerimientos
– Prototipos
– Verificación y validación
– Revisiones
– Post-Mortem

Blastof
Preparación para el inicio del proyecto

• Reunión entre los principales desarrolladores,
clientes y usuarios
• Del Blastoff se obtienen:
– El contexto
– Propósito del proyecto
– Lista de principales riesgos
– Estimación inicial del esfuerzo
– Decisión de seguir adelante o no
– Identificación clara de losinteresados
– Compromiso con el proyecto
– Formación de equipos

Blastof (continuación)
• Determinar el propósito del producto:
1. Escribir en una frase el objetivo/propósito del
producto
2. Cuál es la ventaja/solución que ofrece?
3. Definir cómo medir el éxito.
Además:
4. ¿Es realista / factible?
5. ¿Lo desean todos los interesados (stakeholder)?

Propósito del producto:
• Todos los demás requerimientosson
verificados/validados en torno a su contribución al
propósito del producto.
• Qué ventaja o solución queremos que ofrezca el
producto?
• El producto tiene un criterio de validación
medible/verificable.
• La satisfacción es un factor en el valor del
producto.

Identificación de las
personas interesadas:
•
•
•
•
•

Patrocinadores
Clientes
Usuarios
Especialistas
Ingeniero de requerimientosDeterminar el alcance:
• Dominios y Contexto
– Los dominios de interés son los que
influyen en el sistema que se esta
por estudiar
– El dominio de la aplicación simulará
hasta cierto punto a los dominios
de interés.

Diagrama de contexto:
• Por cada sistema adyacente se dibujan interfaces para
identificar su relevancia en el estudio.
• Los sistemas adyacentes se derivan de los dominios de
interésque interactúan con el dominio de aplicación.
• Las interacciones deben ser comprensibles.
(graficas)

(cont.)
• El contexto incluye todo lo que se debe saber para construir
el sistema.
• El producto es la parte del contexto sobre la cual tenemos
control para adaptar / cambiar
• Los sistemas adyacentes son las fuentes de conocimiento
sobre los dominios de información
• Los sistemas adyacentestienen conexiones con el contexto.
Es importante entenderlos para entender las característtcas
de las conexiones.
• El contexto contiene políticas de procesamiento y datos
almacenados

Estimado inicial de costo/esfuerzo
• Primera medición del tamaño del
sistema:
– Número de sistemas adyacentes
– de dominios,
– entradas y
– salidas.

Primer análisis de riesgos
• Identificar los riesgos más probablespara el proyecto
• Estimar el costo / impacto si el riesgo se vuelve un
problema
• Identificar las señales que indiquen que el riesgo se
está volviendo un problema
• La intención es balancear los beneficios con sus
riesgos
• Un riesgo no forzosamente es algo malo.

Evaluación y toma de decisión de seguir
adelante
• En base a lo anterior se analiza si:
– ¿Los objetivos son viables y medibles?
–¿Son factibles?
– ¿Son los riesgos demasiado altos?
– ¿Es el costo de los objetivos razonable?
– ¿Las personas implicadas están de acuerdo y
dispuestas?
– ¿Se justifica el proyecto?
¿Hay razones para cancelarlo?

Recolección de Requerimientos
– En esta etapa se deben
• Extraer los requerimientos de los
usuarios
• Descubrir el mayor número posible de
requerimientos
• Utilizar diferentes métodos...