Gestión del Cambio en Requerimientos y Control de Líneas Base

📌 En síntesis: Control del cambio inevitable: proceso de solicitud de cambio (RFC), evaluación de impacto técnico y financiero, y congelamiento de líneas base.

Guía técnica desarrollada por el equipo de Proyecto Luna para formación profesional y consulta técnica abierta.

📌

📌 Aprendizaje esperado

📌

Reconocer las metodologías y herramientas ágiles de desarrollo de software en la consecución del alcance del proyecto. Especiﬁcación de requerimientos

Especiﬁcación de requerimientos El desarrollo de software es un proceso complejo que requiere una estructura y un enfoque organizativo para ser exitoso. A lo largo de la historia de la ingeniería de software, han surgido diversas metodologías o modelos de desarrollo que actúan como marcos de trabajo para planiﬁcar, ejecutar y controlar los proyectos. Estas metodologías buscan proporcionar disciplina, eﬁciencia y calidad al proceso de creación de software. Tradicionalmente, los modelos de desarrollo se basaban en un enfoque secuencial y predictivo (como el modelo en Cascada), donde cada fase se completaba antes de pasar a la siguiente y los requerimientos se ﬁjaban al inicio. Sin embargo, la naturaleza cambiante de los requerimientos, la incertidumbre en los proyectos y la necesidad de entregas rápidas llevaron al surgimiento de un paradigma diferente: las metodologías ágiles. Las metodologías ágiles priorizan la ﬂexibilidad, la colaboración y la entrega continua de valor, adaptándose a los cambios en lugar de seguir un plan rígido. Aunque comparten principios comunes, cada metodología ágil tiene sus propias características, roles, eventos y artefactos, lo que las hace más adecuadas para ciertos tipos de proyectos y contextos. En esta clase, exploraremos algunas de las metodologías ágiles más prominentes y cómo cada una aborda la consecución y gestión del alcance del proyecto de software.

🚀 Introducción

Figura 1: Valores fundamentales del maniﬁesto ágil

Especiﬁcación de requerimientos El movimiento ágil nació formalmente en 2001 con la publicación del Maniﬁesto para el Desarrollo Ágil de Software. Este maniﬁesto estableció un conjunto de valores y principios que guían las metodologías ágiles, en contraste con los enfoques más tradicionales y conservadores. Los cuatro valores fundamentales del maniﬁesto ágil son los siguientes:

🧠 ¿Qué es el alcance de un proyecto de software?

Individuos e interacciones sobre procesos y herramientas (se valora más la comunicación y la colaboración humana que la rigidez de los procesos o la soﬁsticación de las herramientas). Software funcionando sobre documentación exhaustiva (el objetivo principal es entregar valor a través de software funcional, no solo documentos y planes). Colaboración con el cliente sobre negociación contractual (el cliente se involucra activamente en el proceso, permitiendo una adaptación continua a sus necesidades). Respuesta al cambio sobre seguir un plan (se reconoce que los requerimientos pueden cambiar, y se busca la adaptabilidad en lugar de apegarse rígidamente a un plan inicial).

Tabla 1. Características clave RUP Fuente: OpenAI (2023) Aunque RUP a menudo se considera un puente entre las metodologías tradicionales y las ágiles, su naturaleza iterativa e incremental lo acerca al enfoque ágil en muchos aspectos. RUP es un marco de proceso de desarrollo de software conﬁgurable que proporciona un enfoque disciplinado para asignar tareas y responsabilidades dentro de una organización de desarrollo. RUP se basa en tres características clave, que se detallan en la Tabla 1.

🛠️ Proceso Uniﬁcado de Desarrollo (Rational Uniﬁed

📌 Process - RUP)

Especiﬁcación de requerimientos Características Descripción Dirigido por casos de uso Los casos de uso, herramienta para capturar y modelar los requisitos de un sistema basado en el estándar UML, son la base para deﬁnir la funcionalidad del sistema y guían todo el proceso. Centrado en la arquitectura Se presta gran atención a la creación de una arquitectura robusta y evolutiva. Iterativo e Incremental El desarrollo se realiza en ciclos cortos (iteraciones) que producen versiones incrementales del software.

🔹 Características y enfoque en el alcance

