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.

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.