Análisis Funcional: La Clave para Entregar Justo el Software que el Cliente Necesita

UNA INTRODUCCIÓN AL ANALISIS FUNCIONAL, CLAVE EN EL DESARROLLO DE SOFTWARE DE CALIDAD

Hoy quiero compartir contigo lo que inicialmente necesitarías saber para comprender los alcances y la significancia del Análisis Funcional en la industria del desarrollo de software.

Esto no significa que de repente me haya convertido en un especialista en temas de IT, como sí lo soy en Lean Six Sigma, ni mucho menos.

En realidad, estoy iniciando un nuevo camino de aprendizaje y me gustaría que me acompañaras en este recorrido, compartiendo contigo mis nuevos conocimientos sobre el Análisis Funcional a medida que los voy adquiriendo.

Antes de continuar, permíteme hacer una breve observación personal.

En mi última publicación, exploré el uso del QFD en Six Sigma para traducir la Voz del Cliente en requisitos productivos 👉 "QFD: El Despliegue de la Función de Calidad para Exceder la Satisfacción del Cliente".

Después de un periodo de reflexión y formación, me encuentro escribiendo sobre Análisis Funcional en TI, un área que, aunque diferente, también busca entender y satisfacer las necesidades del cliente.

Sin planearlo, me veo explicando principios similares en otro contexto: de la manufactura al software.

Espero que esta entrada te aporte el valor que estas buscando. ¡Comencemos!

POR QUÉ EL ANALISIS FUNCIONAL SE VOLVIÓ TAN IMPORTANTE

En el mundo ultra-dinámico de la tecnología y los negocios, la creación de software a medida cobra cada vez más importancia.

Es impensado imaginar nuestras vidas sin los sistemas informáticos que nos rodean y, en ese contexto, el Análisis Funcional se ha convertido en una pieza clave para el éxito de los proyectos de desarrollo de software.

Como es costumbre decir en Lean Six Sigma, si a un proceso le ingresa basura (materia prima de mala calidad, datos ambiguos, personal poco entrenado, equipo mal mantenido, etc.), lo más probable es que de ese proceso también salga basura (un producto defectuoso, scrap, reclamos, etc.).

Es eso, precisamente lo que el Análisis Funcional intenta resolver dentro de un proyecto de desarrollo de un sistema informático:

Asegurar que al proceso creativo de software le ingrese la mejor data posible para garantizar que la salida sea un sistema capaz de satisfacer las expectativas del cliente de manera eficaz y eficiente dentro del contexto del negocio.

Es decir, un buen Análisis Funcional de las expectativas del cliente garantiza que el proyecto de TI esté alineado con los objetivos estratégicos del negocio, asegurando con ello no solo la calidad del producto final y la satisfacción del cliente, sino también el mínimo costo y la reducción de los tiempos de implementación.

Es ahí donde radica la gran importancia del Análisis Funcional.

¿QUÉ ES EL ANÁLISIS FUNCIONAL?

El Análisis Funcional en el desarrollo de software es el proceso de identificar, capturar, documentar y gestionar funcionalidades y restricciones de un sistema de software desde la perspectiva del usuario y del negocio.

De este modo, se asegura que el software desarrollado cumpla con los requisitos esperados, sea eficiente y esté alineado con los objetivos estratégicos de la organización.

Esto implica entender a la perfección las expectativas del cliente/usuario y traducirlas en especificaciones detalladas que guíen a los desarrolladores en la creación de una solución tecnológica que las satisfaga.

Los analistas funcionales actúan como intermediarios entre los stakeholders, entre los cuales están los usuarios y clientes, y los desarrolladores, asegurando un flujo eficaz de informaciónrelevante para que el producto final cumpla con los objetivos del negocio y las expectativas del usuario.

En consecuencia, el rol del analista funcional dentro de una empresa que brinda soluciones de software es fundamental, tanto para alinear la tecnología con las necesidades empresariales de los clientes como para maximizar el valor de las inversiones en TI.