RUP, al ser iterativo, permite cierta ﬂexibilidad en el alcance, especialmente en las iteraciones de la fase de construcción. Los requerimientos pueden ser reﬁnados o priorizados en cada iteración. Sin embargo, su formalidad inherente con sus fases y artefactos detallados, lo hace más adecuado para proyectos donde se necesita un nivel considerable de documentación y gestión de riesgos, y donde el alcance, aunque puede evolucionar, tiene una base más estructurada desde las fases iniciales. La gestión del alcance se apoya en los casos de uso para deﬁnir la funcionalidad y en la trazabilidad a lo largo del proceso.

Figura 2: Fases de RUP

🔹 Fases de RUP

RUP organiza el proceso en cuatro fases secuenciales, cada una con un objetivo principal y varios hitos. Especiﬁcación de requerimientos Fases de RUP Inicio (Inception)

Se deﬁne el alcance del sistema y se crea una visión de alto nivel.
Se identiﬁcan los casos de uso principales y se evalúa la viabilidad del proyecto.
Se obtiene la aprobación de los stakeholders para continuar. Enfoque en el alcance: establecer el alcance del producto a un alto nivel y asegurar la viabilidad. Elaboración (Elaboration)
Se reﬁna la visión y se detallan los casos de uso más críticos.
Se establece la arquitectura base del sistema.
Se crea un plan de proyecto más detallado para las iteraciones posteriores. Enfoque en el alcance: detallar los requerimientos críticos y establecer la línea base del alcance del proyecto a un nivel más granular. Construcción (Construction)
Es la fase más larga, donde se produce la mayor parte del código.
El desarrollo se realiza en iteraciones, cada una produciendo un incremento ejecutable.
Se realizan pruebas continuas. Enfoque en el alcance: implementar los requerimientos deﬁnidos en las iteraciones, gestionando los cambios al alcance a través de un proceso de control. Transición (Transition)
El software se entrega a los usuarios ﬁnales.
Se realizan pruebas de aceptación del usuario y se entrena a los usuarios.
Se migran datos y se despliega el sistema en producción. Enfoque en el alcance: validar que el producto ﬁnal cumple con el alcance acordado y obtener la aceptación formal.

Tabla 2. Valores XP Fuente: OpenAI (2023) Programación Extrema (XP) es una metodología ágil que se centra en entregar software de alta calidad rápidamente y con frecuencia. XP enfatiza la ﬂexibilidad y la respuesta a los cambios en los requerimientos. Es una metodología centrada en el equipo de desarrollo y en prácticas técnicas sólidas. 3.1. Valores y principios de XP XP se basa en cinco valores clave.

📌 Programación Extrema (Extreme Programming - XP)

Especiﬁcación de requerimientos Valores Descripción Comunicación Fomenta la comunicación constante y directa entre todos los miembros del equipo y directamente con el cliente. Simplicidad Se enfoca en hacer la cosa más simple posible, que funcione para el problema actual, evitando complejidad innecesaria. Retroalimentación La retroalimentación constante del cliente y del equipo ayuda a ajustar el curso del proyecto. Coraje Implica tener el valor de tomar decisiones difíciles, como refactorizar el código o descartar funcionalidades. Respeto Mutuo respeto entre los miembros del equipo y hacia el cliente.

3.2. Prácticas clave de XP y el alcance XP implementa estos valores a través de un conjunto de prácticas especíﬁcas, muchas de las cuales impactan directamente la gestión del alcance:

Juegos de planiﬁcación: el cliente deﬁne las “historias de usuario” (requerimientos) en forma de tarjetas, y el equipo estima su esfuerzo. Esto deﬁne el alcance del incremento a desarrollar.
Historias de usuario: requerimientos escritos desde la perspectiva del usuario, de forma concisa y enfocada en el valor. Son la principal forma de deﬁnir el alcance del producto.
Entregas pequeñas y frecuentes: el software se entrega en incrementos muy cortos (con intervalos de pocas semanas), lo que permite una retroalimentación temprana y ajustes constantes del alcance.
Cliente en el sitio (On-site Customer): un representante real del cliente forma parte del equipo de desarrollo, disponible para responder preguntas y clariﬁcar requerimientos diariamente. Esto asegura que el alcance se alinee con las necesidades del negocio de forma continua.
Pruebas de aceptación: el cliente deﬁne las pruebas para cada historia de usuario, lo que ayuda a clariﬁcar los criterios de aceptación del alcance.
Refactorización: mejora continua del diseño del código para mantenerlo simple y ﬂexible, lo que facilita la adaptación a cambios en el alcance.
Desarrollo Dirigido por Pruebas (TDD): escribir pruebas antes del código, lo que ayuda a clariﬁcar el comportamiento deseado y los límites del alcance de una funcionalidad. Enfoque en el alcance en XP XP no deﬁne un alcance ﬁjo al inicio, sino que permite que el alcance evolucione y se reﬁne iteración a iteración mediante las historias de usuario y la retroalimentación constante del cliente. La gestión del alcance es altamente ﬂexible y adaptativa, ideal para proyectos donde los requerimientos son volátiles o no están claros al principio. La claridad del alcance se busca a través de la comunicación directa y las pruebas de aceptación. Especiﬁcación de requerimientos

Tabla 3. Ejemplo de Historia de Usuario en XP Fuente: elaboración propia Ejemplo de Historia de Usuario (XP) En el marco de las metodologías ágiles, las historias de usuario son una herramienta clave para capturar requerimientos desde la perspectiva del usuario. En XP, estas historias se utilizan para priorizar, planiﬁcar y desarrollar funcionalidades dentro de iteraciones o Sprints. A continuación, se presenta un ejemplo práctico adaptado al caso de la aplicación TaskMaster: Especiﬁcación de requerimientos ID HU-001 Título Registro de nueva tarea Como Usuario de la aplicación TaskMaster Quiero Poder crear una tarea con título, descripción, fecha límite y prioridad Para Organizar mis actividades y dar seguimiento a mis compromisos Criterios de aceptación - El formulario debe permitir ingresar título, descripción, fecha y prioridad. - La tarea debe guardarse en el tablero Kanban en la columna “Pendiente”. - El sistema debe conﬁrmar con un mensaje que la tarea fue creada correctamente.

Scrum es el marco de trabajo ágil más popular y ampliamente adoptado. Se basa en el Maniﬁesto Ágil y proporciona una estructura para el desarrollo de productos complejos a través de un enfoque iterativo e incremental. Scrum se enfoca en la colaboración, la autoorganización de los equipos y la entrega de valor en ciclos cortos.

🔹 Roles en Scrum

Scrum deﬁne tres roles principales, cada uno con responsabilidades claras:

📌 Scrum

Especiﬁcación de requerimientos Product Owner (propietario del producto) Es el responsable de maximizar el valor del producto resultante del trabajo del equipo de desarrollo. Gestiona el Product Backlog (la lista de todo lo que el producto necesita), priorizando los elementos para optimizar el valor. Es la voz del cliente y los stakeholders. Scrum Master Responsable de asegurar que Scrum se entienda y se aplique. Facilita el proceso, elimina impedimentos para el equipo y entrena al equipo y a la organización en los principios ágiles. Development Team (equipo de desarrollo) Un equipo autoorganizado y multifuncional que es responsable de entregar un incremento de producto “hecho” al ﬁnal de cada Sprint. No hay subequipos ni jerarquías dentro del equipo de desarrollo.

🔹 Eventos (ceremonias) en Scrum

Scrum deﬁne una serie de eventos (o ceremonias) con un tiempo ﬁjo (time-boxed) para facilitar la comunicación y la inspección y adaptación:

Sprint: el corazón de Scrum. Es una iteración de duración ﬁja (normalmente de 1 a 4 semanas) durante la cual se crea un incremento de producto “hecho”, utilizable y potencialmente entregable. El alcance del Sprint se ﬁja una vez que el Sprint ha comenzado.
Sprint Planning (planiﬁcación del Sprint): al inicio de cada Sprint, el equipo selecciona elementos del Product Backlog para incluir en el Sprint, deﬁniendo el Sprint Backlog (el alcance del Sprint) y planiﬁcando cómo construirá el incremento.
Entregas pequeñas y frecuentes: el software se entrega en incrementos muy cortos (con intervalos de pocas semanas), lo que permite una retroalimentación temprana y ajustes constantes del alcance.
Daily Scrum (Scrum diario): una reunión diaria de 15 minutos para el equipo de desarrollo, donde sincronizan actividades y planiﬁcan el trabajo para las próximas 24 horas, inspeccionando el progreso hacia el objetivo del Sprint.
Sprint Review (Revisión del Sprint): al ﬁnal del Sprint, el equipo y los stakeholders inspeccionan el incremento “hecho”, colaboran en lo que se hizo y qué ha cambiado en el Product Backlog. Se adapta el Product Backlog para el siguiente Sprint. Aquí se valida el alcance del Sprint con el cliente.
Sprint Retrospective (retrospectiva del Sprint): una oportunidad para que el equipo Scrum se inspeccione a sí mismo y cree un plan de mejoras para el siguiente Sprint. Especiﬁcación de requerimientos

