Unas de las primeras fases de cualquier proyecto es la definición de los requisitos. ¿Para qué sirve esta fase? El objetivo es sencillo, definir el alcance del proyecto.
Si consideramos el proyecto como un viaje, los requisitos tienen que definir el destino del viaje y los puntos principales por donde vamos a viajar. Siguiendo con el símil, difícilmente llegaremos a donde queremos ir si no definimos ni donde queremos ir ni una ruta mínima.
Los requisitos pueden ser una fuente de problemas por no darles la importancia necesaria y en ocasiones se realiza de una forma muy ligera o incluso se salta esta fase.
¿Por qué es importante esta fase? Porque todo proyecto tiene unos costes, ya sean económicos o simplemente de tiempo. Pero aun sobrándonos el dinero y el tiempo, necesitamos saber donde vamos, que deseamos hacer y hasta donde queremos llegar.
Hay un ejemplo clásico de una mala definición de requisitos que fue la primera versión de Word para Windows. En su primera versión, el procesador de texto solo tenía un requisito: ser el mejor procesador de textos del momento. En aquella época, era WordPerfect quien lideraba el procesamiento de textos y Bill Gates actuó como jefe de proyecto con este único objetivo. Se consumieron recursos y tiempo, se sacó al mercado pero el producto no tuvo el éxito esperado, a un coste quizás excesivo. Posteriormente, con la definición de requisitos más claros, Microsoft si fue capaz de crear el mejor procesador de texto.
Otro error habitual en los desarrollos a medida, es no hacer la fase de requisitos porque “solo se trata de un cambio mínimo”. Siempre es difícil precisar que significa “un cambio mínimo”, pero un problema que tiene este tipo de actuaciones es que se pierde la trazabilidad de los cambios que se introducen en las aplicaciones. Un cambio mínimo puede ser cambiar un literal, es un cambio sencillo rápido y sin muchas implicaciones, casi siempre, porque qué ocurre si al equipo de desarrollo le llega el cambio directamente por un correo, se implementa pero cuando llega a producción otra persona de la empresa cliente piensa que no había que haber cambiado el literal. Normalmente la empresa que desarrolla tiene que buscar el correo donde se le indicaba el cambio remitirlo, que el cliente se ponga de acuerdo y si no es el literal correcto, volver a dejar el literal anterior. Todo esto supone un consumo de tiempo y dinero. Si las entradas llegan a la empresa de desarrollo a través de requisitos y si esos requisitos tienen que ser validados por el cliente antes del envío, estos problemas se evitan. Por supuesto, esto se consigue con una fase previa a lo que sería el inicio del proyecto que es establecer un marco de comunicación entre ambas partes de cara a afrontar el proyecto.
Incluso cuando el proyecto es un proyecto personal conviene definir qué requisitos queremos cubrir. Principalmente, porque definimos que queremos hacer y hasta donde queremos llegar. Sin eso, puede que le dediquemos mucho tiempo pero cuando alguien nos pregunte como vamos, digamos: “ya está casi”. Ese casi es demasiado ambiguo, porque el casi puede ser un día o dos meses, y ¿donde se origina esa indefinición? en que los requisitos no se encuentran bien definidos.