¿QUIÉNES SON LOS STAKEHOLDERS?

Vuelvo sobre la palabra "stakeholder" dado su importancia ya que la introduje sin antes comentarte de qué se trata.

En el ámbito del desarrollo de software, los "stakeholders" son todas aquellas personas o grupos de personas, a excepción del equipo que trabaja en el producto, que, directa o indirectamente, tienen interés en el proyecto.

Dentro de esta definición puede incluirse a:

Clientes: Quienes encargan el desarrollo del software o lo usarán.
Usuarios finales: Las personas que efectivamente utilizarán el software.
Inversores: Aquellos que financian el proyecto.
Entes reguladores: Organismos que aseguran que el software cumple con las regulaciones vigentes.

En resumen, los stakeholders son individuos o grupos, tanto internos como externos a la organización, que se ven impactados por el resultado del producto.

Esto puede traducirse en beneficios económicos, mejoras en sus vidas o posibles consecuencias negativas, y por lo tanto, su participación durante el desarrollo del software es fundamental.

Si bien el cliente y los usuarios finales suelen ser las principales voces escuchadas para definir los requerimientos del sistema, es vital considerar la voz de todos los stakeholders. Esto asegura una visión completa y equilibrada de las necesidades y expectativas del proyecto.

De ahí que el analista funcional tenga la difícil tarea de armonizar los intereses, muchas veces contrapuestos, de los diferentes stakeholders.

Su objetivo primordial será entonces, lograr un consenso y garantizar que el producto final satisfaga los objetivos del negocio.

LOS REQUERIMIENTOS DEL SISTEMA

No hay Analisis Funcional sin el concepto de requerimiento del sistema, por ello hablemos un poco más del tema.

Un requerimiento es una descripción detallada de lo que el sistema debe hacer o las características que debe tener para satisfacer las necesidades y expectativas de los usuarios y del resto de stakeholders.

Pero los requerimientos de un sistema de software no son todos del mismo tipo, se los clasifican comúnmente en dos grandes categorías: Requerimientos Funcionales y Requerimientos No Funcionales.

Requerimientos Funcionales:

Los requerimientos funcionales describen qué debe hacer el sistema. Se centran en las funcionalidades específicas que el sistema de software debe proporcionar para cumplir con las necesidades de los usuarios y stakeholders.

Estos requerimientos detallan las acciones, comportamientos y respuestas del sistema bajo diversas condiciones, como por ejemplo:

📌 El sistema debe permitir a los usuarios registrar una nueva cuenta.

📌 El sistema debe enviar una confirmación por correo electrónico al completar una compra.

📌 El sistema debe calcular y mostrar el precio total de los artículos en el carrito de compras.

📌 El sistema debe permitir armar un cronograma de auditorías y disparar notificaciones automáticas.

Requerimientos No Funcionales:

Los requerimientos no funcionales describen cómo debe comportarse el sistema. Se centran en los atributos de calidad y las restricciones del sistema, como su rendimiento, seguridad, usabilidad y confiabilidad.

Estos requerimientos no especifican funciones particulares, sino las características que deben cumplirse para que el sistema sea eficiente y satisfactorio para los usuarios, como por ejemplo:

📌 Seguridad: El sistema debe cumplir con los estándares de seguridad ISO27001 para proteger la información confidencial de los usuarios.

📌 Rendimiento: El sistema debe ser capaz de manejar 1000 usuarios concurrentes sin experimentar una degradación significativa en el tiempo de respuesta, manteniendo un tiempo de carga de página promedio inferior a 3 segundos.

📌 Usabilidad: La interfaz de usuario debe ser intuitiva y fácil de usar, siguiendo las mejores prácticas de diseño de experiencia de usuario (UX), con una tasa de satisfacción del usuario superior al 80% en las pruebas de usabilidad.

Documentación de Requerimientos:

Reqerimientos Funcionales: Casos de uso, historias de usuario, especificaciones funcionales, issues, tareas.