Sprint 1 – Duración: 2 semanas Objetivo del Sprint: Entregar una versión funcional inicial que permita a los usuarios registrar y visualizar tareas. Historias de usuario seleccionadas para el Sprint: 1. HU-001 – Registro de nueva tarea 2. HU-002 – Visualización de tareas en tablero Kanban 3. HU-003 – Edición de tarea existente Deﬁnición de “Hecho” (DoD):

Código desarrollado y revisado.

Pruebas unitarias superadas.

Integración en entorno de prueba.

Validación con el Product Owner. Ejemplo de Sprint (Scrum) En Scrum, un Sprint es una iteración con un objetivo especíﬁco que produce un incremento funcional del producto. El siguiente ejemplo muestra cómo podría planiﬁcarse el Sprint 1 de TaskMaster: Especiﬁcación de requerimientos

Enfoque en el alcance en Scrum: la gestión del alcance en Scrum es altamente adaptativa. El Product Backlog es la representación del alcance del producto y es una “lista viva” que puede cambiar constantemente en función de la retroalimentación del mercado y del cliente. Sin embargo, el alcance de un Sprint (Sprint Backlog) está ﬁjado una vez que el Sprint comienza. Los cambios al alcance global son gestionados por el Product Owner a través de la priorización del Product Backlog, asegurando que se entregue el mayor valor posible de forma incremental.

Figura 3: Artefactos principales para representar el trabajo y el valor

🔹 Artefactos de Scrum y la gestión del alcance

Scrum utiliza tres artefactos principales para representar el trabajo y el valor: Product Backlog: una lista ordenada de todo lo que se sabe que se necesita para el producto. Contiene los requerimientos (historias de usuario, características, errores, mejoras) que deﬁnen el alcance del producto. Es dinámico, evolutivo y es responsabilidad del Product Owner. Sprint Backlog: el conjunto de elementos del Product Backlog seleccionados para el Sprint, más el plan para entregar el incremento y conseguir el objetivo del Sprint. Representa el alcance del Sprint. Incremento: el producto “hecho” (usable y potencialmente entregable) resultante del Sprint, más los incrementos de todos los Sprints anteriores. Representa el alcance acumulado del producto. Especiﬁcación de requerimientos

Tabla 4. Principios de Kanban Fuente: OpenAI (2023) Kanban es una metodología ágil que se enfoca en la visualización del trabajo, la limitación del trabajo en progreso (WIP) y la maximización del ﬂujo. A diferencia de Scrum, Kanban no prescribe roles ni eventos ﬁjos, lo que lo hace muy ﬂexible y adaptable a casi cualquier proceso existente. Es ideal para proyectos con ﬂujos de trabajo continuos o donde los requerimientos llegan de forma impredecible.

🔹 Principios de Kanban

Kanban se basa en cuatro principios fundamentales:

🔹 Prácticas de Kanban y la visualización del alcance

Kanban utiliza varias prácticas clave para gestionar el ﬂujo de trabajo y, por extensión, el alcance, las que se detallan a continuación:

📌 Kanban

Especiﬁcación de requerimientos Principios Descripción Empezar con lo que haces ahora No requiere un cambio radical. Se aplica sobre el proceso existente. Acordar buscar cambios incrementales y evolutivos Fomenta la mejora continua sin grandes disrupciones. Respetar los roles, responsabilidades y títulos actuales No impone nuevos roles; se adapta a la estructura organizativa existente. Fomentar actos de liderazgo en todos los niveles Anima a todos a contribuir a la mejora del sistema.

