El éxito o fracaso del desarrollo de aplicaciones, radica en gran medida en comprender lo que el cliente quiere, en traducir sus deseos en un sistema informático, mediante una toma de requisitos adecuada.
Sin embargo, al tratarse de un deseo humano, aterrizar una idea que puede ser abstracta o hasta absurda; es un asunto delicado, que debe ser llevado con mucha rigurosidad, con el propósito de cuantificar, y hacer factible una idea con las herramientas digitales actuales.
Entrevista Inicial con el cliente
Es por eso que una toma de requisitos, debe iniciar con una entrevista informal, donde el cliente narre todo su proceso, visto desde el punto de vista de su negocio, con el fin de captar el propósito final de su deseo de automatización.
Es importante, si es posible, grabar esa conversación, recolectar los esquemas u otros documentos que el cliente use para explicar sus deseos.
Hay que recordar que la percepción de una idea depende del receptor, de su formación, ideas preconcebidas o prejuicios. E incluso, con el paso del tiempo, podemos cambiar nuestro entendimiento, si no tenemos un registro fiable de una conversación.
Esta entrevista debe ser complementada con algunas preguntas ya enfocadas al deseo de crear un programa informático, como por ejemplo, averiguando el tipo y formato de datos de entrada, la interacción con otros sistemas existentes, o de otras personas con el sistema, etc.
Historias de Usuario o Casos de Uso
Toda esta información será modelada para aproximar el entendimiento del proceso del cliente, a un sistema informático que puede estar satisfaciendo total o parcialmente sus deseos, ya sea en forma de historias de usuario o casos de uso.
Esta primera aproximación debe recibir realimentación directa del cliente, para validar que efectivamente se entendieron sus deseos, dándole un alcance delimitado, donde dejan de aparecer términos subjetivos como «quiero que sea muy lindo», «debe ser un sistema inteligente».
Este entendimiento en la toma de requisitos debe ser medible, sin dar lugar a controversias posteriores con respecto a percepciones humanas que cambian de un sujeto a otro.
Prototipo funcional
Incluso una buena práctica para llegar a un entendimiento más concreto de un requerimiento, es la creación de un prototipo funcional que permite mostrarle al cliente como funcionaría el sistema, desde el punto de vista de los diferentes roles que intervienen con él.
Una juiciosa toma de requisitos, donde el cliente interviene en todo el proceso, hasta aceptar la interpretación de sus deseos en términos informáticos, es en gran parte el éxito que puede lograr un proyecto de software; evitando malos entendidos, alcances confusos o no incluidos, o hasta cambios radicales de un sistema mal especificado desde el principio.
[metaslider id=»7943″]
Este artículo hace parte del sistema de divulgación de conocimiento de ITSoftware SAS.