Identificación de Requerimientos.

Introducción
 Es un trabajo que se ejecuta una sola vez.

 Tiene un alcance, plasmado en objetivos y

actividades.

 Tiene recursos asignados.

 Tiene un inicio y un final (Tiempo asignado).

 Produce resultados únicos.

 Alcance
 Recursos (costo del
esfuerzo, principalmente).
 Tiempo.

 Cada parámetro es función

de los otros dos.
 Mover un parámetro
implica cambios a los otros
(por lo menos a uno).
 El principal objetivo de la
dirección del proyecto es
planearlos y controlarlos.
 P: ¿En base a qué se establecen los alcances
de un proyecto?

 R: En base a los requerimientos.

 No es posible realizar estimaciones realistas.
 No es factible emplear coherentemente
herramientas de planeación.
 No se pueden realizar revisiones periódicas
del progreso en base a especificaciones.
 La arquitectura, el diseño y el desarrollo del
software carecerán de una base firme.
 Las pruebas estarán basadas en supuestos y
no en lo que el usuario y otros interesados
requieren.
 No es posible Realizar un control de
configuraciones adecuado.
 No es posible controlar el crecimiento de los
requerimientos.
 Empleo de métricas.
 Empleo de técnicas y herramientas de
estimación.
 Informes formales y regulares de avances.
 Empleo de arquitectura de software
adecuada y datos.
 Empleo de métodos formales de desarrollo.
 Revisiones formales de diseño.
 Métodos formales de pruebas.
 Empleo de herramientas de diseño.
 Empleo de control de versiones y
configuraciones.
 Administración de los requerimientos y
control del crecimiento del proyecto.
¿Por dónde Empezar?
 Identificar usuarios clave, expertos del área y
directivos que auspician el proyecto (los
patrocinadores, o sponsors).
 Obtener organigrama del área.
 Planear entrevistas iniciales.
 Establecer un centro de operaciones.
 Un objetivo fundamental: alinear el proyecto
con las estrategias y metas de los directivos.
 Detectar características y condiciones que
deben cumplir el producto y el proyecto.
 La subestimación o menoscabo de su
importancia es uno de los errores fatales más
comunes.
 Alineación de perspectivas.
 Exploración de antecedentes.
Técnicas de recolección e identificación de Requerimientos.
 Preparar la entreviste
de antemano.
 Preparación != Rigidez
o falta de espontaneidad.
Si es con un directivo de alto nivel:
 Identificar visión panorámica.
 Solicitar que nos ayude a detectar usuarios
clave.
 Identificar si se han investigado las mejores
prácticas del ramo, o las que se llevan a cabo en
empresas similares.
 Facilita la obtención y validación de
requerimientos.
 Presentan una parte del sistema.
 Excelente vehículo de descubrimiento.
 Ayuda a obtener retroalimentación.
 Reduce ambigüedades.
 Permite al cliente/usuario a clarificar ideas.
 ¡Cuidado! Los prototipos tienden a crear la ilusión
de que el sistema está casi, casi listo.
Joint Application Development.
Diseño de aplicación conjunta.

 Son idóneas para balancear objetivos y

requisitos.
 Son indispensables cuando están
involucrados varios departamentos.
 Se debe, ante todo Escuchar.
Estos no son requerimientos:

 Análisis, diseño, diagramas, herramientas

CASE …
 Interfaz gráfica, OO.
 Ebusines, ancho de banda, ERP

… Sino soluciones técnicas.

Estos sí son requerimientos.

 “Necesitamos reducir el tiempo que nos toma

elaborar el informe semestral”
 “Queremos reducir los errores en los estados
de cuenta de los clientes”
 “Necesitamos saber a que clientes les
estamos vendiendo suministros para equipo
de computo”
 Los requerimientos son el insumo principal en
el desarrollo de software.

 Delimitan el alcance real del proyecto de

software.

 El subestimarlos en un proyecto, por lo

general nos hace entrar en crisis.
Contacto:

David Ramírez Ledesma.

davo.rmz@gmail.com

@davo_man