Visualizar el ﬂujo de trabajo: el elemento central es el tablero Kanban, que muestra las etapas del ﬂujo de trabajo (ej. “Pendiente”, “En Desarrollo”, “En Prueba”, “Hecho”). Cada tarjeta en el tablero representa un elemento de trabajo o un requerimiento. Esta visualización hace que el alcance sea transparente y visible para todos.
Limitar el trabajo en progreso (WIP): establecer límites al número de elementos que pueden estar en cada etapa del ﬂujo de trabajo. Esto ayuda a enfocar al equipo, reducir el cambio de contexto y terminar el trabajo antes de empezar otro. Los límites WIP impactan indirectamente el alcance, al forzar la ﬁnalización de elementos antes de tomar nuevos.
Gestionar el ﬂujo: monitorear y mejorar cómo el trabajo se mueve a través del sistema, buscando eventos complejos que detengan el trabajo y optimizando el tiempo de ciclo.
Hacer las políticas explícitas: deﬁnir y hacer visibles las reglas para cada etapa del ﬂujo de trabajo y para mover elementos entre etapas.
Implementar bucles de retroalimentación: aunque no tiene ceremonias ﬁjas como Scrum, Kanban fomenta reuniones regulares (ej. revisión de ﬂujo, revisión de entrega de servicios) para inspeccionar y adaptar.
Mejorar colaborativamente, experimentar (utilizando modelos y el método cientíﬁco): fomenta la mejora continua, basada en datos y experimentación. Enfoque en el alcance en Kanban: la gestión del alcance en Kanban es inherentemente continua y “justo a tiempo”. El Product Backlog (implícito o explícito) es la fuente de requerimientos, pero no hay Sprints con un alcance ﬁjo. Los elementos son disponibilizados al sistema de forma continua a medida que la capacidad lo permite y las prioridades cambian. El tablero Kanban hace que el estado del alcance sea altamente visible, permitiendo a los stakeholders ver el progreso y priorizar el trabajo de manera ﬂuida. Es ideal para equipos que manejan una corriente constante de trabajo o mantenimiento, donde el ﬂujo es más importante que los ciclos de tiempo ﬁjos. Especiﬁcación de requerimientos

Figura 4. Ejemplo Tablero Kanban (Fuente: elaboración propia)

Ejemplo de Tablero Kanban (TaskMaster) Kanban permite visualizar el ﬂujo de trabajo y el estado de cada elemento, facilitando la gestión del alcance en proyectos con ﬂujo continuo. Un tablero típico para TaskMaster podría verse de la siguiente manera: Especiﬁcación de requerimientos

Tabla 5. Comparativa y elección de metodologías ágiles Fuente: OpenAI (2023) La elección de una metodología ágil depende en gran medida del tipo de proyecto a ejecutar, los requerimientos especíﬁcos de los interesados y las características del equipo y la organización.

🔍 Comparativa y elección de metodologías ágiles para

📌 la gestión del alcance

Especiﬁcación de requerimientos Característica clave Proceso Uniﬁcado (RUP) Programación Extrema (XP) Scrum Kanban Enfoque principal Proceso estructurado, iterativo, centrado en la arquitectura. Prácticas de ingeniería de software, mejora continua. Marco de trabajo para desarrollo incremental. Visualización del ﬂujo, limitación WIP, mejora continua. Gestión del alcance Iterativo, pero con más formalidad. Alcance global deﬁnido en fases tempranas, detallado en elaboración. Control de cambios. Evolutivo, basado en historias de usuario, entregas frecuentes. Cliente en el sitio para ajuste continuo. Adaptativo. Product Backlog dinámico. Alcance del Sprint ﬁjo. Priorización por Product Owner. Continua, “Justo a Tiempo”. Flujo constante de ítems, priorización ﬂexible. Cadencia Iteraciones (Sprints) que varían en duración y contenido según la fase. Entregas muy frecuentes (semanas). Sprints de duración ﬁja (1-4 semanas). Flujo continuo, sin cadencia ﬁja (basado en demanda). Roles Múltiples roles detallados (analista, diseñador, desarrollador, Tester, etc.). Equipo pequeño y autoorganizado. Cliente en el sitio. Product Owner, Scrum Master, equipo de desarrollo. Roles no prescritos, se adapta a los existentes. Ideal para proyectos Grandes, complejos, con cierta necesidad de formalidad y documentación. Pequeños- medianos, con requerimientos muy cambiantes y fuerte interacción con el cliente. Complejos, donde el valor se entrega en incrementos regulares, y el equipo necesita autoorganización. Con ﬂujos de trabajo continuos, soporte, mantenimiento, o donde el trabajo llega de

