IMPORTANCIA DEL PROPÓSITO DEL REQUERIMIENTO DE SOFTWARE /

Cuando se inicia el proceso de un “Análisis de Requerimientos”, hacia el desarrollo de un producto de nuevo o mejora de software, uno de los primeros pasos es en entender los alcances y visión del proyecto.  Esto suena muy bien partiendo del hecho de que la persona que realiza una solicitud conoce bien como definir el propósito del proyecto. Pero aquí hay una brecha muy grande. Por lo tanto primero debemos tomar en cuenta quien será la persona que tendría que definir los requerimientos de alto nivel, para que a partir de esta definición sea posible al equipo de análisis definir los requerimientos funcionales, clases de usuario y demás.

Entonces se tiene que comprender que cuando se requiere definir un requerimiento de alto nivel, dicha persona, aunque no necesariamente debe de tener conocimientos técnicos de análisis, si al menos debe de conocer bien cuál es el propósito.

Por ejemplo:

“En un contexto de querer conocer la Capacidad Instalada de una área operativa, el requerimiento de primer nivel puede ser confuso o quererlo definir desde sus “incomes” o entradas en vez de los “outcomes” o salidas. Es decir, se puede caer en el querer definir el propósito de este requerimiento a partir de la manera de integrar las horas “ocupadas”, cuando en realidad lo que requieres es comprar mi capacidad de ocupación con respecto a las horas disponibles.  Por lo tanto  se puede incidir fácilmente que se necesitará más de una iteración, para llegar a cumplir el propósito del requerimiento”

Con lo anterior se puede decir, que el propósito se puede basar en las “salidas” esperadas, esto es correcto, pero solo parcialmente, ya que no basta con conocer cuáles son “las salidas deseadas”,  es importante conocer también cuál es el impacto deseado dentro de la organización. Es decir debemos de conocer quienes serán los usuarios que estarán en continua interacción y si están del todo listos para que sean integrados.

Cuando nos enfrentamos a una “mejora de proceso”, es decir migrar de un proceso manual a uno automatizado, o de un sistema “legacy” a uno “moderno”, uno de los errores más comunes son los de querer replicar la misma secuencia  de “sub-procesos” en el nuevo sistema, al final el resultado deseado ya es conocido, sin embargo es una buena práctica cuestionarse si serán necesarios replicar todo el esquema o ya es posible a través de la nueva tecnología simplificar más procesos. La práctica nos dice que siempre es posible, y si no fuese así, valdría la pena replantearse dicha migración. Ya que los recursos que serán invertidos para la nueva solución tal vez no sean del todo viables.

El impacto dentro de la organización, es también un tema a evaluar cuando se define el propósito. El impacto desde la perspectiva de mejora, debe obviamente contener mayores beneficios que impactos negativos a corto plazo que se puedan tener. Pero dejando a un lado los impactos que normalmente ocurren  durante el proceso de transición, es importante también evaluar cuáles son los interlocutores que tienen relación en dicho proceso y también los posibles interlocutores. Por ejemplo podemos pensar de primera mano, que una solución móvil se encuentra dirigida a una “clase de usuario” en específico,  pero analizando un poco más nos podemos encontrar que puede ser viable que otra “clase de usuario” diferente de la anterior también goce de ese beneficio, la pregunta sería entonces: ¿vale la pena  tal vez volver a pensar la definición de requerimiento para que el beneficio sea mayor, o es preferible acotar el beneficio en una primera etapa?.

Lo que acabamos de mencionar, se encuentra ligado también a la viabilidad de un requerimiento, ya que inicialmente un requerimiento con el furor de las cosas puede estar definido de manera muy general  y el impacto deseable tal vez sea el beneficiar a una gran cantidad de “clases de usuarios” o tipos de proceso, pero cuál es la viabilidad de que este requerimiento sea integrado?, cuál ese contexto de la organización ?, cuáles son las implicaciones legales?, cuál es la factibilidad de implementación?, se cuenta con los mecanismos necesarios parle soporte post-lanzamiento?, etc.

El proceso de definición de los requerimientos, es un proceso que debe registrarse muy minuciosamente y tan delicado, que puede ser la base que sustente el nivel de éxito de un proyecto de software. Aquí hemos anotado algunas recomendaciones prácticas para tomar en cuenta, no son las únicas pero si son puntos de Facto que no se pueden dejar a un lado cuando se requiere comenzar a realizar una especificación formal.