Cómo hacer una toma de requisitos

Dilbert y sus problemas con los requisitos

Hoy vamos a volver a las bases de la ingeniería del software, e intentaremos aclarar algunos conceptos.

Para la toma de requisitos pasaremos habitualmente por 3 fases:

• Obtención de los requisitos candidatos. Para ello, pasaremos por las inevitables entrevistas a usuarios potenciales, análisis de mercado, realizando prototipos, etc.
• Especificar los requisitos, lo cual pasa inevitablemente, por escribirlos y documentarlos.
• Analizar los requisitos, estableciendo un profundo estudio de los requisitos, de forma que se dividan en sus más pequeños componentes.

Para la toma de requisitos, Steve McConnell en su Software Project Survival Guide propone un proceso más o menos secuencial de 9 pasos:

1. Identificación de usuarios finales clave.
2. Entrevista a dichos usuarios finales.
3. Construcción de un prototipo basado en los resultados de las entrevistas. Es importante que el prototipo sea a la vez simple e interactivo.
4. Presentación del prototipo a los usuarios finales, solicitando feedback.
5. Desarrollar una guía de estilo que refleje el diseño/interfaz del prototipo.
6. Completar y extender el prototipo hasta que demuestre funcionalmente todo el software.
7. Utilizar el prototipo como la primera línea de base de los requisitos.
8. Escribir una documentación de usuario detallada, basada en el prototipo anterior.
9. Crear documentación de requisitos no funcionales para algoritmos, procesos, interfaces con otros sistemas hardware y software, etc.

Por supuesto, hay que tener algunos puntos en consideración:

• Todos los documentos anteriores, así como el prototipo, se pondrán bajo control de cambios a partir de su primera versión. Es fundamental no esperar a fases posteriores, ya que el versionado no es sólo para controlar lo entregado al cliente, sino que nos evita múltiples problemas, proporciona agilidad (especialmente cuando hay que echar cambios atrás), y apenas nos quita tiempo (sobre todo si se automatiza).
• El prototipo no necesita tener código. Existen herramientas de prototipado basadas en flujos de acciones, flujos de procesos. Pero también las hay que simplemente dibujan pantallas. Un simple PowerPoint puede ser una herramienta de prototipado ágil, y efectiva. Un powerpoint es fácil de reproducir en cualquier dispositivo (PC, tablet, móvil, ...), no requiere instalación...

En las próximas entradas, revisaremos en detalle cada uno de estos puntos, y cerraremos el ciclo completo de toma de requisitos desde la experiencia.