Requerimientos No Funcionales: Requisitos de rendimiento, estándares de seguridad, directrices de usabilidad.

Ambos tipos de requerimientos son esenciales para el desarrollo exitoso de un sistema de software, ya que los requerimientos funcionales aseguran que el sistema haga lo que se supone que debe hacer, mientras que los requerimientos no funcionales garantizan que lo haga de manera efectiva y satisfactoria.

ACTIVIDADES CLAVE EN EL ANÁLISIS FUNCIONAL

Las actividades que se llevan adelante durante el Análisis Funcional de requerimientos consisten de una serie de tareas mútuamente entrelazadas, entre las que se encuentran:

Estudio de Factibilidad: Porque no siempre es posible hacer lo que el cliente solicita o es mejor trabajar sobre lo que ya tiene que desarrollar algo de cero.
Adquisición y Análisis de Requerimientos: Descubrir, capturar, clasificar, organizar y negociar los requerimientos.
Especificación de Requerimientos: Documentar los requerimientos en un formato estándar.
Validación de Requerimientos: Comprobar que los requerimientos sean correctos, completos, consistentes, realistas y verificables.

Estudio de Factibilidad:

No siempre lo que tiene en mente el cliente es lo mejor para resolver una necesidad propia.

Ante la solicitud del desarrollo de una solución informática, el analista funcional realiza este estudio para determinar la viabilidad del proyecto.

Este proceso incluye varias actividades clave:

Reuniónes con el Cliente: Para discutir el problema que el cliente quiere resolver y las expectativas que tiene sobre la solución informática y así comprender sus necesidades y objetivos.

Revisión de Documentación y Aplicaciones Existentes: Incluye procedimientos, cualquier especificación previa, informes de auditoría, manuales de sistemas actuales y aplicaciones existentes para identificar posibles integraciones o reutilizaciones de componentes y tener un conocimineto más detallado del negocio del cliente.

Evaluación Técnica: El analista funcional trabaja junto con el equipo técnico para evaluar si el sistema requerido es técnicamente viable. Esto incluye revisar la arquitectura actual, la infraestructura disponible, y las tecnologías necesarias para implementar la solución.

Recomendación: Con base en los hallazgos del estudio, el analista funcional presenta una recomendación al cliente. Esta puede ser, proceder con el desarrollo, realizar ajustes en los requisitos o buscar alternativas más viables, y a partir de allí trabaja con el cliente para delinear un plan de implementación que incluya plazos, recursos necesarios y métricas de éxito.

Adquisición y Análisis de Requerimientos:

Una vez evaluada la factibilidad del proyecto, el analista funcional se reúne con clientes y usuarios finales para descubrir el dominio de aplicación, qué servicios debe proporcionar el sistema, su desempeño requerido, las restricciones de hardware, etcétera.

Es una etapa crucial en donde los analistas funcionales utilizan una variedad de métodos para obtener una comprensión profunda de las necesidades del negocio, entre los que se incluyen:

Entrevistas: Son reuniones individuales con los stakeholders, para discutir sus necesidades, problemas y expectativas. Las entrevistas pueden ser estructuradas (con preguntas específicas) o no estructuradas (más abiertas y flexibles).

Encuestas y Cuestionarios: Son herramientas útiles para recolectar información de un gran número de personas de manera eficiente. Permiten obtener datos cuantitativos y cualitativos que ayudan a formar una imagen clara de las necesidades del negocio.

Talleres: Son sesiones colaborativas donde se reúnen varios stakeholders para discutir y definir los requisitos. Los talleres pueden incluir actividades como brainstorming, análisis de procesos y juegos de roles para identificar problemas y soluciones.

Observación: Los analistas pueden observar cómo los usuarios interactúan con los sistemas actuales para identificar problemas y áreas de mejora. Actividad útil para captar lo que muchas veces no se ve en las entrevistas más formales.

