Capitulo 02 Captura de requisitos Pablo Gervás F. Informática, UCM, octubre 2004 Sobre trabajo de P.Mejía, I. Sommerville

Contenido Qué es la captura de requisitos Ingeniería de requisitos El proceso de captura Técnicas avanzadas

Problemas Los usuarios no saben lo que quieren. Un sistema tiene muchos usuarios y ninguno tiene una visión de conjunto. No saben cómo hacer más eficiente la operación en su conjunto No saben qué partes de su trabajo pueden transformarse en software. No saben detallar lo que saben de forma precisa.

Solución tradicional: analistas Labores –obtener una lista de requisitos de cada usuario –adquirir una visión de conjunto –componer una especificación completa, correcta y consistente Desventajas –listas de requisitos son difíciles de comprender y de hacer bien –difíciles de transformar en especificaciones de diseño e implementación

Objetivos generales Enumerar los requisitos candidatos Comprender el contexto del sistema Capturar requisitos funcionales Capturar requisitos no funcionales

Requisitos funcionales Definen lo que el sistema tiene que hacer, los servicios que debe proporcionar al usuario Describen la funcionalidad del sistema

Requisitos no funcionales Delimitan las condiciones en que el sistema presta servicios a los usuarios –Velocidad de respuesta –Ancho de banda requerido –Espacio en memoria o en disco –....

Segunda parte Qué es la captura de requisitos Ingeniería de requisitos El proceso de captura Técnicas avanzadas

Desafíos para la Ingeniería de requisitos –Al informatizar un determinado proceso el propio proceso puede sufrir cambios difíciles de predecir. – Usuarios diferentes tienen requisitos y prioridades diferentes. Hay una negociación de cambios en los requisitos. – Los usuarios finales del sistema y la organización que paga por el sistema tienen requisitos diferentes. – El prototipado es necesario para clarificar requisitos

Definición y especificación de requisitos Definición de Requisitos 1. El Software proporciona significado de representación y acceso a archivos externos creados por otras herramientas. Especificación de Requisitos 1.1 El usuario debe proporcionar facilidades para definir el tipo de archivos externos. 1.2 Cada tipo de archivo externo puede tener una herramienta asociada. La cual, será aplicada para el archivo. 1.3 Cada tipo de archivo externo será representado como un icono específico mostrado al usuario. 1.4 Las facilidades proporcionadas para la representación del icono en un tipo de archivo externo será definido por el usuario. 1.5 Cuando un usuario selecciona una representación de icono de un archivo externo, el efecto de la selección es aplicar las herramientas asociadas con el tipo de archivo ex- terno al archivo representado por la selección del icono.

Lectores de requisitos Gerencia de Cliente Usuarios Finales del Sistema Ingenieros de Clientes Gerencia de Contratistas Arquitectos del Sistema Definición de Requisitos Especificación de Usuarios Finales del Sistema Ingenieros de Cliente Arquitectos del Sistema Desarrolladores de Software Especificación de Software (Quizá) Ingenieros de Clientes Arquitectos del Sistema Desarrolladores de Software

El proceso de ingeniería de requisitos Estudio de Viabilidad Análisis de Requisitos Definición de Requisitos Especificación de Requisitos Informe de Viabilidad Modelos del Sistema Documento de Requisitos Definición de Requisitos Especificación de Requisitos

Documento de requisitos Especificación de la conducta externa del sistema. Especificar los límites de la implementación. Fácil de cambiar. Sirve como una herramienta de referencia para mantenimiento.

Validación de requisitos Demostración de que los Requisitos que definen el sistema son lo que el cliente realmente quiere. Los costos de errores en los Requisitos son altos, por lo cual, la validación es muy importante. –reparar un error de Requisito después del desarrollo puede resultar en un coste 100 veces mayor que reparar un error en la implementación. El Prototipado es una técnica importante de la validación de Requisitos.

Qué comprobar Validación. ¿Provee al sistema las funciones que mejor soporten las necesidades del cliente? Consistencia. ¿Existe cualquier conflicto en los Requisitos? Completo. ¿Están incluidas todas las funciones requeridas por el cliente? Realismo. ¿Pueden los Requisitos ser implementados con la tecnología y el presupuesto disponible?

Revisión de Requisitos Una revisión regular puede ayudar mientras la definición de Requisitos está siendo hecha. Tanto el cliente como el personal de contratistas deben estar involucrados en la revisión. La revisión debe ser formal (con los documentos completos) o informal. Una buena comunicación entre desarrolladores, clientes y usuarios puede resolver problemas en las primeras etapas.

Evolución de Requisitos Es esencial planear posibles cambios en los requisitos cuando el sistema sea desarrollado y utilizado. El documento de requisitos debe ser organizado, de tal forma que los cambios en los requisitos puedan ser hechos sin tener que re-escribir demasiado. Las referencias externas deben ser minimizadas y las secciones del documento deben ser tan modulares como sea posible.