Para identiﬁcar el tipo de metodología según los requerimientos de los interesados y el tipo de proyecto:

Si los requerimientos son muy volátiles e inciertos, y se necesita retroalimentación muy frecuente del cliente para aﬁnar el producto: XP o Scrum son excelentes opciones.
Si se requiere una estructura más formal y documentación a lo largo del ciclo de vida, pero aún con ﬂexibilidad y adaptabilidad: RUP podría ser considerado.
Si el proyecto implica un ﬂujo continuo de trabajo, mantenimiento o soporte, o los requerimientos llegan de forma asíncrona: Kanban es muy efectivo.
Si el cliente puede involucrarse directamente y dedicar tiempo al equipo: XP y Scrum se beneﬁcian enormemente.
Si la complejidad técnica es alta y la arquitectura es crítica: RUP y XP (con sus prácticas de ingeniería) ofrecen un buen soporte.
Si el equipo es pequeño y altamente colaborativo: XP puede ser muy potente. La elección no siempre es exclusiva; muchas organizaciones adoptan enfoques híbridos, combinando elementos de diferentes metodologías para crear un proceso que se ajuste mejor a sus necesidades especíﬁcas. Lo importante es que la metodología elegida facilite la consecución y gestión efectiva del alcance del proyecto, entregando valor continuamente a los stakeholders. Especiﬁcación de requerimientos

Las metodologías ágiles han revolucionado la forma en que se desarrollan los proyectos de software, ofreciendo una alternativa ﬂexible y adaptativa a los enfoques tradicionales. Procesos como RUP, XP, Scrum y Kanban, aunque distintos en su implementación, comparten los valores del Maniﬁesto Ágil, priorizando los individuos, el software funcionando, la colaboración con el cliente y la respuesta al cambio. Comprender las particularidades de cada una de estas metodologías es crucial para el ingeniero de software. La elección adecuada de un marco de trabajo no solo optimiza los procesos internos del equipo, sino que también impacta directamente en cómo se deﬁne, gestiona y persigue el alcance del proyecto. Al poder identiﬁcar distintos tipos de metodologías y asociarlas al tipo de proyecto a ejecutar, los profesionales pueden maximizar la entrega de valor, minimizar riesgos y asegurar que el producto ﬁnal cumpla verdaderamente con las expectativas de los interesados. La agilidad en la gestión del alcance no signiﬁca la ausencia de planiﬁcación, sino la capacidad de adaptarse y evolucionar el plan en función del aprendizaje continuo y la retroalimentación.

💡 Conclusión

Especiﬁcación de requerimientos

Agile Manifesto. (2001). Manifesto for Agile Software Development. https://agilemanifesto.org/ Anderson, D. J. (2010). Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press. Beck, K. (1999). Extreme Programming Explained: Embrace Change. Addison-Wesley. Larman, C. (2004). Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd ed.). Prentice Hall. PMI. (2021). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) (7th ed.). Project Management Institute. Schwaber, K. y Sutherland, J. (2020). The Scrum Guide. Scrum.org. https://scrumguides.org/ Sommerville, I. (2011). Ingeniería del Software (9na ed.). Pearson Educación. https://elibro.net/es/lc/santotomas/titulos/37857

🚀 Potencia tus proyectos tecnológicos con Proyecto Luna

En Proyecto Luna desarrollamos arquitectura de software de alto rendimiento, optimización de bases de datos críticas y soluciones aplicadas de inteligencia artificial y automatización para empresas y profesionales.

💼 Soluciones de ingeniería: Conoce nuestras capacidades y casos de estudio en proyectoluna.com/work/.
🛡️ Seguridad y auditoría: Orientación técnica y respuesta ante incidentes en ¿Te han hackeado?.
📩 Contacto directo: Escríbenos a través de nuestro formulario de contacto o a contacto@proyectoluna.com.

📚 Fuentes y lecturas recomendadas

Especiﬁcación de requerimientos

Diagrama explicativo