Análisis de Documentos: Revisión, nuevamente, de la documentación existente, como manuales de usuario, procedimientos operativos y reportes anteriores, para entender el contexto y los requisitos previos.

Especificación de Requerimientos:

Una vez recolectados y analizados los requerimientos, el siguiente paso es documentarlos de manera clara y precisa, algo importantísimo.

Los requerimientos del usuario se escriben casi siempre en lenguaje natural, complementado con diagramas y tablas adecuados.

La especificación de requerimientos es fundamental para asegurar que todas las partes interesadas tengan una comprensión común y detallada de lo que se espera del sistema.

Si bien las herramientas utilizadas para documentar requerimientos componen una amplia variedad, me voy a centrar solo en las más usadas:

Casos de Uso: Es una técnica de especificación y documentación utilizada en el desarrollo de software para representar las interacciones entre un sistema y sus usuarios o actores (ya sean personas u otros sistemas).

Estos casos de usos describen las acciones que un usuario realiza en un sistema para alcanzar un objetivo específico y, por lo tanto, ayudan a definir las funcionalidades del sistema.

El propósito principal de los Casos de Uso es capturar y comunicar los requisitos funcionales del sistema de una manera clara y comprensible para todas las partes interesadas, incluidos los desarrolladores, diseñadores y usuarios finales.

Diagrama de casos de uso con StarUML

Historias de Usuario: Son descripciones breves y sencillas (sin usar jerga de software) de una funcionalidad desde la perspectiva del usuario final.

Representan requerimientos de software en un lenguaje comprensible para todas las partes interesadas, incluidos desarrolladores, analistas y clientes.

Cada historia de usuario incluye un contexto, una acción y un resultado esperado. Por ejemplo, "Como usuario, quiero poder restablecer mi contraseña para acceder a mi cuenta si la olvido".

Para convertir Casos de Uso en Historias de Usuario, se debe identificar el objetivo principal del caso de uso y expresarlo en términos de valor para el usuario final.

Es muy importante que la historia de usuario venga acompañada de criterios de aceptación para que sea posible validar la solución informática desarrollada para el requerimiento en consideración.

Historia de usuario, con subtareas asociadas, bajada de Jira

Diagramas de Flujo: Representaciones visuales de los procesos y flujos de trabajo. Ayudan a visualizar los pasos y decisiones en un proceso, facilitando la identificación de posibles mejoras.

FlowChart hecho con Lucidchart

Diagramas de Clase: Utilizados en el diseño de sistemas orientados a objetos, estos diagramas muestran las clases (en POO) del sistema y las relaciones entre ellas.

Documento de Requerimientos de software: El Documento de Requerimientos de Software (DRS) es un documento formal que recoge todos los requerimientos del sistema y los organiza de una manera estandarizada.

Este documento es esencial para guiar el desarrollo del software y asegurar que todas las necesidades del cliente sean cumplidas. De mínima, el DRS incluye:

*Introducción:*	Objetivo del documento. Alcance del sistema. Definiciones, acrónimos y abreviaturas.
*Descripción General:*	Perspectiva y funcionalidades del producto. Características del usuario. Restricciones generales.
*Requerimientos Funcionales:*	Descripción detallada de cada función que debe realizar el sistema.
*Requerimientos No Funcionales:*	Criterios que determinan la calidad y desempeño del sistema. Incluyen rendimiento, seguridad, usabilidad y escalabilidad.
*Criterios de aceptación:*	Definen las condiciones que deben cumplirse para considerar que un requisito se ha cumplido.
*Interfaces de Usuario:*	Descripción de cómo los usuarios interactuarán con el sistema.
*Apéndice:*	En donde se incluye información adicional de soporte, como diagramas, casos de uso o glosario de términos.

Validación y Verificación:

Una vez que los requisitos están documentados, es fundamental validarlos y verificarlos para asegurar que reflejan correctamente las necesidades y expectativas del negocio y los stakeholders.

Este proceso te garantiza en gran medida el éxito del proyecto.

