Todo software es creado por y para personas (al menos de momento). Y esto es lo que realmente complica la programación y, de hecho, todo el proceso de la ingeniería de software. Y lo que la diferencia de otras ingenierías. Sí, el resultado de toda ingeniería son elementos que se usan o impactan en personas pero no tan directamente como en el mundo del software.

Muchas veces utilizamos los usuarios como “excusa”. Les echamos la culpa de todos nuestros problemas. Incluso cuando realmente, no es que sean “tontos” sino que realmente nuestra interfaz de usuario es mala, el tiempo de carga es excesivo o hay muchos errores no controlados.

Pero hoy me gustaría fijarme en uno de los problemas más graves: la definición de los requisitos del software. Si esto no lo tenemos claro, da igual lo que hagamos después. O como lo hagamos, ni el pair programming ni ninguna otra técnica súper avanzada (o, peor, “cool”) van a ayudarnos a crear un software que responda a lo que quería el cliente. Más que nada porque no sabemos realmente lo que quiere el cliente.

La captura o elicitación de los requisitos es una de las principales áreas de estudio en el mundo de la ingeniería de requisitos. Hay montones de artículos y trabajos que buscan asegurar que conseguimos llegar a un conjunto de requisitos preciso y completo al hablar con el cliente (y con todos los otros perfiles de usuario del futuro sistema). Para el que quiera leer sobre el tema, este artículo, un clásico del tema, da referencias más que suficientes para empezar: Requirements engineering: a roadmap.

No es mi objetivo resumir estas técnicas sino presentaros un vídeo que ilustra muy bien lo complicado que es ser preciso con los requisitos. Propongo que este vídeo se usa al:

  • Empezar las entrevistas con los clientes de un nuevo proyecto, para que tomen conciencia de la importancia de ser claros
  • En todo curso de primero de programación, para que los futuros programadores entiendan la importancia de la comunicación y habilidades sociales en su futuro como programador (a añadir a la lista de lecciones para un programador en su primer día de “cole”)
  • Y ya puestos, a la familia (o al “cuñado” de turno) cuando digan que la programación es fácil.

Además el vídeo es divertido (al menos en mi opinión) con lo que es una buena manera de aprender este concepto añadiendo un poco de distensión a la reunión.

Hay una verdadera colección de videos parecidos o sea que si éste no os gusta, probad con algún otro.

Fijaros como el vídeo juega mucho con la ambigüedad de los requisitos, sobre todo con el hecho de que los niños expresan es una “underspecification”. Es decir dan algunas condiciones que el producto final debe cumplir pero no todas con la que hay más de una manera de implementar lo que piden pero que no son lo que el niño realmente quería. Este problema concreto también se conoce como el “frame problem” y no lo encontramos sólo en la especificación de requisitos sino en cualquier otro tipo de especificación (ejemplo, los contratos de las operaciones/funcionalidades).

Diréis: ¡si lo que hay que hacer es de sentido común!. Cierto, pero el sentido común es el menos común de los sentidos. Y no es igual para todo el mundo con lo que codificarlo no es trivial. De hecho según Yann LeCunn la siguiente revolución en el mundo de la IA vendrá cuando podamos dotar a las máquinas de cierto sentido común que les permita acelerar mucho su aprendizaje gracias a descartar todos los escenarios que no tienen sentido. Ahora mismo, tiene que descubrir hasta las leyes físicas más básicas (ej: la ley de la gravedad) por si solas, en cambio un niño enseguida aprende la intuición de que las cosas caen y lo incorpora en sus predicciones futuras. Pero esto ya es una historia para otro día.