Todo proyecto de software tiene como punto de partida la captación de requerimientos. Durante años esta fase del proyecto ha ido investigando mejores mecanismos para una elicitación de requisitos de software óptima. Entiéndase por elicitación al traspaso de información de una persona a otra.

Problemas en elicitaciones

Uno de los principales problemas es lo que se conoce como el teléfono malogrado, muchas veces las personas cuando trasmiten una información de manera verbal a otra, obtienen como resultado una información tergiversada inintencionalmente, esto se debe a la falta práctica de replicación de ideas, falta de registro de evidencia de información, intercambio de idiomas, inferir ideas, entre otros motivos. Y dento del mundo del software la fase de captación de requisitos muchas veces sufre de una muy baja calidad de elicitación.

Lenguaje uniforme

Uno de los primeros pasos que las organizaciones deben apuntar, es al uso de un lenguaje uniforme, donde queden claros todos los conceptos, términos, palabras claves y definiciones utilizadas en la organización bajo su contexto actual. Por ejemplo, debe quedar claro para todos si internamente el software empresarial se llama, software, sistema, aplicación, erp, módulo, etc. Los nombres de las aplicaciones también deben quedar uniformes, por ejemplo en algunas empresas algunos trabajadores podrían llamar al sistema WAY500 como WAY 5.0, WAY 5 o UAY V, y confundirse con algún otro sistema que tenga el nombre muy similar. Lás áreas, los procesos, la forma de comunicación, es decir todo debe estar familiarizado y uniformizado.

Buenas prácticas

Se puede empezar a clasificar todos los requisitos de software en familias o grupos, por ejemplo, durante el periodo ENE-JUN del año 2018 existieron 23 requisitos relacionados a mejoras de procesos, 187 relacionados a reportería, 67 relacionados a nuevos mantenedores, 30 relacionados a requisitos de apps móviles, etc. Esto nos ayudará tener un flujo de trabajo para cada tipo de requisito, ya que no es lo mismo crear una app o web, que crear sólo un mantenedor maestro o reporte. Una vez establecido el flujo de trabajo, será importante tener todo un esquema de preguntas o una matriz guía para la captación de información durante una entrevista o diálogo.

Como se mencionó anteriormente es importante establecer registros de evidencias en acuerdos, prototipos e ideas que colaboren al objetivo funcional del requisito a desarrollar. Ya que, si sólo dependemos de la débil trasmisión de información verbal, provocaremos inferencias o análisis que discrepan del punto de partida.

Consejo audit

El trabajo de ambas partes, tanto usuario como desarrollador, deben reforzar sus habilidades de trasmisión y negociación de requisitos en una organización, y ambos deben velar por un trabajo en equipo. Esto se logra con una proactiva intervención de un Jefe de Proyectos, Gerente de Proyectos, o cualquier otro rango que mayor jerarquía que permita tomar decisiones salomónicas del avance de los requisitos del software.