Las actividades de validación y verificación incluyen:

📌 Revisiones con Stakeholders: Realizar reuniones y revisiones formales con los stakeholders para asegurarse de que todos los requerimientos han sido entendidos y aprobados.

Durante estas sesiones, se presentan los documentos de requerimientos, casos de uso, historias de usuario, y cualquier otra documentación relevante para recibir retroalimentación y aprobaciones.

📌 Prototipos y Modelos: Utilizar prototipos y modelos visuales para ilustrar cómo funcionará el sistema. Estos prototipos pueden ser maquetas simples, diagramas de flujo, o modelos interactivos que permitan a los stakeholders visualizar el producto final y hacer ajustes antes de la implementación real.

📌 Aseguramiento de Calidad: Verificar que los requerimientos cumplen con los criterios de calidad definidos, como claridad, consistencia, y viabilidad técnica.

📌 Pruebas de Concepto: Implementar pequeñas pruebas de concepto para verificar la viabilidad técnica de los requerimientos más críticos. Estas pruebas pueden incluir la creación de módulos funcionales del sistema para demostrar que los requerimientos pueden ser cumplidos con la tecnología y recursos disponibles.

📌 Gestión de Cambios: Establecer un proceso formal para gestionar cambios en los requerimientos. Esto incluye registrar todas las solicitudes de cambio, evaluar su impacto, y obtener aprobaciones antes de realizar modificaciones. Mantener un registro detallado de todos los cambios aprobados para asegurar la trazabilidad y coherencia del proyecto.

📌 Comunicación Continua: Mantener una comunicación continua con todos los stakeholders durante todo el proceso de validación para asegurar que cualquier cambio o ajuste en los requerimientos sea claramente comunicado y entendido por todos.

La validación de requerimientos es una actividad iterativa que puede necesitar varias rondas de revisión y ajuste.

El objetivo es asegurar que, antes de avanzar a las fases de diseño y desarrollo, todos los requerimientos sean correctos, completos y aprobados por todas las partes interesadas.

Una validación minuciosa ayuda a evitar costosos retrabajos y garantiza que el proyecto cumpla con las expectativas y necesidades del negocio.

METODOLOGÍAS ÁGILES DE DESARROLLO DE SOFTWARE: EL ENFOQUE SCRUM

En el desarrollo de software, la metodología que elija una organización puede marcar una gran diferencia en eficiencia y calidad del producto final.

Aunque existen varias metodologías disponibles, en esta sección te contaré resumidamente de las metodologías ágiles, en particular Scrum, quien se ha ganado una gran popularidad por su capacidad de adaptarse rápidamente a las necesidades cambiantes del mercado y los usuarios.

¿Qué son las Metodologías Ágiles?

Las metodologías ágiles surgieron como una respuesta a las limitaciones de los enfoques tradicionales, como el Waterfall o Cascada.

En lugar de seguir un proceso lineal que llevaría meses o años para ver un producto terminado, las metodologías ágiles se basan en ciclos iterativos y colaborativos, donde se prioriza la entrega continua de valor, con lo cual, los equipos ágiles trabajan en entregas pequeñas y frecuentes que permiten realizar ajustes basados en la retroalimentación constante de los stakeholders.

El Marco de Trabajo SCRUM

Entre las metodologías ágiles, Scrum posiblemente sea la más utilizada, y en este punto, si bien no es mi intención explayarme demasiado, sí quiero trasnferirte los conceptos esenciales que me enseñaron a mí.

Scrum, más que una metodología es un marco de trabajo que estructura el proceso de desarrollo en ciclos cortos llamados sprints, que suelen durar entre una y cuatro semanas.

Al final de cada sprint, el equipo presenta un incremento del producto, una entrega parcial, que puede ser revisado y evaluado por los stakeholders.

Uno de los principios fundamentales de Scrum es la autogestión del equipo.

