Después de la visión viene la lista de requisitos

Después que los involucrados están identificados en la visión,
lo siguiente es el trabajo técnico de elaborar la lista de requisitos

En relación a lo que ocurre en el comienzo del ciclo de vida de una aplicación, hemos estado hablando de la primera fase: la identificación del problema y de la solución. Hemos comentado que en esta fase inicial definimos el cambio que queremos realizar y nos esforzamos en lograr una identidad de todos los involucrados en una visión común de lo esperado. La visión describe lo que percibimos como situación actual, la situación alternativa que queremos, la importancia de lograr el cambio y los beneficios que se esperan obtener con ello. Ahora bien, ¿después de ella que viene? La respuesta es que bajamos un poco más hacia los detalles, ya que lo próximo es la definición de los requisitos.

Elaborar una lista de requisitos es un trabajo técnico. Es la definición de las características, capacidades, condiciones o atributos funcionales que se espera que un sistema tenga. La lista de requisitos con los que debe cumplir una solución es una de descripción de cualidades y metas. Normalmente los requisitos no están vinculados con el cómo alcanzarlos, sino más bien establecen con precisión el qué es lo que se debe lograr.

Los requisitos pueden ser de dos tipos: funcionales o no funcionales.

Los requisitos funcionales son capacidades que debe tener un sistema  para cumplir sus objetivos y realizar eficazmente las tareas para los cuales fue diseñado. Este tipo de requisitos define lo que la solución debe hacer. Por ejemplo, tener la capacidad de generar una cierta salida, a partir del procesamiento de la información almacenada en un momento dado.

Los requisitos no funcionales son capacidades que debe tener la solución que son independientes de la función que los sistemas involucrados en ella cumplirán dentro de la institución. Con este tipo de requisitos se establecen metas de rendimiento o condiciones no técnicas o no funcionales. Por ejemplo, tener la primera fase lista para una cierta fecha, ser compatible con una cierta política de desarrollo de soluciones, resolverse con una arquitectura de información bien definida, ser compatible con un cierto sistema o reglamento, etc.

Los requisitos tienen un gran impacto en el plan y la ejecución del desarrollo de la solución, y por tanto en los costos, por lo que es importante que se exija en ellos lo que sea realmente necesario y que sean lo suficientemente precisos y claros para que sean entendidos por todos sus lectores, sin necesidad de aclaratorias.

Son más útiles y funcionan mejor si son concisos y completos como para definir lo necesario sin ambigüedad y si están redactados como cualidades verificables.

Los Arquitectos de información analizan los requisitos como parte de la definición o conceptualización de la solución. Este análisis debe contribuir a mejorar la redacción de los mismos y servir para eliminar los requisitos que sean innecesarios porque no aportan a la definición de la solución, así como incluir cualquier otro que si sea necesario para tener una lista consistente de exigencias para la solución.

Como los requisitos eventualmente se cambian, las buenas prácticas profesionales recomiendan que se haga un proceso de gestión de los mismos donde haya trazabilidad entre los cambios en los requisitos y las implicaciones de estos cambios en el plan de desarrollo de la solución, de tal manera que el proceso sea controlado. El cambio sin control de los requisitos puede impactar negativamente en el desarrollo de la solución, dificultando la convergencia de los procesos y el cumplimiento de las metas del desarrollo.