Procesos y técnicas de elicitación de requisitos
Requisitos
Requisito condición o capacidad que debe cumplir un sistema o componente de un sistema para satisfacer un contrato o documento. *De software define las funciones, capacidades o atributos de cualquier sistema de software. *Puede variar desde unos estatutos abstractos en alto nivel de un servicio o unas restricciones del sistema hasta una especificación funcional matemática detallada. *Pueden servir como una función dual – Puede ser la base para: la declaración del contrato, deber estar abierto a interpretación – El contrato en sí, debe ser definido en detalle – Ambas declaraciones serán llamadas Requerimientos
Podría describir
Podría describir: Facilidad a nivel usuario: el procesador de palabras debe incluir un verificador de ortografía y un comando de corrección – Propiedad muy general del sistema: el sistema debe asegurar que la información personal nunca se haga disponible sin autorización – Restricción específica del sistema: el sensor activado 10 veces por segundo – Restricción para el desarrollo del sistema: sistema desarrollado usando Ada – Cómo llevar a cabo algún cálculo: la nota final debe ser calculada sumando las notas del examen, proyecto y cursada del estudiante basado en la siguiente fórmula nota final = nota_exam + 2*nota_proy + 2/3*nota_cursada
Tipos
Tipos: – Funcionales (serv func) no funcionales (lim en desarrollo) – Requerimientos de dominio (obtienen del dominio de la aplicación)
Procesos
Procesos: Entender el problema: definir. Describir el problema: especificación. Verificar la naturaleza del problema: validación. Ponerse de acuerdo en los límites del problema: negociación (iterativo)
Estudio de factibilidad (descripción sistema cómo utilizar), análisis de requerimientos (qué quieren), definición de requerimientos (para cliente), especificación de requerimientos (detallada)
Analista
Analista: Definir objetivos del proyecto y beneficios al negocio. Identificar el problema a resolver y obtener los requisitos. Identificar a los involucrados en el desarrollo del proyecto así como a las clases de clientes y usuarios. Identificar el ambiente del dominio a desarrollar y estar preparado para desarrollar el sistema requerido. Administrar los requisitos utilizando un proceso y un plan de requerimientos. Modelar los requisitos. Realizar control de cambios en los requisitos.
Habilidades
Habilidades: Capacidad de comunicación, análisis y observación, organización. Analizar los riesgos del desarrollo del software.
Conclusiones
Conclusiones: Es muy difícil formular una especificación de requisitos completa y consistente. La definición de requerimientos, la especificación de requisitos y la especificación de Software son una manera de especificar el Software para diferentes tipos de lectores. El Documento de Requerimientos es una descripción para clientes y desarrolladores.
Elicitación
Elicitación: Descubrir, tornar explícito, obtener el máximo de información para el conocimiento del objeto en cuestión, en este caso los requisitos.
Dificultades: Información esparcida en diversas fuentes con posibilidad de conflictos entre ellas. Conocimiento tácito. Observabilidad limitada (cambiar el problema, cliente ocupado). Desviación (persona no libre/dice todo).
Actividades: Identificación de fuentes de información (documento, libros, sistemas software), Recolectar la información (diferentes técnicas para obtener información), comunicación (resultados determinan manera, ayudar o no entender, etapa documentación y modelización)
Técnicas: Tradicionales, Técnicas de elicitación grupal, Prototipación, Técnicas guiadas por modelos, Técnicas cognitivas, Enfoque antropológico, Técnicas sociales, Ingeniería reversa, Reutilización
Tradicionales: Lectura de Información, Cuestionario, Entrevistas
Técnicas de elicitación grupal: Reuniones
Técnicas de Recolección: Prototipación, técnicas guiadas por modelos
Técnicas Cognitivas: Análisis de protocolo, card sorting
Técnicas de Recolección: Enfoque Antropológico, Técnicas Sociales, Ingeniería Inversa, Reuso
¿Qué técnicas usar? Depende de la situación, clientes, recursos. Analizar contexto y respetar limitaciones, Integración
Procesos
Tradicionales Lectura de información Abarca la lectura de todos los documentos disponibles en la organización, intenta identificar estructuras, hechos y vocabulario similares. Tipo de lectura: diagramas organizacionales, standards, modelos de procesos o manuales de sistemas existentes. Fácil de obtener si hay documentación, permite manejar gran volumen. Provee información muy dispersa. Gran trabajo para procesarlo. Cuestionario o Secuencia de preguntas que exige un conocimiento mínimo. o Facilitan la estructuración de preguntas y un tratamiento estadístico. o Limita el tipo de respuestas o Tienen poca participación e interacción. Entrevistas *Estructuradas: qué preguntar, cómo y a quien, orden. *No estructurada: ofrece más flexibilidad, informal *Favorecen el contacto directo y la validación. Problema del conocimiento tácito, desviación. Problema de diferencias culturales desarrolladores vs. Cliente, usuario. *Tips: comienzo «inocuo», permiso para grabar, inicio pregunta fáciles, preguntas abiertas hacia el final.
Técnicas de elicitación grupales. Reuniones Extensiones de entrevista. Muy activas. De corta duración e intensas con un determinado foco. Favorecen la aparición de múltiples opiniones, creación, feedback y consenso colectivo. Puede haber dispersión, incomodidad en el grupo, pensamiento generado a nivel de grupo. Altos costos.
Técnicas de recolección. Prototipación se puede usar cuando hay un alto grado de incertidumbre en cuanto a los requisitos o cuando se necesitan un temprano feedback de los stakeholders. – combinar con otras técnicas, ejemplo usar un prototipo para provocar una discusión y feedback en una técnica de elicitación grupal o ser la base para un cuestionario o análisis de protocolo. Técnicas guiadas por modelos – proveen un modelo específico del tipo de información que se va a recolectar y usan ese modelo para dirigir la actividad de elicitación. Ej. métodos orientados a objetivos como KAOS, o métodos basados en escenarios como CREWS.
Técnicas cognitivas. Análisis de protocolo – se analiza al experto mientras este «describe» cómo hace su tarea. Se intenta captar la racionalización utilizada en la ejecución de una tarea. – Ventajas: obtiene una directa verbalización de las tareas cognitivas. Embebida en el contexto de trabajo, bueno para revelar problemas de interacción con sistemas existentes. – Desventajas: se enfoca solo en la performance, desconociendo aspectos sociales, se basa en lo que dice y no lo que hace. Card Sorting – se pide a expertos que ordenen cartas (con descripciones de objetos de un dominio) y expliquen el porqué de ese orden – útil para la clasificación del conocimiento pero presupone un conocimiento de las entidades de un dominio.
Técnicas de recolección. Observación – El ingeniero se convierte en espectador del proceso. – Ventajas: revela detalles obviados por otras técnicas, fácil de ejecutar – Desventajas: depende de la visión del espectador. Gran consumo de tiempo. La «rica descripción» que se obtiene es difícil de procesar. Enfoque antropológico (Técnicas de etnografía) – se integra con el medio ambiente, el analista se convierte en el cliente. – Ventajas: visión de dentro para afuera, muy contextualizada – Desventajas: consume mucho tiempo, poca sistematización. Técnicas sociales – enfocándose en los aspectos sociales y no en la tecnología, demanda muchos recursos y tiempo. – Buena en el largo plazo, – Ej. análisis de conversación que identifica patrones en las conversaciones e interacciones. Ingeniería inversa – Requiere que haya un sistema existente con documentación (o código) disponible. – Desventajas: no refleja la actualización de la información, información muy detallada (a un bajo nivel) Reuso – Debe haber componentes reutilizables disponibles, se debe definir lo que se va a reutilizar, necesita de mecanismos de recuperación. – Análisis de dominio – Si bien favorece la calidad y la productividad, no siempre es fácil de lograr en la realidad.