El equipo Scrum es multifuncional, lo que significa que incluye a todas las personas necesarias para completar el trabajo, desde programadores hasta analistas funcionales, diseñadores, testers y líderes de proyecto.

Esto fomenta la colaboración y la comunicación dentro del equipo, lo que es crucial para el hallazgo de las mejores soluciones y, consecuentemente, para el éxito de un proyecto ágil.

Marco de trabajo ágil SCRUM: principales conceptos

Los Roles en SCRUM

En Scrum, los roles son claramente definidos para asegurar que todos en el equipo comprendan sus responsabilidades.

A continuación, se describen los roles principales y cómo el analista funcional encaja dentro de este contexto:

Product Owner: Es el responsable de maximizar el valor del producto. Define y prioriza el backlog del producto, que es la lista de características y tareas que deberían realizarse. El Product Owner se asegura de que los desarrolladores trabajen en las funcionalidades que aportan mayor valor al negocio, y en esta tarea, puede apoyarse en el analista funcional para clarificar los requisitos y asegurar que estén alineados con las necesidades del usuario

Scrum Master: Es el responsable de gestionar, mentorizar, facilitar y fomentar el valor de la agilidad dentro del equipo Scrum. Su tarea principal es asegurar que Scrum se implemente correctamente, eliminando impedimentos que puedan afectar el progreso del equipo. Aunque el Scrum Master no se involucra directamente en la definición de los requisitos, el analista funcional puede colaborar con él para asegurar que cualquier impedimento relacionado con la interpretación de requisitos sea resuelto rápidamente. El SM NO es un project manager.

Desarrolladores: Antiguamente se hablaba de equipo de desarrolladores, pero hoy esta concepción está cambiando por la de, desarrolladores, a secas, ya que no es correcto considerar un equipo dentro de otro equipo. Aclarado ese punto, los desarrolladores son los responsables de construir el producto. En un entorno ágil, el grupo de desarrolladores es multifuncional y se organiza para entregar incrementos de software funcionales al final de cada sprint. Aquí, el analista funcional puede trabajar junto a ellos para asegurar que los requisitos están claros y son comprendidos de manera uniforme por todos los miembros del equipo. El analista funcional puede participar en la elaboración de las historias de usuario, proporcionando contexto adicional y aclarando cualquier duda técnica o funcional que surja durante el desarrollo.

Como se vio, el rol del analista funcional no está formalmente definido dentro del marco de trabajo Scrum, pero éste puede desempeñar un papel crucial en la facilitación de la comunicación entre el Product Owner, los desarrolladores y los stakeholders.

El Ciclo de Trabajo en SCRUM

Cada sprint en Scrum comienza con una Sprint Planning, donde se define qué trabajo se realizará durante el sprint y cómo se llevará a cabo.

Durante el sprint, el equipo se reúne diariamente en una breve reunión llamada Daily Scrum para revisar el progreso y ajustar el plan según sea necesario.

Al final del sprint, se lleva a cabo una Sprint Review donde se presenta el incremento del producto a los stakeholders, seguido por una Sprint Retrospective, que permite al equipo reflexionar sobre el proceso y áreas a mejorar para el próximo sprint.

El analista funcional tiene participación activa en todas esas actividades, denominadas ceremonias del SCRUM.

Adaptabilidad y Respuesta al Cambio

Una de las mayores fortalezas de Scrum es su capacidad para adaptarse a los cambios.

En lugar de seguir un plan rígido, Scrum permite que los equipos ajusten sus prioridades según la retroalimentación recibida.

Esto es particularmente útil en entornos dinámicos donde los requisitos pueden evolucionar rápidamente.

EL PEFIL DEL ANALISTA FUNCIONAL

Las habilidades y conocimientos básicos que debería tener alguien que se iniciara en esta actividad, deberían ser:

✅ Comunicación efectiva: Capacidad para interactuar con stakeholders, recoger requisitos, negociar y transmitir información de manera clara y concisa.

✅ Pensamiento analítico: Habilidad para entender y analizar procesos empresariales y traducirlos en requisitos técnicos.

