Cuando se empieza a conceptualizar un sistema, a veces las peticiones de nuestros usuarios o clientes se centran en el qué debe hacer y se obvia la parte de cómo. Por “cómo” me refiero a los frecuentemente ignorados requerimientos no funcionales.
Para los interesados en crear un sistema, es normalmente fácil definir lo que la aplicación debe incluir: formularios para guardar datos, posibilidad de manejar diferentes tipos de usuarios, reportes, y posibilidad a exportar a Excel, etc. Si nos basamos en esto solamente y no preguntamos más allá, probablemente el resultado que se logre no cumplirá con las expectativas de nuestro cliente.
Existen dos puntos importantes que deben considerarse además de la funcionalidad deseada; ambos pueden englobarse dentro de los requerimientos no funcionales, pero es importante hacer la distinción:
- Restricciones
- Atributos de calidad
Las restricciones son las más sencillas de visualizar, dado que son decisiones ya tomadas, con un grado mínimo o nulo posible de variabilidad. Por ejemplo, podemos decir que el sistema tiene que construirse en una aplicación de escritorio porque el ambiente así lo requiere, o que tiene que construirse en un lenguaje y/o tecnología específicos porque es el estándar de la empresa. Aunque es importante considerarlas desde el inicio, las restricciones son normalmente las más visibles, ya sea investigando un poco acerca de lo que hace la empresa o que el cliente desde un inicio las declara como parte de sus peticiones.
En donde empieza a ponerse más complicado el proceso de identificación es con los atributos de calidad, como pueden ser
- Disponibilidad
- Desempeño (performance)
- Seguridad
- Modificabilidad
En inglés es muy común identificarlos como -ilities, dado que la mayoría tienen la misma terminación. El problema normalmente es que no acostumbramos a hacer las preguntas correctas (o a veces ni siquiera a hacerlas) y los clientes muchas veces no tienen idea de qué es exactamente lo que necesitan. De este modo terminamos con adjetivos subjetivos como lento, rápido, siempre, etc.
Por ejemplo, un cliente me dijo alguna vez que la nueva versión de su aplicación debía estar disponible siempre. Era entendible su petición después de que su aplicación se caía constantemente y les hacía perder ventas, pero ni siquiera Netflix tiene una disponibilidad del 100% (Su esquema de disponibilidad es de 99.999% de acuerdo a este video bastante interesante).
Estos atributos tienen una razón de ser, la cual debe estar asociada a las metas de negocio y con ello definir su factibilidad. A final de cuentas el cliente o usuario final tienen la última palabra en cuanto a estos atributos, pero es responsabilidad del arquitecto hacerles ver el costo que implicaría alcanzarlos logrando un balance con los objetivos del negocio que se buscan cumplir con el sistema en cuestión.