Los requisitos se pueden dividir en dos categorías.

Los requisitos funcionales son los que rodean las necesidades del cliente; por ejemplo, ¿a qué áreas del sistema necesita acceso este grupo de usuarios?

Luego, los requisitos no funcionales se centran en el sistema.

Estos, a su vez, se pueden dividir en dos áreas que abarcan muchos factores cada una.

Primero están los conocidos como "atributos de calidad empresarial", por ejemplo, tiempo de comercialización, coste o ROI.

Luego están los "atributos de calidad del sistema", como la disponibilidad, la seguridad, la escalabilidad, etc.

Este primer paso es muy importante porque la falta de un requisito inicial puede tener un gran impacto en el rendimiento general del sistema en el futuro.

Como la experiencia demuestra en muchos casos las definiciones iniciales de los responsables de  los proyectos no son las correctas por no considerar la arquitectura del sistema. En consecuencia el equipo construye bajo un supuesto erróneo y los costos finales son muy altos.

La raíz de este problema fue que los requisitos iniciales eran incorrectos: fueron definidos por personas sin la experiencia necesaria en la arquitectura del sistema para realizar dichos requisitos.

El mejor enfoque sería garantizar que las personas adecuadas estén en el lugar para reunir los requisitos del sistema; esto requiere un conjunto de habilidades que se extienden más allá del producto, el desarrollo o la arquitectura.

 

Hay 3 áreas principales de conocimiento que son relevantes aquí:

Conocimiento de la arquitectura del sistema

Comprender los fundamentos de cómo se construyen los sistemas es la base para liderar a los equipos hacia un desarrollo exitoso.

Es un área de conocimiento compleja porque los sistemas no son específicos del desarrollo de software, pero aprender los conceptos y luego estudiar el contexto de la arquitectura del software es necesario para obtener experiencia.

 

Mentalidad del producto

Como arquitecto, es importante tener la mentalidad de propietario o gerente de producto.

Los elementos clave de esto son una comprensión fundamental de la visión, el alcance y la hoja de ruta del sistema que se va a construir.

Cuando se trata de una verdadera mentalidad sobre el producto, no se puede olvidar a ningún interesado.

Los requisitos deben recopilarse de todos los roles involucrados en el desarrollo y uso del sistema: usuarios, gerentes, inversores, desarrolladores, diseñadores, etc.

Un arquitecto es responsable de resolver las necesidades comerciales utilizando tecnología: sin comprender las necesidades comerciales, la solución entregada no ser valioso.

 

Habilidades blandas

Para aplicar el pensamiento del producto a la arquitectura del sistema, un arquitecto debe poder trabajar bien con cada parte interesada para recopilar la información relevante.

Esto significa poder hablar varios idiomas, no es fácil.

Por ejemplo, no es óptimo hablar de cosas como la refactorización de código o los microservicios con un especialista en marketing; quieren saber qué tan rápido es el producto para sus clientes.

Viceversa: hablar sobre los perfiles de los clientes con un desarrollador no es la forma de comprender los requisitos de ese desarrollador.

No es posible que una persona sea un experto en cada función del equipo, por lo que trabajar con los gerentes y los miembros del equipo en cada función garantizará que cada parte interesada esté representada en los requisitos del sistema.

La buena arquitectura del sistema se reduce a un buen trabajo en equipo y a nivel individual que requiere una amplia gama de habilidades técnicas y sociales que deben aprenderse con educación y experiencia.

 

Al equilibrar los requisitos funcionales y no funcionales, teniendo en cuenta todas las necesidades de las partes interesadas y priorizando adecuadamente en colaboración con el equipo de desarrollo, un arquitecto tomará mejores decisiones y garantizará que su sistema se construya correctamente desde el principio.