Toma de Requisitos - Paso 7: Prototipo como Requisitos 1.0

Toma de Requisitos - Paso 7: Prototipo como Requisitos 1.0

Hoy vamos a continuar explicando los pasos necesarios para una toma de requisitos, con el paso nº 7: establecer el prototipo como la primera versión de los requisitos.

Esta entrada forma parte de una serie cuyo índice es el siguiente:

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.

Una vez llegados a este punto, tendremos un prototipo bastante completo. Pero...¿No se trataba de tomar los requisitos? ¡Pero si ya los tenemos! Basta con considerar el prototipo como la primera versión de los requisitos.

Para ello, el prototipo debe cumplir una serie de características:

• Debe ser estable.
• Debe haber un compromiso por parte del equipo de desarrollo de hacer el software realmente a imagen y semejanza del prototipo.
• El cliente, o al menos los usuarios clave, han de validarlo.
• Debe ponerse al prototipo bajo control de cambios. No podemos modificarlo a la ligera. Un cambio en el estilo, en el flujo, en la funcionalidad...nos puede provocar una tormenta imparable de cambios.

A partir de aquí, basaremos todo en el prototipo, de forma que sirva de base para crear:

• Las estimaciones.
• Los planes.
• La estructura y organización del equipo.
• Los diseños.
• EL desglose del trabajo que permita construirlo.

Y aquí da igual la metodología que usemos. Sea ágil o no, hay que aceptar los cambios en el prototipo, como parte de los cambios que se requieren para el producto final.

El control de cambios no significa "ya está", "ya lo tenemos y no hay que tocarlo". Pero sí significa que tenemos que estar atentos a cada cambio, y realizar el adecuado seguimiento antes de aceptarlo, rechazarlo, o ponerlo "en espera". Ya dedicaremos un día algún artículo más detallado al control de cambios, y algunos trucos al respecto que espero os sean útiles.

Por desgracia, la manera más común de tratar los cambios es aceptar todo sí o sí, desbaratando cualquier plan existente, y evitando realizar nuevos planes, que al final, pudieran habernos llevado al éxito. Por desgracia, es así en demasiadas ocasiones. Y es que nos ciega el éxito, nos da miedo involucrar al cliente y realmente llevar un buen control de cambios. En fin.

Una vez tenemos la primera línea base del prototipo, la primera versión por tanto de los requisitos, tendremos una serie de logros adicionales:

• Posibilidad de empezar con la documentación de usuario (manuales, etc).
• Preparar los planes de pruebas, con todo detalle.
• En paralelo, también pueden comenzar la arquitectura, diseño y algunas tareas de implementación.

En el siguiente post de esta serie, veremos ya la creación de documentación, y la toma de requisitos no funcionales.

Un saludo.