Requisitos y diseño en proyectos… ¿hay alguna diferencia?

La semana pasada tuve el orgullo de impartir el primer curso de preparación de la certificación CBAP, después del cambio de modelo de certificaciones realizado por el IIBA (Nuevo CBAP a la vista). Uno de los temas que generó mayor controversia a lo largo del curso, fue la separación que realiza la Guía del BABOK v3 entre los conceptos de requisitos y diseño. La propia Guía del BABOK insiste en que “la distinción entre requisitos y diseños no está siempre clara” y que, en función del tipo de proyecto que se realice, la responsabilidad del analista de negocio en el diseño es mayor o menor.

Guía Babok en requisitos como proyectos

La Guía del BABOK define requisito como “una representación usable de una necesidad. Los requisitos se centran en la comprensión de qué tipo de valor podría ser entregado si se cumple un requisito.” Dicho de otra manera, los requisitos son el enlace con la necesidad de negocio y van evolucionando desde más alto nivel (objetivos de negocio) a mayor nivel de detalle a medida que se adquiere mayor conocimiento de la solución y del valor esperado. Existen, en función del nivel de detalle y del foco de los requisitos, diferentes tipos de requisitos: de negocio, de stakeholder, de solución (funcionales y no funcionales), de transición. Pero con independencia del nivel de detalle y la manera de representarlos, los requisitos se focalizan en el valor aportado al negocio. Y define diseño como “una representación usable de una solución. Los diseños se centran en la comprensión de cómo el valor podría ser realizado por una solución si se construye.” Es decir, el diseño sirve para dar forma a los requisitos en una solución que pueda ser implementable. El diseño, por lo tanto, se focaliza en cómo se construirá el sistema, no cómo funcionará. Es similar a la diferencia entre un plano realizado por un arquitecto que muestra cómo será el edificio en términos de distribución, habitaciones, etc. (requisitos), y los planos de ingeniería de construcción que muestran cómo se construirá el edificio (diseño). Es habitual que en proyectos IT se haga la distinción entre requisitos de solución funcionales y no funcionales (que describen las características y funcionalidades que debe poseer la solución), y el diseño técnico (que describe como se implementará técnicamente, incluyendo diseño físico de base de datos, estructura de componentes de código, etc.) Normalmente, en este tipo de proyectos, el trabajo de analista se queda a nivel de comportamientos esperados de la solución, y son arquitectos o expertos técnicos quienes definen el diseño técnico. En proyectos ágiles, es habitual que la evolución en el nivel de detalle de los requisitos se realice a través de la descomposición de User stories y los diseños, en forma de prototipos y diagramas, permitan ir ganando la comprensión y aceptación por parte de stakeholders de negocio y técnicos acerca de cómo implementar la solución. Pero la definición que se da en la Guía del BABOK es más amplia: a partir de unos requisitos iniciales de negocio, un diseño (en forma de, por ejemplo, workflow de proceso o mockup de interface de usuario), puede permitir identificar o descubrir nuevos requisitos para la solución, que, a su vez, desembocan en un diseño orientado a componentes técnicos. Es decir, el diseño permite avanzar en el descubrimiento de requisitos de mayor nivel de detalle, a la vez que orienta y posibilita la implementación de la solución. Al final, lo único que importa es que la implementación responda al diseño y cumpla con los requisitos. Desde el punto de vista de analista tendremos que asegurarnos que la solución implementada le aporte el valor esperado al cliente y resuelva su necesidad inicial, y para ello, tendremos que “utilizar” tanto requisitos como diseños.