Requisitos funcionales, atributos de calidad y restricciones

Tres tipos de requisito

Un requisito es cualquier cosa que un sistema debe cumplir para que sus partes interesadas lo acepten. A los arquitectos les resulta útil clasificar los requisitos en tres tipos, porque cada tipo influye en el diseño de una forma distinta. Un requisito funcional dice qué debe hacer el sistema: 'un cliente puede añadir un artículo al carrito', 'el sistema de farmacia comprueba cada nueva receta frente a las alergias del paciente', 'un pasajero puede ver la posición del conductor en un mapa'. Los requisitos funcionales describen el comportamiento, los datos y las reglas que los relacionan. Son lo que recogen la mayoría de las historias de usuario y los casos de uso.

Un atributo de calidad dice con qué calidad debe hacerlo el sistema. 'Los resultados de búsqueda aparecen en medio segundo', 'el servicio de reservas está disponible el 99.95% del tiempo', 'se puede añadir un nuevo proveedor de pagos en menos de dos semanas', 'los historiales de los pacientes solo pueden leerlos los clínicos que tratan a ese paciente'. Los atributos de calidad son propiedades del sistema en su conjunto o de una función, y solo tienen sentido con una medida asociada: ¿suficientemente rápido para quién, con qué carga, medido cómo?

Una restricción es una decisión que ya se ha tomado por ti. 'El sistema debe ejecutarse en el tenant de Azure que ya tiene la empresa', 'todos los datos personales permanecen en la Unión Europea', 'el equipo sabe Java y no tiene presupuesto para formarse en otra cosa', 'el primer lanzamiento debe estar en producción antes de que empiece el año fiscal el 6 de abril'. Las restricciones eliminan opciones en lugar de describir comportamiento. No son negociables dentro del proyecto, aunque un buen arquitecto comprueba que cada una sea de verdad una restricción y no solo una costumbre o una suposición.

Los límites no siempre son nítidos, y no pasa nada. El objetivo de la clasificación no es el orden burocrático; es asegurarse de que nadie reúna cincuenta historias de usuario y se olvide de preguntar cuántos usuarios habrá, cuánto tiempo puede sobrevivir el negocio a una caída o qué regulador está vigilando.

Por qué muchos arquitectos evitan el término 'requisitos no funcionales'

Los documentos de requisitos dividen tradicionalmente todo en requisitos funcionales y requisitos no funcionales (NFR). El término está en todas partes, en contratos, pliegos de licitación y ofertas de empleo, así que necesitas reconocerlo. Aun así, muchos arquitectos e investigadores lo evitan, por tres razones.

Primero, define una categoría grande e importante por lo que no es. Todo lo que no es una función acaba en el mismo cajón: los tiempos de respuesta, las reglas de cifrado, la elección del proveedor de nube y el color del logotipo. El artículo de Martin Glinz On Non-Functional Requirements (IEEE International Requirements Engineering Conference, 2007) mostró que las definiciones publicadas no coinciden en qué pertenece a la categoría y que una misma necesidad puede clasificarse de una u otra forma según cómo se formule: 'solo el personal autorizado puede ver los salarios' se lee como una función cuando se escribe como regla de acceso y como una cualidad cuando se escribe como objetivo de seguridad.

Segundo, el nombre sugiere que estos requisitos están separados de las funciones y pueden añadirse más tarde. No es así. Un atributo de calidad califica una función: es el proceso de pago el que debe ser rápido, el pago el que nunca debe perderse, el historial médico el que debe ser confidencial. Por eso Bass, Clements y Kazman, en Software Architecture in Practice, hablan de requisitos de atributos de calidad y tratan las restricciones como una categoría aparte.

Tercero, 'no funcional' suena opcional, como si un sistema que funciona pero es lento, inseguro o imposible de cambiar siguiera 'funcionando'. En la práctica, esos son exactamente los sistemas que acaban reescribiéndose. Algunos equipos prefieren 'requisitos de calidad'; otros, en particular en Thoughtworks, dicen 'requisitos transversales' (cross-functional requirements) para subrayar que atraviesan todas las funcionalidades. Este curso usa atributos de calidad y restricciones. Si tu organización dice NFR, no hace falta pelearse por la palabra; basta con asegurarse de que cada NFR sea una cualidad medible o una restricción claramente enunciada.

Restricciones: técnicas, organizativas, regulatorias, de plazo y de presupuesto

Las restricciones merecen más atención de la que suelen recibir, porque a menudo deciden más de la arquitectura que cualquier funcionalidad. Una restricción no es más que un requisito sin libertad restante. Ayuda agruparlas según su origen.

Dos hábitos ayudan. Primero, anota el origen de cada restricción (una normativa, un contrato, una persona concreta con poder de decisión) para que pueda comprobarse y, si cambian las circunstancias, revisarse. Segundo, distingue las restricciones reales de las preferencias disfrazadas de restricciones. 'Debemos usar microservicios' rara vez es una restricción; es una decisión de diseño que alguien tomó pronto, y debe justificarse con atributos de calidad como cualquier otra decisión. La sección del Capítulo 1 sobre decisiones y compromisos explica por qué las decisiones tempranas y difíciles de revertir merecen ese examen.

Requisitos arquitectónicamente significativos

