Arquitectos y requerimientos
Los arquitectos no diseñamos en el vacío; diseñamos para resolver problemas y potenciar oportunidades.
Los requerimientos son nuestro «material de construcción»; son el puente entre el «qué» (el negocio) y el «cómo» (la tecnología). Unos materiales defectuosos o inexistentes llevan a una estructura inestable o que, simplemente, no sirve para lo que se necesitaba.
La importancia de los requerimientos radica en tres pilares:
- Guía para la toma de decisiones: Cada decisión técnica debe estar respaldada por un requerimiento. Sin ellos, las decisiones se vuelven arbitrarias o basadas en «modas» tecnológicas.
- Gestión de Trade-offs (Compromisos): En arquitectura, ganar algo suele significar sacrificar otra cosa. Los requerimientos nos dicen qué priorizar en esos conflictos.
- Definición del éxito: Un sistema puede ser técnicamente perfecto, pero si no cumple con los requerimientos funcionales o los atributos de calidad esperados, la solución es un fracaso desde la perspectiva de negocio.
No cualquier frase escrita en un documento es un buen requerimiento, así que los requerimientos son nuestro «material de construcción», necesitamos que se nos proporcionen buenos requerimientos, y éstos deben cumplir con algunos atributos, entre los que destacan:
- Necesario: Cada requerimiento debe aportar un valor real al negocio o cumplir con una norma.
- Factible: Debe ser posible de implementar dentro de las restricciones de tiempo, presupuesto y tecnología.
- Completo: Debe contener toda la información necesaria para ser comprendido sin buscar fuentes externas.
- Consistente: No debe contradecir a otros requerimientos ya establecidos.
- Verificable: Debe existir una forma objetiva (prueba o métrica) para comprobar que se cumplió.
- No Ambiguo: Debe tener una única interpretación para todos los involucrados.
Para construir buenos requerimientos tenemos, además, ciertas estructuras que nos pueden guiar y técnicas especialmente pensadas para que dichos requerimientos partan desde el corazón del negocio: los procesos.
Además, en el caso de los requerimientos no funcionales (ojo, que son los grandes olvidados), éstos deben de ser cuantificables. En lugar de «El sistema debe escalar», un buen requerimiento sería: «El sistema debe soportar una carga de 5000 usuarios concurrentes en menos de 2 minutos con un tiempo de respuesta por debajo de los 2 segundos».
Arquitectos y analistas
Guías como SWEBOK (Software Engineering Body of Knowledge), marca claras áreas de conocimiento y sus relaciones, y las dos primeras son:
- Software Requirements: proceso de definir y documentar las necesidades y restricciones del sistema. Esta es la primera fase lógica, ya que no se puede construir un sistema sin saber qué se espera de él. Normalmente son los analistas quienes se ocupan de esta área.
- Software Architecture: diseño de la estructura del sistema, incluyendo sus componentes, sus relaciones y la justificación de las decisiones de diseño. Esta fase es crítica y se basa en el análisis de los requerimientos. Compete a los niveles 1 a 3 de C4 Model, si es que lo usas. Normalmente son los arquitectos quienes se ocupan de esta área.
Dicho esto, queda claro lo capital del trabajo del analista para que el trabajo que debe de realizar el arquticto parta de un buen material. Para hacer un buen plato, se necesitan buenos ingredientes ergo, no restemos importancia al trabajo del analista ni forcemos al arquitecto a hacer platos sin buenos ingredientes, porque no saldrán bien.