Funcionalidad: La segunda dimensión

Cuando diseñamos la Funcionalidad nos ocupamos de
que todos los casos de uso esté contemplados

Después de haber definido la Arquitectura de Información como un trabajo que se realiza manejándose en 5 dimensiones, Estructura, Funcionalidad, Navegación, Comunidades e Imagen, nos concentramos hace algunas semanas en la primera de estas dimensiones: La Estructura de Información. Vimos que con independencia del tipo de problema de gestión de información a resolver, el primer paso para lograr una solución con criterios de Arquitectura era hacer la lista de los tipos de objetos de información con los que se trabajará. Luego se definían las propiedades de estos objetos y las asociaciones entre ellos. Queremos en este post entrar en la segunda dimensión: La Funcionalidad. Un área crucial porque, después de todo, los sistemas se hacen siempre para que cumplan una función. Ahora bien, ¿qué es lo que un Arquitecto de Información considera como Funcionalidad?

En la práctica, se comprende que todos los aspectos que se integran en un sistema de información son importantes, una adecuada representación que maneje todo lo necesario, la navegación que haga fácil y estimule el uso, la calidad de la presentación que resulte agradable al usuario, la seguridad que protege los contenidos críticos, las distinción de las comunidades que interactúan con el sistema, etc. Sin embargo, en cierta forma, podemos decir que es esencial en el diseño de un sistema de información la especificación de su funcionalidad, porque ésta está ligada a la razón por la que el sistema se hace.

La definición de la funcionalidad incluye varios aspectos ligados al manejo de la información. ¿Cómo debe introducirse la data?, ¿qué validaciones hay que realizar?, ¿cuáles son las salidas que se requieren?, ¿qué transformaciones de los componentes de la información son necesarios? También cómo buscaremos la información, cuáles son las situaciones de necesidad de exploración que tendremos que resolver, eventuales reportes, servicios de alerta o mensajes que hay que producir, pasos dentro de un flujo de trabajo, etc.

Para definir la funcionalidad normalmente se parte de las situaciones de uso más frecuentes, si bien siempre hay que repasar el análisis realizado para asegurarse que todos los casos de gestión necesarios fueron tomados en cuenta. Arquitectos e Ingenieros coinciden en el empleo del término de "casos de uso", que no es más que cada una de las especificaciones de las situaciones que un sistema de información tiene que contemplar, expresados en un lenguaje que los usuarios finales y todo el equipo involucrado en el proyecto pueda entender.

En esta dimensión de funcionalidad nos enfocamos entonces en lo que el sistema o aplicación debe hacer, dejando de lado otras consideraciones como la representación de información, la seguridad, la estética, etc.

Lo que nos interesa asegurar cuando trabamos en la dimensión de funcionalidad es que especificamos en detalle todo lo que un sistema debe hacer. Que estén contemplados todos los casos de uso. La omisiones aquí pueden significar que un sistema diseñado en su casi totalidad no entre en producción porque alguien de mentalidad pragmática, con toda razón o sin ella, argumente que falta un caso que debe tomarse en cuenta en forma imprescindible, ya que sin él el sistema carece de sentido.