El objetivo del análisis funcional es modelar el producto software explicando las interacciones entre los usuarios y el sistema. Este tipo de análisis pretende detallar qué funcionalidad implementará el producto software para dar solución a los requisitos. El análisis funcional del software entrega las especificaciones del software, refinando y destilando los requisitos obtenidos previamente. Estas especificaciones son los “planos” funcionales del producto software.
Imagine el siguiente requisito expresado como una Historia de Usuario: “Como técnico administrativo quiero consultar los pedidos pendientes en una determinada fecha para planificar el envío de los albaranes”. Si se prescindiera del Análisis Funcional, entonces un diseñador o programador bajo “presión de calendario” podría ofrecer una solución basada en concatenar en texto plano las descripciones de los pedidos y, aunque efectivamente el sistema daría solución al requisito, la funcionalidad ofrecida por el software estaría muy alejada de la deseada del cliente. Es labor del analista aterrizar y detallar qué funcionalidad debe entregar el producto software despejando posibles ambigüedades. El análisis funcional detalla y concreta cómo debe ser la solución al requisito. En este ejemplo, el analista funcional podría especificar un caso de uso del sistema que requiera la presentación de los pedidos en una lista ordenada cronológicamente. De este modo, el programador o diseñador ve reducida la cantidad de posibles soluciones.
Los analistas hacen uso, además del lenguaje natural, de todo tipo de diagramas, gráficos o tablas para facilitar la comprensión de la solución planteada tanto a quién la diseñará y programará (equipo de desarrollo), como a quién la validará y aceptará (usuarios líderes y clientes). Estas especificaciones funcionales son destiladas y refinadas a partir de los requisitos previamente recogidos.
En la construcción de software con visión predictiva, la especificación del producto tiene forma de listado detallado de requerimientos. El cambio no es “bienvenido”, por lo tanto, se requiere detallar minuciosamente toda la funcionalidad del sistema propuesto.
En la construcción de software con visión adaptativa, las especificaciones del software no se concretan con tanto detalle. A diferencia de la visión predictiva, no es tan importante detallar minuciosamente toda la funcionalidad del sistema propuesto. Si el equipo de desarrollo construye una funcionalidad de forma equivocada, el malentendido será solventado en la siguiente iteración. En la visión adaptativa el cambio es “bienvenido”.
En ambos escenarios es habitual acompañar las especificaciones con diagramas y prototipos para facilitar su comprensión tanto por parte del negocio como por parte del equipo técnico. El análisis funcional refina las interacciones de los usuarios desde los diagramas de casos de uso, el nivel más alto y abstracto, hasta los prototipos de las pantallas, el nivel más bajo y concreto. De esta manera, los análisis funcionales suelen incluir:
Casos de uso. Los casos de uso expresan las especificaciones del producto software. Los casos de uso son los requerimientos que el diseño técnico debe suplir. Son definidos a alto nivel, por ejemplo, el caso de uso no detalla exactamente qué botones el producto ofrecerá.
Prototipos. Ejemplos y bocetos de las pantallas con las que los usuarios interaccionarán. Los prototipos ayudan a explicar a bajo nivel cómo será la interacción del usuario indicando, por ejemplo, qué caja de texto el usuario editará antes de pulsar un determinado botón.
El caso de uso describe la interacción del usuario con el producto software.
En 1986, Ivar Jacobson, importante contribuyente al desarrollo de los modelos de UML y proceso unificado, creó el concepto de “caso de uso”. Durante los años 90 los casos de uso se convirtieron en una de las prácticas más comunes para la especificación de requisitos.
El caso de uso debe evitar el uso de términos técnicos, en su lugar debe describirse con lenguaje natural cercano al usuario. También debe expresarse, sintácticamente, como una oración con sujeto, verbo y predicado. Por ejemplo, “Base de datos” o “fichero” o “factura” no pueden ser casos de uso, en su lugar el caso de uso podría ser “el administrativo registrará una factura”.
Es importante que el caso de uso tenga un propósito que resulte valioso para el producto software. Por ejemplo, la interacción “el técnico comercial escribirá su nombre de usuario en una caja de texto” o “el técnico comercial escribirá su contraseña en una caja de texto” no tienen valor para el sistema. Un caso de uso con valor para el sistema podría ser “el técnico comercial se autenticará en el sistema”.
El caso de uso se centra en describir cómo alcanzar una meta o tarea de negocio. El grado de detalle requerido depende en parte de la metodología seguida en la construcción, por ejemplo, la visión predictiva exige detalles muy finos. El caso de uso debe describir interacciones con los actores sin hacer referencias explícitas a elementos concretos de la interfaz de usuario del sistema a desarrollar, estos detalles son más propios de los “prototipos”
El diagrama de caso de uso ofrece una representación de las especificaciones del software a altísimo nivel. Por ejemplo:
Un diagrama de caso de uso es una relación de acciones realizadas por el sistema, que producen un resultado observable y valioso para un usuario en particular, es decir, representa el comportamiento del sistema con el fin de dar respuestas a los usuarios. Los diagramas expresan las interacciones a muy alto nivel, estos diagramas no pretenden mostrar los detalles de la interacción.
Los diagramas de casos de uso proporcionan un modo claro y preciso de comunicación entre cliente y desarrollador. Desde el punto de vista del cliente proporcionan una visión de “caja negra” del sistema, se muestra el sistema desde el exterior sin necesidad de entrar en los detalles de su construcción. Para los desarrolladores, suponen el punto de partida y el eje sobre el que se apoya todo el desarrollo del sistema en sus actividades de diseño, codificación y pruebas.
Los diagramas de casos de uso forman parte del estándar UML. Presentan los siguientes tipos de elementos:
Actor. Un actor es algo o alguien que se encuentra fuera del sistema y que interactúa con él. En general, los actores serán los usuarios del sistema y los sistemas externos al que se esté desarrollando. Un actor se representa con una figura de "hombre de palo" con el nombre del actor debajo de la figura.
Casos de uso. Un caso de uso representa el comportamiento que ofrece el sistema de información desde el punto de vista del usuario. Un caso de uso se representa mediante una elipse con el nombre del caso de uso dentro o debajo.
La relación entre casos de uso es unidireccional. Puede representar “usa a” o “extiende de”:
La relación “usa a” o “incluye a” se utiliza cuando se quiere reflejar un comportamiento común en varios casos de uso. Es decir, si los casos de uso A y B presentan una parte común, esta se puede extraer a un tercer caso de uso C. Entonces, habrá una relación “usa” o “incluye” del caso de uso A al C y otra del B al C.
La relación “extiende de” se utiliza cuando se quiere reflejar un comportamiento opcional de un caso de uso. Por ejemplo, el caso de uso A que representa un comportamiento habitual del sistema, sin embargo, dependiendo de algún factor, este caso de uso puede presentar un comportamiento adicional o ligeramente diferente, que se podría reflejar en un caso de uso B. En este caso, habrá́ una relación “extiende” del caso de uso B al A.
Los casos de uso pueden describirse formalmente. Cada caso de uso contiene: Identificador, Nombre, Referencias a otros casos de uso que utiliza, Autor, Fecha de actualización y de creación, Actores, Descripción, Desencadenador (trigger), Precondición, Postcondición, Flujo, Frecuencia de uso, Excepciones, Reglas de negocio y Notas.
el prototipado tiene como objetivo elaborar un modelo o maqueta de las interfaces entre el sistema y el usuario (formatos de pantallas, informes, formularios, etc.), que ayude a comprender como se producirá́ la interacción. El prototipado simula el aspecto visual del sistema representando conceptos, componentes, objetos gráficos, así como las entradas y salidas requeridas. De esta manera, ayudan a expresar las interacciones de los usuarios con el sistema de manera muy detallada y concreta.
Existen herramientas gráficas que facilitan el diseño de interfaces de usuario como por ejemplo pencil. Si bien, estas herramientas permiten “esbozar” el aspecto de la interface gráfica, no permiten desarrollar aplicaciones interactivas.
La explosión de herramientas software que facilitan a los analistas la construcción de, incluso, prototipos interactivos, ha llevado al prototipado a ser la principal técnica de análisis funcional. Los prototipos forman parte de técnicas como el Design Thinking y el Design Sprint para la validación rápida de posibles soluciones.
Es importante no confundir el prototipo interactivo con el Producto Mínimo Viable. El Producto Viable Mínimo (MVP, del inglés Minimum Viable Product) es un producto con suficientes características para satisfacer a los clientes iniciales, y proporcionar retroalimentación para el desarrollo futuro. El Producto Mínimo Viable se despliega en el entorno de Producción, el Prototipo interactivo sin embargo no llega a desplegarse, el prototipo es utilizado para ayudar a construir el producto (el prototipo no es el producto).
🔎 El Design Sprint es una metodología ágil desarrollada por Google, el sprint se lleva a cabo, idealmente, en cinco días. A partir de aquí el lunes se define un objetivo realista, el martes se generan ideas y se definen los usuarios con los que se va a testear la solución, el miércoles se seleccionan las ideas, el jueves se prototipan y finalmente el viernes se testean las soluciones con el público objetivo. Es muy utilizada por los diseñadores UX/UI para recoger un rápido feedback del cliente.
Referencias:
• Métrica-3 Técnicas. Administración Electrónica del Gobierno de España.
• S. Gómez, E.Moraleda; "Aproximación a la Ingeniería del Software", Editorial Universitaria Ramón Areces, 2014
• I. Sommerville; “Ingeniería del Software”, Addison Wesley, 2005