Tercera parte Qué es la captura de requisitos Ingeniería de requisitos El proceso de captura Técnicas avanzadas

Qué se pretende definir objetos observables evaluar el flujo y contenido de la información definir y elaborar funciones del software entender el comportamiento del sistema establecer características del interfaz descubrir restricciones ocultas

Delimitar el alcance La funcionalidad y el rendimiento del sistema se deben acotar de manera comprensible y concreta (sin ambigüedades). Describir: –datos y control, –función –rendimiento –restricciones –interfaces –fiabilidad

Viabilidad Tecnología: hay tecnología? se domina? está dentro del estado del arte? Financiera: pueden asumir el coste la organización, el coste, el mercado? Tiempo: llegará al mercado antes que la competencia? Recursos: qué se va a necesitar? está disponible? Muy relacionado con la experiencia disponible en los proyectos del tipo que se pretenda desarrollar (si se han hecho muchos, es más fácil decidir sobre la viabilidad de una propuesta)

Citado en el Pressman "Quien hace una pregunta parece ignorante durante cinco minutos. Quien se la calla sigue siéndolo el resto de su vida. " Antiguo proverbio chino

Una situación en que los participantes... no saben qué decir se preocupan de que se les entienda mal piensan a dónde va a llevar tienen expectativas diferentes quieren que se acabe cuanto antes quieren que sea un éxito Una entrevista de obtención de requisitos ¿Una primera cita romántica? No.

Preguntas: sobre el contexto Quién solicita este trabajo Quién usará el producto Cuál es el beneficio económico de una solución satisfactoria Hay más fuentes para la solución que se busca

Preguntas: sobre el problema describir buenos resultados generados por una solución buena cuál es el problema al que nos enfrentamos en qué entorno (describir/mostrar) se va a utilizar restricciones específicas de rendimiento

Preguntas: sobre la reunión en sí es usted la persona adecuada para responder a estas preguntas son oficiales sus respuestas le parecen relevantes mis preguntas hago demasiadas preguntas hay alguien más que pueda aportar información hay algo más que debería preguntar

Limitaciones Las reuniones en generales dan resultados muy pobres. Se deben emplear sólo como primer paso, para luego ser sustituidos por reuniones que combinen resolución de problemas, negociación, y especificación.

Cuarta parte Qué es la captura de requisitos Ingeniería de requisitos El proceso de captura Técnicas avanzadas –FAST –QFD

Facilitated application specification techniques (FAST) Método específico para gestionar entrevistas diseñado para poner a clientes y desarrolladores a trabajar en equipo hay muchas versiones Referencia útil: JAD (Joint Application Development)

Una reunión –se celebra en sitio neutral –asisten clientes y desarrolladores –hay reglas claras para la preparación y la participación –hay un orden del día, suficientemente formal para que se cubra todo, suf. informal para que haya flexibilidad –hay un moderador (cliente o desarrollador) –hay un mecanismo de definición (pizarra, fichas,...) –el objetivo es identificar el problema, especificar requisitos básicos de la solución

Proceso fundamental –reunión previa con el cliente (alcance y descripción básica), –se redacta una petición de producto (1 o 2 páginas), –se convoca una reunión FAST, –se elige un moderador, –se reparte la petición de producto a todos los asistentes

Deberes para la reunión Cada asistente tiene que traer preparado a la reunión las siguientes listas: –objetos (forman parte del entorno del sistema, producidos por el sistema, utilizados por el sistema) –servicios –restricciones (coste, tamaño, reglas de negocio) –criterios de rendimiento Las listas no tienen que ser exhaustivas pero deben reflejar la visión que cada uno tiene del sistema

Primera fase de la reunión en la reunión se exponen las listas para un área concreta en este punto no se admiten críticas ni discusión se elabora una lista combinada cuando están las listas combinadas para todas las áreas, se acuerda una versión negociada de cada una

Segunda fase de la reunión se separan los asistentes por equipos cada uno se encarga de hacer una mini especificación de unas cuantas propuestas de la lista cada equipo presenta su mini especificación a todos los participantes en función de eso se rehacen las listas se asigna a alguien la tarea de redactar un documento de especificación

Quality Function Deployment Astilleros de Kobe, Mitsubishi Heavy Industries, años 70 Maximizar la satisfacción del cliente a base de priorizar los requisitos en función de la satisfacción que se espera que proporcionen: –normal: los que pide el cliente cuando describe lo que quiere, si están, el cliente está satisfecho –esperado: los que el cliente no menciona pero da por sentado que va a encontrar, si no están, habrá protestas –emocionantes: adiciones que no hacen falta pero que harán feliz al cliente

Direcciones interesantes Joint Application Design Quality Function Development Institute

Referencias Pressman, capítulos 10 y 11 Sommerville, capítulos 5 y 6