✅ Conocimientos básicos de IT: Comprensión general de tecnologías de la información y conceptos de desarrollo de software.

✅ Documentación: Capacidad para redactar documentos claros y detallados, como casos de uso e historias de usuario.

✅ Gestión del tiempo: Habilidad para gestionar múltiples tareas, para priorizar y cumplir con los plazos.

✅ Trabajo en equipo: Capacidad para colaborar efectivamente con desarrolladores, testers y otros miembros del equipo.

✅ Resolución de problemas: Habilidad para identificar y solucionar problemas durante el análisis de requisitos y desarrollo del proyecto.

✅ Conocimientos de metodologías ágiles: Familiaridad con frameworks ágiles, especialmente Scrum, y capacidad para adaptarse a entornos de trabajo flexibles y cambiantes.

✅ Manejo de herramientas informáticas: Competencia en el uso de herramientas comúnmente utilizadas en proyectos ágiles, como JIRA, Trello, Asana (software de Gestión de Proyectos), y Lucidchart, Microsoft Visio, StarUML, Visual Paradigm (software de diagramación), Figma, Marvel (software de prototipado)

REFLEXIÓN FINAL: EL ANALISIS FUNCIONAL Y LEAN SIX SIGMA

No sé desde qué formación has leído este post, pero si vienes del mundo fabril, habituado con conceptos de Mejora Continua, de Lean Six Sigma, quizás como un Ingeniero de Procesos de la industria, probablemente hayas notado muchas similitudes con el Análisis Funcional.

Ambos comparten principios fundamentales, como la importancia de entender los procesos a través de un mapeo intensivo (Value Stream Mapping), enfocarse en la mejora continua mediante iteraciones (kaizen), la dinámica de los equipos de implementación y el concepto de entregas parciales, similar al flujo continuo de lotes cada vez más pequeños de Lean Manufacturing.

Al igual que en Lean Six Sigma, un buen Análisis Funcional se centra en comprender y mejorar los procesos para cumplir con los objetivos del negocio, convirtiéndose en una pieza esencial para el éxito de los proyectos de TI.

La integración de estos enfoques puede llevar a soluciones más eficientes y alineadas con las necesidades del cliente y del negocio.

Bueno, eso fue todo, al menos por ahora. Espero sinceramente haberte aportado valor con este artículo. Si has llegado hasta aquí, te lo agradezco de corazón.

Este artículo es el resultado de un excelente curso de 120 hs recientemente completado e impartido por SilverTech, sobre el Analisis Funcional en el desarrollo de software.

Quiero expresar mi más sincero reconocimiento y gratitud a la organización SilverTech, un sitio altamente recomendable para personas +50 que desean explorar nuevos caminos en el mundo laboral actual.

Y además, un especial agradecimiento a los docentes Norma Adriana Lopez Ifill, Gabriel Guevara y Giselle Gioffre por la impecable formación y el valioso conocimiento que me han brindado.

¿Tienes dudas, preguntas, otros puntos de vista o sugerencias sobre temas que te gustaría ver en el blog?

No dudes en dejar un comentario. Escribo con el propósito de ayudar y disfrutar del proceso, pero también para mejorar y aprender de tus opiniones.

Si deseas saber más sobre mí, te invito a visitar mi perfil en LinkedIn.

¡Que tengas una excelente semana y hasta pronto!

ANÁLISIS FUNCIONAL: EL PUENTE ENTRE LAS IDEAS Y EL SOFTWARE REAL

UNA INTRODUCCIÓN AL ANALISIS FUNCIONAL, CLAVE EN EL DESARROLLO DE SOFTWARE DE CALIDAD

POR QUÉ EL ANALISIS FUNCIONAL SE VOLVIÓ TAN IMPORTANTE

¿QUÉ ES EL ANÁLISIS FUNCIONAL?

¿QUIÉNES SON LOS STAKEHOLDERS?