La mayoría de los requisitos no afectan a la arquitectura. Que la factura muestre el código postal del cliente encima o debajo del nombre de la calle es un detalle; se puede cambiar en una tarde. Un requisito arquitectónicamente significativo (ASR) es aquel que tiene un efecto medible en la arquitectura: si cambiara, la estructura del sistema tendría que cambiar. Reconocer los ASR pronto importa porque es caro acomodarlos tarde. Añadir una sala de espera a un sitio de venta de entradas la semana antes de una venta es posible; particionar el inventario de asientos entre servidores después del lanzamiento es reescribirlo.

Lianping Chen, Muhammad Ali Babar y Bashar Nuseibeh entrevistaron a profesionales sobre cómo reconocen los ASR (Characterizing Architecturally Significant Requirements, IEEE Software, 2013). Sus conclusiones coinciden con la experiencia de la mayoría de los arquitectos. Los ASR suelen ser difíciles de satisfacer, a menudo afectan al sistema en su conjunto y no a una sola funcionalidad, con frecuencia entran en conflicto entre sí y a menudo se enuncian de forma vaga o no se enuncian en absoluto. Los atributos de calidad y las restricciones son la mayoría, pero algunos requisitos funcionales también son significativos.

Ejemplos de ASR funcionales: 'todo cambio en el historial de un paciente debe poder atribuirse a una persona y a un momento' (necesita un mecanismo de auditoría en todos los componentes), 'los usuarios pueden colaborar en el mismo documento en tiempo real' (exige un modelo de sincronización y probablemente otro estilo de comunicación) y 'los clientes pueden deshacer una transferencia bancaria en un plazo de 30 minutos' (afecta a cómo se mueve el dinero entre cuentas). Cada uno obliga a una decisión estructural, no solo a escribir más código.

Por qué las cualidades dan forma a la arquitectura más que las funciones

Esta es la idea central de este capítulo. Si solo importara la funcionalidad, casi cualquier estructura serviría: podrías escribir todo el sistema como un único programa grande y seguiría calculando las respuestas correctas. Bass, Clements y Kazman lo dicen directamente: la funcionalidad no determina la arquitectura, porque muchas arquitecturas distintas pueden ofrecer las mismas funciones. Lo que las separa es lo bien que cada una logra las cualidades.

Piensa en dos sistemas de venta de entradas con funcionalidades idénticas: explorar eventos, reservar asientos, pagar. Uno vende entradas para un salón local de 300 plazas; el otro vende una gira por estadios de 60 000 plazas. El momento de más actividad del salón local puede traer unas pocas solicitudes por segundo, y una única aplicación web con una base de datos es la respuesta correcta: barata, sencilla y fácil de cambiar. La gira por estadios debe absorber una ráfaga miles de veces mayor, no debe vender nunca el mismo asiento dos veces y debe impedir que los bots lo compren todo en el primer segundo. Ese sistema necesita una red de distribución de contenidos, una cola delante de la tienda, un inventario de asientos cuidadosamente diseñado, un almacenamiento particionado y un flujo de pago capaz de esperar a un proveedor sobrecargado. Las mismas funciones, arquitecturas completamente distintas, y la diferencia procede por completo de los atributos de calidad y las restricciones.

Cualidades implícitas que nadie pone por escrito

Algunas de las cualidades más importantes nunca se enuncian porque todas las partes interesadas las dan por supuestas. Estos requisitos implícitos solo salen a la luz cuando se incumplen, normalmente en producción. Nadie escribe 'no perder pedidos', 'no cobrar dos veces al cliente', 'seguir funcionando cuando se adelanta la hora', 'mostrar el mismo saldo en el teléfono y en el sitio web' o 'no filtrar los datos de un cliente a otro'. Sin embargo, cada uno de ellos es un ASR con consecuencias importantes: un tratamiento idempotente de los pagos, escrituras duraderas, una programación segura frente a los husos horarios, consistencia entre canales y un aislamiento estricto entre tenants.

Los requisitos implícitos se esconden por razones sociales. Las partes interesadas del negocio creen que son demasiado obvios para mencionarlos; los desarrolladores suponen que otra persona se ha ocupado de ellos; y las plantillas de requisitos rara vez los piden. Algunas preguntas útiles para sacarlos a la luz son: '¿Qué te pondría furioso si ocurriera?', '¿Qué nos haría salir en los periódicos?', '¿Qué ha fallado en el sistema que vamos a sustituir?' y '¿Por qué despiertan de noche al equipo de operaciones?'. Los informes de incidentes y las incidencias de soporte de los sistemas anteriores son una fuente muy rica; también lo son las guías publicadas por los reguladores y las obligaciones de los contratos con clientes.

Cómo trabajan los profesionales con los ASR

Los arquitectos con experiencia mantienen una lista breve y viva de ASR, normalmente de cinco a quince elementos, en lugar de un largo documento de requisitos. Cada elemento enuncia la cualidad como un escenario comprobable (Sección 2.3), nombra a la parte interesada a la que le importa, registra su prioridad y enlaza con las decisiones que motivó. La plantilla arc42, por ejemplo, pide los tres a cinco objetivos de calidad principales en su primera página y una lista más completa de requisitos de calidad más adelante. La lista se revisa cada vez que se toma una decisión importante o el negocio cambia de rumbo, y los elementos más importantes acaban respaldados por comprobaciones automatizadas llamadas funciones de aptitud, que se presentan en la Sección 2.8.