La recopilación de requisitos es una de las actividades de mayor trascendencia en el desarrollo de software. Debemos comprometernos junto al cliente en la elección de requisitos, distinguiendo muy bien entre lo que desea y lo que necesita. Es fundamental entender bien lo que nos quiere transmitir el cliente (no olvides que el profesional eres tú y no él). Es muy fácil que olvides apuntar cosas que te ha pedido, que apuntes cosas mal (por no haberle entendido) o decidir hacer las cosas que más te apetecen a ti, mientras rechazas lo que más necesita él.
Si nunca has recopilado requisitos, no me creerás. Pero ya te irás dando cuenta según ganes experiencia. La asignatura de proyectos te puede servir para empezar a fijarte. Algunos problemas comunes al recopilar requisitos son:
- El cliente nos explica mal cuál es el problema a resolver.
- El cliente desconoce el proceso de desarrollo de software pensando que es algo muy flexible.
- Al cliente se le olvida contarnos algún aspecto importante del producto a conseguir. Por tanto, surgirá durante la realización del proyecto en forma de solicitud de cambios importantes.
Michael A. Jackson y Daniel McCracken explican que es muy difícil disponer de todos los requisitos de un sistema antes de empezar a desarrollarlo, porque el usuario no los conoce en ese momento. No hay que olvidar, que mientras se realiza el producto, el usuario se va dando cuenta de cosas que se pueden hacer y que él desconocía y, por tanto, se le van ocurriendo nuevas ideas que pueden afectar al propio objetivo del sistema en desarrollo.
Entonces, ¿cómo podemos hacer una buena captura de requisitos, minimizando nuestros errores? Aquí os cuento cómo lo enfocamos nosotros consiguiendo muy buenos resultados en P4:
- El cliente debería contribuir inicialmente, escribiendo un documento de presentación del proyecto. Escribir le fuerza a aclararse y a organizar sus ideas sobre qué le gustaría conseguir.
- El equipo de desarrollo, es decir nosotros, debemos reforzar el trabajo del cliente leyéndolo reflexivamente (entendiéndolo, criticándolo,...). Mejor que lo lean varios miembros y varias veces. Todo lo que genere dudas o lo que no esté claro si es un requisito o una sugerencia, hay que anotarlo para contrastarlo después con el cliente.
- Escribir, a partir de la presentación, la primera versión de la lista de requisitos. Organizarlos según las partes principales del producto a conseguir.
- Teniendo en mente la metáfora del iceberg, el equipo debe preparar muy bien las reuniones con el cliente. No es suficiente con asistir en modo pasivo y simplemente anotar todo lo que se dice. El trabajo con el documento de presentación nos ha permitido hacernos una idea del producto. Nuestra lista de dudas y la versión incompleta de requisitos nos servirán para lanzar preguntas oportunas y definir mejor el producto.
- Después, en reuniones de equipo conviene contrastar lo que se ha entendido y completar la lista de requisitos.
- Conviene elaborar un prototipo hueco de funcionalidad para contrastar con el cliente si le hemos entendido bien antes de meternos con el grueso de la implementación.
No comments:
Post a Comment