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

Alfred Maeso Aztarain

Alfred Maeso Aztarain

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

Compartir

Share on email
Share on facebook
Share on twitter
Share on linkedin
Share on pinterest

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.

Forma parte de la comunidad #AlwaysLearning

Sobre el autor

Alfred Maeso Aztarain

Alfred Maeso Aztarain

Alfred, Lead Expert de Netmind en Business Analysis, Change Management, Portfolio, Program y Project Management, tiene más de 15 años de experiencia en la dirección de proyectos de TI y servicios de TI para diferentes organizaciones y la administración pública. El interés y la experiencia de Alfred se centran en el Business Analysis y el Program y Project Management. Es licenciado en Ingeniería de Telecomunicaciones y está certificado como MSP, MoP e ITIL Approved Trainer. Trabaja para inspirar el cambio en las organizaciones y cree que el conocimiento y el aprendizaje continuo son los pilares del cambio. Alfred se dedica con pasión a aprender y a compartir conocimientos con las personas con las que colabora. Entre sus certificaciones se incluyen: CBAP, SAFe® 4 Certified Program Consultant, AgileBA Practitioner, Change Management Instructor, PRINCE2 Agile Instructor, CSM Certified Scrum Master, PMI-PBA®, y PMP® Project Management Professional. ¡Conecta con Alfred en LinkedIn!

Insights relacionados

SOLICITAR FORMACIÓN A MEDIDA

Por favor, proporciona la siguiente información para ayudarnos a personalizar la solución.

CONTÁCTANOS

Netmind España
Barcelona +34 933 041 720
Madrid +34 914.427.703

Nos puedes encontrar de:
Lunes – Viernes, 9:00-18:00 (GMT+1)

¡Te ayudamos!
info@netmind.net

¿Dudas sobre servicios/formaciones?
comercial@netmind.es

Solicitar Información