“Especificación de Requerimientos” Objetivo: revisar criterios para determinar aspectos claves en la definición de requerimientos por parte del Cliente y/o Usuario (y las posteriores especificaciones y otras etapas asociadas) Luis F. Hevia R.

Sobre los Clientes Puede suceder que: No sepan lo que quieren No se comprometan por escrito La comunicación sea lenta No participen o no entiendan el proceso No estén preparados técnicamente No conozcan los riesgos Clientes nuevos!!!

Participación del cliente Debe recopilar requerimientos reales Lo más frecuente es no detectarlos Los Clientes los entienden en forma amplia, los desarrolladores en forma reducida Mayor productividad si el Cliente participa en forma amplia, NO total La importancia de las Interfaces Participación de diversos grupos del Cliente

Manejo de Expectativas del Cliente Necesidad de comprender las expectativas Causa de fracaso Impacto en planificación, costo o funcionalidad Creencia de que es obvio o imposible Caso de los cambios y la reacción del cliente Educando al cliente Construyendo realidades

Herramientas y consejos Aunque sean dibujos... Determinando alcances Clarificando los Objetivos Cuidado con las omisiones Meticulosidad ¿innecesaria? Filtrar requerimientos: claridad en costos (“lo pequeño es hermoso”) Alerta: los cambios sólo si son imprescindibles y negociados

REQUERIMIENTOS FUNCIONALES DISTINTIVOS PROPIOS. Ejemplos: Para una Cárcel: identificación de visitas y a quien visita; llevar un registro diario; verificar la visita con la lista de personas que pueden visitar al interno. Para un Banco de Sangre: cálculos de dosis, hacer un seguimiento de pacientes y análisis de tratamientos; estimaciones de sobrevida de pacientes. Para una Escuela de Conducir: generar una interfaz tipo visión de un conductor en un auto; reproducir situaciones con vídeo para situaciones de transito; Detectar errores al conducir comparando con situación ideal; ingresar en forma pesonalizada según niveles de complejidad.

REQUERIMIENTOS FUNCIONALES GENERICOS ListadoS e informes (debe especificar cuántos y de qué tipo) Estadísticas (debe especificar cuántas y de qué tipo) Gráficos (debe especificar cuántos y de qué tipo) Control de acceso (y/o o vistas) personalizado a usuarios Mantenedor de una BD (insertar, eliminar y actualizar)

Otros Aspectos Relevantes No confundir Requerimientos con objetivos o su contexto. Ej: dedicado sólo a leyes laborales sindicales; atender solicitudes de trabajo, etc. Requerimientos NO Funcionales Genéricos. Ej: fácil instalación y uso, Interactivo, bajo tiempo de respuesta, navegable, aplicación amigable, etc. Especificación plataforma de HW y SW general exigido. Ej: en Linux, BD Oracle, etc. Deben venir firmados por el Cliente con los suficientes detalles que eviten conflictos posteriores

Especificaciones Esfuerzo necesario para producción Obsolescencia por cambios de requerimientos Diseño muy (in)-flexible Cuidado con la Entretención del desarrollador Objetivo: Planificación v/s generar el mejor SW posible en el tiempo disponible Traducir en Especificaciones a producción

Producto: Especificación de Requerimientos Se requiere la participación del cliente. Consume un % del tiempo total del proyecto (aprox. 20%). Identificar los problemas o necesidades de Negocios en un alto % (90%) Deben ser analizados en un 100%: las metas de la organización, objetivos y factores de éxito; los Procesos de Negocios y flujos de información: los Requerimientos en términos de Procesos y principios de negocios, estructura organizacional y arquitectura tecnológica; los beneficios de la Solución e impacto en la organización, recursos humanos y ambiente tecnológico En esta etapa no se debe pensar en posibles soluciones, sino solo en el problema, ie se debe describir el problema en forma de Requerimientos Atributos de Calidad: Claridad, Mantenimiento, Flexibilidad, Corrección, Confiabilidad, Facilidad de uso, Integridad, Eficiencia Encargado (s) revisión final: Cliente y Jefe de Proyectos

Producto: Análisis Requiere la participación del cliente y del Analista de Negocios No se debe consumir más de un % (30) del tiempo total del proyecto. Se deben identificar las soluciones que satisfagan la Especificación de Requerimientos, en un 100% Se debe documentar la Solución Propuesta en un 100%. Se debe preparar el Plan inicial del Proyecto en un 70% del total y de QA en un 80%, basado en la Solución Propuesta. Atributos de Calidad: Completitud, Claridad, Mantenimiento, Flexibilidad, Corrección, Confiabilidad, Facilidad de uso, Integridad, Eficiencia Encargado (s) revisión final: Cliente y el Jefe de Proyectos

Producto: Diseño No se debe consumir más de un % del tiempo total del Proyecto. Se requiere de la participación del Arquitecto de Sistema, del Diseñador, Jefe de Proyectos, y del Analista de Negocios En un alto % (90) se debe: Definir la Funcionalidad y Solución (desde el punto de vista del Diseño) que satisfacen todos los Requerimientos acordados suficientemente flexible para soportar en el futuro nuevas funcionalidades . Planificar cómo se va a implementar y aceptar la Solución Propuesta Planificar el soporte de la Solución Propuesta Atributos de Calidad: Claridad, Completitud, Mantenimiento, Flexibilidad, Corrección, Confiabilidad, Facilidad de uso, Integridad, Eficiencia Encargado (s) revisión final: Arquitecto de Sistema, Jefe de Proyectos, y el Cliente