📌 En síntesis: Gestión del alcance del proyecto: resolución de conflictos de interesados, priorización con MoSCoW (Must, Should, Could, Won
Guía técnica desarrollada por el equipo de Proyecto Luna para formación profesional y consulta técnica abierta.
📌
📌 Aprendizaje esperado
📌
Analizar casos de uso en proyectos acotados, categorizando roles principales y relacionándolos con los objetivos del proyecto. Especificación de requerimientos
Especificación de requerimientos La Ingeniería de Requerimientos es fundamental para cualquier proyecto de software exitoso. Es aquí donde entendemos las necesidades del usuario y definimos qué debe hacer el sistema. Si los requerimientos no son claros, es muy probable que el proyecto tenga problemas, como costos más altos o retrasos, y que el producto final no sea lo que el cliente esperaba. Una vez que hemos hablado con los usuarios y analizado sus necesidades, el siguiente paso es documentar estos requerimientos de manera estructurada. Esto se conoce como modelado de requerimientos, que nos ayuda a crear representaciones claras de lo que el software hará. Estas representaciones nos permiten comprender mejor el problema, comunicarnos de forma efectiva con todos los involucrados, y verificar que estamos construyendo lo correcto. Son la base para que los arquitectos diseñen el sistema y los encargados de las pruebas sepan qué validar. A continuación, nos centraremos en los Casos de uso, una técnica de modelado muy utilizada, basada en el estándar UML (Unified Modeling Languaje). Los casos de uso describen lo que el sistema hace desde la perspectiva de sus usuarios externos. Para usar bien esta técnica, primero necesitamos entender quiénes son los “actores” que interactuarán con el sistema. Luego, definiremos los casos de uso mismos, es decir las funcionalidades, detallando cómo son sus interacciones, qué condiciones deben cumplirse antes y después, y cómo el sistema maneja diferentes situaciones, tanto las que salen de manera exitosa como las que no.
🚀 Introducción
Especificación de requerimientos El modelado de requerimientos es el proceso de crear representaciones abstractas de los requerimientos de un sistema. Estas representaciones (modelos) nos ayudan a comprender, comunicar, analizar y validar los requisitos. Son una forma estructurada de organizar y visualizar la información obtenida de los stakeholders, permitiendo identificar funcionalidades, interacciones y dependencias. Entre las diversas técnicas de modelado, el enfoque orientado a casos de uso es uno de los más populares y efectivos, especialmente para sistemas interactivos. Este enfoque se centra en describir lo que un sistema hace desde la perspectiva de sus usuarios externos. Nos permite comprender el sistema desde la perspectiva de cómo interactúan las personas (o sistemas) con él para lograr un objetivo específico.
🧠 ¿Qué es el modelado de requerimientos?
🛠️ El enfoque orientado a casos de uso
Especificación de requerimientos Para entender cómo un sistema se comporta, primero debemos entender quién o qué interactúa con él. Aquí es donde entra el concepto de actor. 3.1. Definición de actor En el contexto de los casos de uso, un actor es una entidad externa al sistema que interactúa con él para lograr un objetivo o para recibir algún valor de este. Los tipos de actores identificables son los que se detallan a continuación: Es fundamental entender que un actor representa un rol y no una persona o entidad específica. Por ejemplo, “cliente” es un rol; Juan Pérez puede ser un cliente, pero el actor es el “cliente”.
🛠️ Actores en el desarrollo de software
Figura 1: ¿Quién puede ser un actor?
Un actor Puede ser Una persona (un rol que desempeña un usuario, no una persona específica). Otro sistema de software (cuando nuestro sistema interactúa con otro sistema externo). Un dispositivo de hardware (cuando el sistema interactúa con un dispositivo específico, como un sensor o una impresora).
Especificación de requerimientos 3.2. Importancia de identificar actores Identificar correctamente a los actores es el primer paso y uno de los más importantes en el modelado de casos de uso porque:
-
Ayuda a delimitar el alcance del sistema: ¿quién usará el sistema y para qué?
-
Permite comprender las perspectivas de los diferentes usuarios o sistemas con los que interactúa el software.
-
Es la base para identificar los casos de uso (las funcionalidades que el sistema debe proveer para esos actores). 3.3. Tipos de actores Los actores se pueden clasificar según su rol principal en relación con el sistema. Esta clasificación nos ayuda a entender sus motivaciones y cómo esperan interactuar. 3.3.1. Actores principales (primarios) Un actor principal (también conocido como primario) es aquel que inicia un caso de uso para lograr un objetivo de valor de negocio con el sistema. Son los usuarios directos del sistema que obtienen un resultado observable del caso de uso. Sus principales características son:
-
Siempre inicia la interacción con el sistema.
-
Tiene un objetivo que el sistema le ayuda a lograr.
-
Recibe un valor directamente del caso de uso. Especificación de requerimientos 3.3.2. Actores secundarios (soporte) Un actor secundario (o de soporte) es aquel que participa en un caso de uso, pero no lo inicia. Usualmente, proporcionan un servicio o información al sistema o reciben información de él para completar el objetivo del actor principal. Son aquellos que el sistema necesita para completar el caso de uso, pero no son el iniciador. Sus principales características son:
-
Nunca inicia el caso de uso.
-
Proporciona servicios al sistema (ej. base de datos, sistema de pago).
-
Puede recibir información necesaria para su funcionamiento (ej. una impresora recibe datos para imprimir). Ejemplos:
-
En un sistema de biblioteca: “lector” (inicia el préstamo de un libro).
-
En un sistema de banca online: “cliente” (inicia una transferencia bancaria).
-
En un sistema de e-commerce: “comprador” (inicia la compra de un producto). Ejemplos:
-
En un sistema de biblioteca: “sistema de gestión de inventario” (proporciona información sobre la disponibilidad del libro).
-
En un sistema de banca online: “pasarela de pagos externa” (procesa la transacción monetaria).
-
En un sistema de e-commerce: “sistema de correos” (recibe la solicitud de envío).
-
“Administrador de sistema” (mantiene el sistema, pero no inicia las operaciones de negocio primarias).
Especificación de requerimientos 3.4. Ejemplos de actores (tabla comparativa) En la Tabla 1 se destacan ejemplos de actores para distintos proyectos o sistemas. Tabla 1. Ejemplos de tipos de Actores para diversos Proyectos Fuente: OpenAI (2023) Proyecto / sistema Sistema de cajero automático Plataforma educativa online Sistema de gestión hospitalaria Cliente Estudiante, profesor Médico, enfermera, recepcionista Banco central, sistema de seguridad, dispensador de efectivo Sistema de pagos, servidor de correo electrónico Laboratorio externo, sistema de farmacia, impresora Actor principal (inicia interacción, busca valor) Actor secundario (interactúa, proporciona servicio/información)
Especificación de requerimientos Una vez que hemos identificado a los actores, el siguiente paso es definir los casos de uso. 4.1. Definición y propósito de un caso de uso Un caso de uso describe una secuencia de acciones realizadas por el sistema para producir un resultado observable de valor para un actor específico. En otras palabras, es una descripción de una funcionalidad del sistema desde la perspectiva de cómo un usuario (actor) interactúa con él para lograr un objetivo, basado en los requerimientos funcionales levantados previamente. Propósito:
-
Capturar los requerimientos funcionales del sistema de una manera comprensible para stakeholders técnicos y no técnicos.
-
Definir los límites y el alcance del sistema.
-
Servir como base para la planificación de pruebas (casos de prueba).
-
Facilitar la comunicación entre los stakeholders y el equipo de desarrollo. 4.2. Diagrama de casos de uso Un diagrama de casos de uso es una herramienta de modelado UML (Lenguaje Unificado de Modelado) que permite describir funcionalidades del sistema desde la perspectiva del usuario (actor). Es utilizado principalmente en la etapa de análisis de requerimientos para identificar qué hace el sistema y cómo interactúan los usuarios o sistemas externos con él.
⚙️ Casos de uso: describiendo la interacción del sistema
Especificación de requerimientos Tabla 2. Componentes principales del diagrama de caso de uso. Fuente: OpenAI (2023) Elemento Símbolo Descripción Actor
Figura de palo Representa a una persona, sistema u organización que interactúa con el sistema. No necesariamente debe ser un usuario humano. Caso de uso Óvalo Describe una funcionalidad específica o una tarea significativa que el sistema debe realizar para un actor, escrita en verbo infinitivo como Definir, Crear, Registrar, etc. Sistema (Límites) Rectángulo Encierra todos los casos de uso. Representa el sistema que se está modelando. Todo lo que está dentro pertenece al sistema; lo de afuera, no. Asociación de comunicación Línea sólida Indica la interacción entre un actor y un caso de uso. Puede ser unidireccional o bidireccional.
Figura 2: Símbolos diagrama de casos de uso
Actor Límite de un sistema Caso de uso Asociación de comunicación Extensión <
4.3. Componentes clave plantilla de casos de uso Aunque no existe un estándar único para la plantilla de descripción de un caso de uso, la mayoría incluyen elementos comunes que proporcionan una descripción completa y detallada de la interacción. En la Tabla 3 se detallan los elementos más comunes. Especificación de requerimientos Tabla 3. Elementos comunes de los casos de uso Fuente: OpenAI (2023) Elementos Descripción Verbo en infinitivo + Objeto (ej. “registrar usuario”). Nombre del caso de uso Quién inicia el caso de uso. Actor(es) principal(es) Otros que interactúan. Actores secundarios Un resumen de una o dos frases del propósito del caso de uso. Descripción breve Condiciones que deben ser verdaderas antes de que el caso de uso pueda comenzar. Precondiciones La secuencia de pasos normales para completar el caso de uso. Flujo básico (o flujo principal de éxito): Describen cómo el sistema reacciona a variaciones o errores durante el flujo básico. Flujos alternativos / excepciones El estado del sistema después de que el caso de uso se ha completado con éxito (o ha fallado). Postcondiciones
Especificación de requerimientos
🛠️ Elementos fundamentales de un caso de uso
Profundicemos en los componentes más críticos de la descripción de un caso de uso. 5.1. Flujo básico (flujo principal o flujo de éxito) El flujo básico describe la secuencia “ideal” o más común de interacciones entre el actor principal y el sistema para lograr el objetivo del caso de uso. Es el camino adecuado y correcto donde todo funciona como se espera, sin errores ni variaciones. Se describe paso a paso, alternando entre las acciones del actor y las respuestas del sistema.
- Características: o Secuencia lineal de pasos. o Representa la interacción exitosa y más frecuente. o No incluye errores o condiciones excepcionales. Ejemplo caso de uso: “realizar pago en línea”.
Figura 3: Ejemplo caso de uso: “realizar pago en línea”.
1 2 3 4 5 6 7 8 9 El cliente selecciona los productos en el carrito de compras. El cliente hace clic en “proceder al pago”. El sistema muestra las opciones de pago. El sistema valida los datos de la tarjeta. El sistema envía los datos a la pasarela de pagos externa. La pasarela de pagos externa aprueba la transacción. El cliente selecciona “tarjeta de crédito” e ingresa los datos requeridos. El sistema envía un correo electrónico de confirmación al cliente. El sistema confirma el pago al cliente y genera un número de pedido.
Especificación de requerimientos 5.2. Escenarios de éxito y fallo Un escenario es una instancia específica de un caso de uso. Es una ejecución particular del caso de uso, siguiendo una ruta determinada a través de sus flujos. Un caso de uso es una plantilla general, mientras que un escenario es una historia concreta 5.2.1. Escenarios de éxito Un escenario de éxito es una instancia del flujo básico en el cual todas las condiciones se cumplen y el actor logra su objetivo sin ningún problema. Es una “historia exitosa” de una interacción completa y correcta. 5.2.2. Escenarios de fallo (flujos alternativos y excepciones) Los escenarios de fallo (o flujos alternativos / excepciones) describen rutas menos comunes o situaciones en las cuales el flujo básico no se cumple. En la Figura 4 se detallan los escenarios. Ejemplo escenario de éxito para “realizar pago en línea” o El cliente X selecciona 3 productos y procede al pago. o Selecciona “tarjeta de crédito”, ingresa una tarjeta VISA válida y hace clic en pagar. o El sistema valida los datos, la pasarela de pagos aprueba la transacción, el sistema confirma el pago (pedido #12345) y el cliente recibe el email de confirmación.
Especificación de requerimientos A continuación, destacamos un ejemplo de escenario de fallo/alternativo para realizar un pago en línea.
Figura 4: Escenarios de fallo
Figura 5: Ejemplo escenario de fallo/alternativo para “realizar pago en línea”
Los escenarios de fallo Pueden ser Flujos alternativos: describen caminos alternativos que aún resultan en un éxito del objetivo del caso de uso, pero de una manera diferente al flujo básico. Por ejemplo, pagar con PayPal en lugar de tarjeta de crédito. Excepciones: describen situaciones de error o condiciones anormales que impiden que el objetivo del caso de uso se complete con éxito. Conducen a un fallo del caso de uso. Ejemplo escenario de fallo/alternativo para “realizar pago en línea”
-
(Desde paso 4 del flujo básico) el cliente selecciona “tarjeta de débito”.
-
El sistema redirige al cliente a la página de su banco para autenticación.
-
El cliente completa la autenticación en el banco.
-
El banco autoriza la transacción.
-
(Continúa en el paso 7 del flujo básico).
-
(Desde paso 6 del flujo básico) la pasarela de pagos externa rechaza la transacción.
-
El sistema muestra un mensaje de error al cliente: “pago rechazado. por favor, verifique sus datos o intente con otro método de pago”.
-
El cliente puede intentar nuevamente o cancelar la operación. Flujo alternativo: pago con tarjeta de débito Excepción: tarjeta de crédito rechazada
Especificación de requerimientos El siguiente diagrama de caso de uso es un ejemplo de una transacción en el Sistema de Pago en Línea: 5.3. Precondición Una precondición es una condición que debe ser verdadera y verificable antes de que un caso de uso pueda comenzar. Si una precondición no se cumple, el caso de uso no puede iniciarse. Características:
-
Definen los requisitos de entrada para el caso de uso.
-
Son externas al control del caso de uso (el caso de uso no las establece, solo las asume).
-
Generalmente se refieren al estado del sistema o del actor.
Figura 6: Diagrama de caso de uso “realizar pago en línea”
Cliente Sistema de pago en línea Realizar pago en línea Extends Extends Pago realizado con tarjeta de débito Pago rechazado
Especificación de requerimientos 5.4. Postcondición Una postcondición es una condición que debe ser verdadera y verificable después de que un caso de uso se ha completado con éxito. Describe el estado final del sistema y los datos después de una ejecución exitosa del caso de uso. También se pueden especificar postcondiciones para escenarios de fallo, describiendo el estado después de un fallo específico. Características:
-
Describen el resultado observable del caso de uso.
-
Indican los cambios en el estado del sistema o de los datos. Ejemplo caso de uso: “iniciar sesión en el sistema”
-
Precondición: el usuario tiene una cuenta registrada en el sistema.
-
Precondición: el sistema está operativo y accesible. Ejemplo caso de uso: “realizar pago en línea”
-
Precondición: el carrito de compras del cliente contiene al menos un producto.
-
Precondición: el cliente ha iniciado sesión en el sistema (o ha proporcionado sus datos como invitado).
Especificación de requerimientos 5.5. Reglas de negocio Si bien no son un componente directo del flujo de un caso de uso, las reglas de negocio son declaraciones que definen o restringen algún aspecto del negocio. A menudo, influyen en los flujos (básicos y alternativos) y en las pre/postcondiciones de los casos de uso. Por ejemplo, “un cliente no puede pedir más de 10 unidades de un mismo producto en una sola compra” es una regla de negocio que afectaría el flujo de “realizar compra”. Ejemplo caso de uso: “iniciar sesión en el sistema”
-
Postcondición (éxito): el usuario está autenticado y tiene acceso al sistema.
-
Postcondición (fallo por credenciales incorrectas): el usuario no está autenticado y un mensaje de error se ha mostrado. Ejemplo caso de uso: “realizar pago en línea”
-
Postcondición (éxito): el pedido ha sido registrado como “pagado” en el sistema.
-
Postcondición (éxito): el stock de los productos comprados ha sido actualizado.
-
Postcondición (éxito): se ha enviado una confirmación de pedido al cliente. Hemos recorrido un camino fundamental en la de Especificación de Requerimientos, adentrándonos en el modelado de sistemas a través de los actores y los casos de uso. Hemos enfatizado la importancia crítica de estas herramientas para transformar necesidades abstractas en descripciones concretas y accionables para el equipo de desarrollo. Comprendimos que los actores no son solo “usuarios”, sino roles que representan a cualquier entidad (persona, sistema, dispositivo) que interactúa con nuestro software, ya sea iniciando una función (actor principal) o colaborando en su ejecución (actor secundario). Identificar y clasificar correctamente a estos actores es el primer paso vital para delimitar el alcance del proyecto y entender las perspectivas de quienes usarán el sistema. Los casos de uso, por su parte, se revelan como descripciones poderosas de las funcionalidades del sistema, narradas desde la perspectiva del objetivo del actor. Hemos desglosado su estructura, comprendiendo la vitalidad de elementos como:
-
El flujo básico, que nos guía por el “camino feliz” de la interacción.
-
Las precondiciones, que aseguran que el sistema esté en el estado correcto antes de una operación.
-
Las postcondiciones, que definen el estado final deseado tras una ejecución exitosa.
-
Los escenarios de éxito y fallo (flujos alternativos y excepciones), que nos obligan a pensar más allá de lo ideal, anticipando errores y desviaciones, y garantizando la robustez y resiliencia del software.
💡 Conclusión
Especificación de requerimientos
Sommerville, I. (2011). Ingeniería del Software (9ª ed.). Pearson Educación. OpenAI. (2023). ChatGPT (versión GPT-4) [Modelo de lenguaje]. https://chat.openai.com Pressman, R. S., y Maxim, B. R. (2020). Ingeniería del Software: Un Enfoque Práctico (9ª ed.). McGraw-Hill Education.
🚀 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
- Especificación de requerimientos
