![\"\"](\"https:\/\/www.cybermedian.com\/wp-content\/uploads\/2026\/09\/img_6aba3b59771b3.png\")
<\/p>\nUna descripci\u00f3n de caso de uso explica c\u00f3mo un actor logra un objetivo interactuando con un sistema. Complementa un diagrama de casos de uso:<\/p>\n
<\/p>\n
Diagrama de casos de uso:<\/strong> Muestra actores, alcance del sistema y relaciones.<\/p>\n<\/li>\n Descripci\u00f3n de caso de uso:<\/strong> Explica el comportamiento detallado, condiciones, reglas y resultados.<\/p>\n<\/li>\n<\/ul>\n Un diagrama proporciona el mapa; la descripci\u00f3n proporciona la ruta.<\/p>\n Un caso de uso representa un objetivo valioso que un actor externo logra a trav\u00e9s de un sistema.<\/p>\n Ejemplos:<\/p>\n El cliente realiza un pedido<\/p>\n<\/li>\n El empleado presenta una reclamaci\u00f3n de gastos<\/p>\n<\/li>\n El paciente agenda una cita<\/p>\n<\/li>\n El administrador crea una cuenta de usuario<\/p>\n<\/li>\n El cliente restablece una contrase\u00f1a<\/p>\n<\/li>\n<\/ul>\n Un buen caso de uso es:<\/p>\n Orientado a objetivos<\/p>\n<\/li>\n Valioso para un actor<\/p>\n<\/li>\n Descrito desde la perspectiva del usuario<\/p>\n<\/li>\n Independiente de dise\u00f1os de pantalla espec\u00edficos<\/p>\n<\/li>\n Centrado en el comportamiento observable del sistema<\/p>\n<\/li>\n<\/ul>\n Utilice una frase corta verbo-sustantivo como Presentar reclamaci\u00f3n de gastos<\/strong>, Rastrear env\u00edo<\/strong>, o Aprobar solicitud de pr\u00e9stamo<\/strong>.<\/p>\n Un actor es un rol externo que interact\u00faa con el sistema.<\/p>\n Un actor puede ser:<\/p>\n Una persona<\/p>\n<\/li>\n Una organizaci\u00f3n<\/p>\n<\/li>\n Otro sistema de software<\/p>\n<\/li>\n Un dispositivo de hardware<\/p>\n<\/li>\n Un disparador programado o basado en el tiempo<\/p>\n<\/li>\n<\/ul>\n Ejemplos:<\/p>\n Cliente<\/p>\n<\/li>\n Agente de soporte<\/p>\n<\/li>\n Auxiliar de almac\u00e9n<\/p>\n<\/li>\n Pasarela de pago<\/p>\n<\/li>\n Servicio de correo electr\u00f3nico<\/p>\n<\/li>\n Administrador<\/p>\n<\/li>\n<\/ul>\n Un actor es un rol<\/strong>, no necesariamente un individuo espec\u00edfico. Por ejemplo, \u201cCliente\u201d suele ser mejor que \u201cJane Smith\u201d.<\/p>\n El actor principal<\/strong> inicia el caso de uso para lograr un objetivo.<\/p>\n El actor de apoyo<\/strong> asiste al sistema durante la ejecuci\u00f3n.<\/p>\n Ejemplo:<\/p>\n Actor principal: Cliente<\/p>\n<\/li>\n Actor de apoyo: Pasarela de pago<\/p>\n<\/li>\n Caso de uso: Realizar pedido<\/p>\n<\/li>\n<\/ul>\n El cliente inicia el pedido, mientras que la pasarela de pago autoriza el pago.<\/p>\n El l\u00edmite del sistema define qu\u00e9 est\u00e1 dentro del sistema que se est\u00e1 modelando.<\/p>\n Para una tienda en l\u00ednea, el l\u00edmite podr\u00eda incluir:<\/p>\n Navegar por los productos<\/p>\n<\/li>\n A\u00f1adir producto al carrito<\/p>\n<\/li>\n Realizar pedido<\/p>\n<\/li>\n Realizar pago<\/p>\n<\/li>\n Rastrear pedido<\/p>\n<\/li>\n<\/ul>\n Los siguientes est\u00e1n fuera del l\u00edmite:<\/p>\n Cliente<\/p>\n<\/li>\n Pasarela de pago<\/p>\n<\/li>\n Empresa de entrega<\/p>\n<\/li>\n Proveedor de correo electr\u00f3nico<\/p>\n<\/li>\n<\/ul>\n El l\u00edmite evita la confusi\u00f3n sobre la responsabilidad del sistema.<\/p>\n Un caso de uso debe describir una interacci\u00f3n completa que produzca un resultado significativo.<\/p>\n Por ejemplo:<\/p>\n Realizar pedido:<\/strong>Un cliente selecciona productos, proporciona informaci\u00f3n de entrega, paga por el pedido y recibe una confirmaci\u00f3n del pedido.<\/p>\n<\/blockquote>\n \u00abValidar n\u00famero de tarjeta de cr\u00e9dito\u00bb podr\u00eda ser una funci\u00f3n del sistema, pero generalmente es demasiado peque\u00f1a para ser un objetivo de usuario independiente. En cambio, podr\u00eda ser parte de Realizar pedido<\/strong> o Realizar pago<\/strong>.<\/p>\n Una precondici\u00f3n establece lo que debe ser cierto antes de que comience el caso de uso.<\/p>\n Ejemplos:<\/p>\n El cliente tiene una cuenta activa.<\/p>\n<\/li>\n El producto est\u00e1 disponible para la venta.<\/p>\n<\/li>\n El empleado est\u00e1 autenticado.<\/p>\n<\/li>\n La cita est\u00e1 programada.<\/p>\n<\/li>\n El carrito de compras contiene al menos un art\u00edculo.<\/p>\n<\/li>\n<\/ul>\n Una precondici\u00f3n no es una acci\u00f3n realizada por el caso de uso.<\/p>\n Precondici\u00f3n deficiente:<\/p>\n El cliente inicia sesi\u00f3n.<\/p>\n<\/blockquote>\n Precondici\u00f3n mejorada:<\/p>\n El cliente est\u00e1 autenticado.<\/p>\n<\/blockquote>\n Una poscondici\u00f3n establece lo que es cierto despu\u00e9s de que finaliza el caso de uso.<\/p>\n Ejemplos:<\/p>\n El pedido est\u00e1 registrado.<\/p>\n<\/li>\n El pago est\u00e1 autorizado.<\/p>\n<\/li>\n Se env\u00eda un correo electr\u00f3nico de confirmaci\u00f3n.<\/p>\n<\/li>\n La reclamaci\u00f3n de gastos tiene un estado de presentada.<\/p>\n<\/li>\n La cuenta de usuario est\u00e1 marcada como activa.<\/p>\n<\/li>\n<\/ul>\n Las postcondiciones deben describir resultados, no detalles de implementaci\u00f3n.<\/p>\n Postcondici\u00f3n deficiente:<\/p>\n La Postcondici\u00f3n mejorada:<\/p>\n El pedido se almacena y est\u00e1 disponible para su cumplimiento.<\/p>\n<\/blockquote>\n El escenario principal de \u00e9xito, tambi\u00e9n llamado el flujo b\u00e1sico<\/strong> o camino feliz<\/strong>, describe la interacci\u00f3n normal exitosa.<\/p>\n Cada paso debe describir:<\/p>\n Una interacci\u00f3n entre el actor y el sistema<\/p>\n<\/li>\n Una respuesta del sistema<\/p>\n<\/li>\n Una acci\u00f3n empresarial significativa<\/p>\n<\/li>\n<\/ol>\n Ejemplo:<\/p>\n El cliente selecciona productos.<\/p>\n<\/li>\n El sistema muestra el carrito actual.<\/p>\n<\/li>\n El cliente ingresa la informaci\u00f3n de entrega.<\/p>\n<\/li>\n El sistema valida la informaci\u00f3n de entrega.<\/p>\n<\/li>\n El cliente env\u00eda el pedido.<\/p>\n<\/li>\n El sistema solicita la autorizaci\u00f3n del pago.<\/p>\n<\/li>\n La pasarela de pagos autoriza el pago.<\/p>\n<\/li>\n El sistema registra el pedido.<\/p>\n<\/li>\n El sistema muestra la confirmaci\u00f3n del pedido.<\/p>\n<\/li>\n<\/ol>\n Evite detalles espec\u00edficos de la interfaz a menos que sean esenciales para el requisito.<\/p>\n Paso deficiente:<\/p>\n El cliente hace clic en el bot\u00f3n azul en la esquina inferior derecha.<\/p>\n<\/blockquote>\n Paso mejorado:<\/p>\n El cliente env\u00eda el pedido.<\/p>\n<\/blockquote>\n Un flujo alternativo describe una variaci\u00f3n v\u00e1lida del escenario principal.<\/p>\n Ejemplos:<\/p>\n El cliente elige la recogida en tienda en lugar de la entrega.<\/p>\n<\/li>\n El cliente paga con un m\u00e9todo de pago guardado.<\/p>\n<\/li>\n El administrador aprueba una reclamaci\u00f3n con condiciones.<\/p>\n<\/li>\n El usuario se autentica utilizando un c\u00f3digo de un solo uso.<\/p>\n<\/li>\n<\/ul>\n Los flujos alternativos pueden volver a unirse al flujo principal.<\/p>\n Ejemplo:<\/p>\n A1. El cliente utiliza un m\u00e9todo de pago guardado<\/strong> Un flujo de excepci\u00f3n describe una condici\u00f3n no exitosa o anormal.<\/p>\n Ejemplos:<\/p>\n El pago es rechazado.<\/p>\n<\/li>\n El producto est\u00e1 agotado.<\/p>\n<\/li>\n La autenticaci\u00f3n falla.<\/p>\n<\/li>\n El servicio externo no est\u00e1 disponible.<\/p>\n<\/li>\n Los datos requeridos son inv\u00e1lidos.<\/p>\n<\/li>\n<\/ul>\n Un flujo de excepci\u00f3n debe explicar:<\/p>\n D\u00f3nde ocurre el problema<\/p>\n<\/li>\n Qu\u00e9 hace el sistema<\/p>\n<\/li>\n Qu\u00e9 ve el actor<\/p>\n<\/li>\n Si el caso de uso termina o se reanuda<\/p>\n<\/li>\n<\/ul>\n Ejemplo:<\/p>\n E1. El pago es rechazado<\/strong> Usar Ejemplo:<\/p>\n Realizar Pedido incluye Calcular Total<\/p>\n<\/li>\n Realizar Pedido incluye Autenticar Cliente<\/p>\n<\/li>\n Retirar Efectivo incluye Verificar PIN<\/p>\n<\/li>\n<\/ul>\n El comportamiento incluido es obligatorio.<\/p>\n Usar Ejemplo:<\/p>\n Realizar Pedido puede ser extendido por Aplicar C\u00f3digo de Descuento<\/p>\n<\/li>\n Finalizar Compra puede ser extendido por Agregar Mensaje de Regalo<\/p>\n<\/li>\n<\/ul>\n El comportamiento extendido no siempre se ejecuta.<\/p>\n Una regla \u00fatil:<\/p>\n Incluir:<\/strong> \u201cEsto siempre ocurre como parte del caso de uso.\u201d<\/p>\n<\/li>\n Extender:<\/strong> \u201cEsto puede ocurrir bajo ciertas condiciones.\u201d<\/p>\n<\/li>\n<\/ul>\n No use La generalizaci\u00f3n representa la herencia entre actores o casos de uso.<\/p>\n Ejemplo:<\/p>\n Empleado es un actor general.<\/p>\n<\/li>\n Gerente es un actor especializado que hereda el comportamiento del Empleado.<\/p>\n<\/li>\n<\/ul>\n Utilice la generalizaci\u00f3n cuando el elemento especializado sea genuinamente un tipo del elemento generalizado, no simplemente porque dos elementos compartan algunos pasos.<\/p>\n La siguiente plantilla funciona bien para documentos de requisitos, especificaciones de proyectos y modelos de an\u00e1lisis.<\/p>\n Objetivo:<\/strong> Alcance:<\/strong> Nivel:<\/strong> Actor principal:<\/strong> Actores de apoyo:<\/strong><\/p>\n Pasarela de pago<\/p>\n<\/li>\n Servicio de inventario<\/p>\n<\/li>\n Servicio de correo electr\u00f3nico<\/p>\n<\/li>\n Servicio de entrega<\/p>\n<\/li>\n<\/ul>\n Partes interesadas e intereses:<\/strong><\/p>\n Cliente:<\/strong> Desea comprar productos con \u00e9xito y recibir confirmaci\u00f3n.<\/p>\n<\/li>\n Tienda:<\/strong> Desea registrar un pedido v\u00e1lido y cobrar el pago.<\/p>\n<\/li>\n Almac\u00e9n:<\/strong> Necesita informaci\u00f3n precisa de cumplimiento.<\/p>\n<\/li>\n Pasarela de pago:<\/strong> Necesita una solicitud de pago v\u00e1lida.<\/p>\n<\/li>\n Servicio de entrega:<\/strong> Necesita una direcci\u00f3n de entrega completa.<\/p>\n<\/li>\n<\/ul>\n Disparador:<\/strong> Precondiciones:<\/strong><\/p>\n El cliente tiene al menos un art\u00edculo en el carrito.<\/p>\n<\/li>\n Los productos est\u00e1n disponibles para pedir.<\/p>\n<\/li>\n El cliente proporciona una direcci\u00f3n de entrega v\u00e1lida.<\/p>\n<\/li>\n El sistema puede comunicarse con el servicio de pago.<\/p>\n<\/li>\n<\/ul>\n Garant\u00edas m\u00ednimas:<\/strong><\/p>\n Ning\u00fan pedido sin pagar se considera confirmado.<\/p>\n<\/li>\n El cliente es informado si el pedido no puede completarse.<\/p>\n<\/li>\n El inventario reservado se libera si el pago falla.<\/p>\n<\/li>\n<\/ul>\n Garant\u00edas de \u00e9xito:<\/strong><\/p>\n El pago est\u00e1 autorizado.<\/p>\n<\/li>\n El pedido se registra.<\/p>\n<\/li>\n El inventario se reserva.<\/p>\n<\/li>\n El cliente recibe una confirmaci\u00f3n.<\/p>\n<\/li>\n La informaci\u00f3n de cumplimiento est\u00e1 disponible para el almac\u00e9n.<\/p>\n<\/li>\n<\/ul>\n El cliente revisa el carrito de compras.<\/p>\n<\/li>\n El sistema muestra los productos, cantidades, precios, impuestos, costo de env\u00edo y total.<\/p>\n<\/li>\n El cliente proporciona la informaci\u00f3n de entrega.<\/p>\n<\/li>\n El sistema valida la informaci\u00f3n de entrega.<\/p>\n<\/li>\n El cliente selecciona un m\u00e9todo de pago.<\/p>\n<\/li>\n El cliente env\u00eda el pedido.<\/p>\n<\/li>\n El sistema verifica la disponibilidad del producto.<\/p>\n<\/li>\n El sistema solicita la autorizaci\u00f3n del pago a la Pasarela de Pago.<\/p>\n<\/li>\n La Pasarela de Pago autoriza el pago.<\/p>\n<\/li>\n El sistema crea el pedido.<\/p>\n<\/li>\n El sistema reserva los productos pedidos.<\/p>\n<\/li>\n El sistema env\u00eda una confirmaci\u00f3n del pedido al cliente.<\/p>\n<\/li>\n El sistema muestra el n\u00famero de pedido y la fecha estimada de entrega.<\/p>\n<\/li>\n<\/ol>\n A1. El cliente utiliza una direcci\u00f3n guardada<\/strong><\/p>\n En el Paso 3, el cliente selecciona una direcci\u00f3n previamente guardada. El sistema muestra la direcci\u00f3n y contin\u00faa en el Paso 4.<\/p>\n A2. El cliente utiliza un m\u00e9todo de pago guardado<\/strong><\/p>\n En el Paso 5, el cliente selecciona un m\u00e9todo de pago guardado. El sistema utiliza ese m\u00e9todo y contin\u00faa en el Paso 6.<\/p>\n A3. El cliente elige la recogida en tienda<\/strong><\/p>\n En el Paso 3, el cliente elige la recogida en tienda en lugar de la entrega. El sistema muestra las tiendas disponibles y las fechas de recogida, luego contin\u00faa en el Paso 5.<\/p>\n E1. Producto no disponible<\/strong><\/p>\n En el Paso 7, el sistema determina que un producto no est\u00e1 disponible. El sistema identifica el producto no disponible, actualiza el carrito y solicita al cliente que revise el pedido.<\/p>\n E2. El pago es rechazado<\/strong><\/p>\n En el Paso 9, la Pasarela de Pagos rechaza el pago. El sistema no confirma el pedido, libera las reservas de inventario, muestra el mensaje de error y permite al cliente seleccionar otro m\u00e9todo de pago.<\/p>\n E3. La Pasarela de Pagos no est\u00e1 disponible<\/strong><\/p>\n En el Paso 8, la Pasarela de Pagos no responde dentro del tiempo de espera configurado. El sistema marca el intento de pago como pendiente, informa al cliente y evita el env\u00edo duplicado del pedido.<\/p>\n Un pedido debe contener al menos un producto.<\/p>\n<\/li>\n La cantidad del producto debe ser mayor que cero.<\/p>\n<\/li>\n Un producto no puede ser pedido cuando el stock disponible es insuficiente.<\/p>\n<\/li>\n El pago debe ser autorizado antes de que se confirme el pedido.<\/p>\n<\/li>\n Los precios y los impuestos se calculan utilizando las reglas de precios vigentes.<\/p>\n<\/li>\n Un cliente puede cancelar un pedido solo antes de que comience su cumplimiento.<\/p>\n<\/li>\n<\/ul>\n El resumen del pedido debe mostrarse en un plazo de dos segundos bajo carga normal.<\/p>\n<\/li>\n La informaci\u00f3n de pago no debe almacenarse en texto plano.<\/p>\n<\/li>\n Los env\u00edos duplicados no deben crear pedidos duplicados.<\/p>\n<\/li>\n El sistema debe registrar un rastro de auditor\u00eda para los cambios en el estado del pago y del pedido.<\/p>\n<\/li>\n<\/ul>\n Las descripciones de los casos de uso pueden redactarse en diferentes niveles de detalle.<\/p>\n Un caso de uso de resumen describe un proceso comercial amplio.<\/p>\n Ejemplo:<\/p>\n Cumplir el pedido del cliente<\/p>\n<\/blockquote>\n Esto puede incluir:<\/p>\n Recibir el pedido<\/p>\n<\/li>\n Seleccionar productos<\/p>\n<\/li>\n Empaquetar el pedido<\/p>\n<\/li>\n Despachar el pedido<\/p>\n<\/li>\n<\/ul>\n Este es generalmente el nivel m\u00e1s \u00fatil para el an\u00e1lisis de requisitos.<\/p>\n Ejemplo:<\/p>\n Realizar pedido<\/p>\n<\/blockquote>\n Describe un objetivo que un actor principal puede lograr en una sola sesi\u00f3n.<\/p>\n Esto describe un comportamiento del sistema m\u00e1s peque\u00f1o y reutilizable.<\/p>\n Ejemplos:<\/p>\n Calcular el total del pedido<\/p>\n<\/li>\n Validar el pago<\/p>\n<\/li>\n Generar factura<\/p>\n<\/li>\n<\/ul>\n Los casos de uso a nivel de subfunci\u00f3n son \u00fatiles cuando el comportamiento se reutiliza o es t\u00e9cnicamente complejo, pero no deben reemplazar los casos de uso orientados a objetivos del usuario.<\/p>\n Escriba desde la perspectiva del actor:<\/p>\n El cliente env\u00eda un pedido.<\/p>\n<\/blockquote>\n Evite una redacci\u00f3n centrada en la implementaci\u00f3n:<\/p>\n OrderController invoca el servicio de pedidos.<\/p>\n<\/blockquote>\n Lo \u00faltimo pertenece a la documentaci\u00f3n de dise\u00f1o, no a un caso de uso empresarial.<\/p>\n Evite combinar demasiadas acciones:<\/p>\n El cliente introduce los detalles, selecciona el pago, confirma el pedido y recibe un correo electr\u00f3nico.<\/p>\n<\/blockquote>\n Mej\u00f3relo separando la interacci\u00f3n:<\/p>\n El cliente introduce la informaci\u00f3n de entrega.<\/p>\n<\/li>\n El sistema valida la informaci\u00f3n.<\/p>\n<\/li>\n El cliente selecciona un m\u00e9todo de pago.<\/p>\n<\/li>\n El cliente confirma el pedido.<\/p>\n<\/li>\n El sistema env\u00eda una confirmaci\u00f3n.<\/p>\n<\/li>\n<\/ol>\n Un lector deber\u00eda poder determinar si el requisito ha sido implementado.<\/p>\n D\u00e9bil:<\/p>\n El sistema procesa la solicitud.<\/p>\n<\/blockquote>\n M\u00e1s fuerte:<\/p>\n El sistema valida la solicitud, registra la reclamaci\u00f3n, le asigna un n\u00famero de reclamaci\u00f3n y muestra el estado de la presentaci\u00f3n.<\/p>\n<\/blockquote>\n Use:<\/p>\n El cliente proporciona la informaci\u00f3n de entrega.<\/p>\n<\/blockquote>\n En lugar de:<\/p>\n El cliente ingresa la direcci\u00f3n en el cuadro de texto y hace clic en el bot\u00f3n verde Continuar.<\/p>\n<\/blockquote>\n La segunda versi\u00f3n restringe innecesariamente la interfaz.<\/p>\n No llene el flujo b\u00e1sico con todos los errores posibles. Coloque los errores en los flujos de excepci\u00f3n.<\/p>\n Las reglas de negocio a menudo se aplican a m\u00faltiples casos de uso. Mantenerlas separadas evita texto repetido e inconsistente.<\/p>\n Para cada fallo importante, especifique:<\/p>\n Si los datos se guardan<\/p>\n<\/li>\n Si una transacci\u00f3n se revierte<\/p>\n<\/li>\n Si el actor puede reintentar<\/p>\n<\/li>\n Si se notifica a un administrador<\/p>\n<\/li>\n Si el caso de uso termina o se reanuda<\/p>\n<\/li>\n<\/ul>\n Un flujo de trabajo pr\u00e1ctico es:<\/p>\n Identifique el sistema que se est\u00e1 modelando.<\/p>\n<\/li>\n Liste los actores externos.<\/p>\n<\/li>\n Pregunte qu\u00e9 quiere lograr cada actor.<\/p>\n<\/li>\n Convierta cada objetivo en un nombre de caso de uso.<\/p>\n<\/li>\n Defina el l\u00edmite del sistema.<\/p>\n<\/li>\n Escriba el escenario principal de \u00e9xito.<\/p>\n<\/li>\n A\u00f1ada flujos alternativos y de excepci\u00f3n.<\/p>\n<\/li>\n A\u00f1ada reglas de negocio y requisitos especiales.<\/p>\n<\/li>\n Dibuje el diagrama de casos de uso.<\/p>\n<\/li>\n Revise el modelo con las partes interesadas.<\/p>\n<\/li>\n Vincular los casos de uso con los requisitos, las pruebas y los artefactos de dise\u00f1o.<\/p>\n<\/li>\n<\/ol>\n Una pregunta \u00fatil es:<\/p>\n \u00bfQu\u00e9 resultado empresarial necesita este actor del sistema?<\/p>\n<\/blockquote>\n Los elementos m\u00e1s comunes son:<\/p>\n Actor:<\/strong>Rol externo<\/p>\n<\/li>\n Caso de uso:<\/strong> Capacidad del sistema o objetivo del actor<\/p>\n<\/li>\n L\u00edmite del sistema:<\/strong> Alcance del sistema<\/p>\n<\/li>\n Asociaci\u00f3n:<\/strong> El actor participa en un caso de uso<\/p>\n<\/li>\n Incluir:<\/strong> Comportamiento reutilizable requerido<\/p>\n<\/li>\n Extender:<\/strong> Comportamiento opcional o condicional<\/p>\n<\/li>\n Generalizaci\u00f3n:<\/strong> Actor o caso de uso especializado<\/p>\n<\/li>\n<\/ul>\n Un diagrama de casos de uso no debe intentar mostrar:<\/p>\n Cada paso del flujo de trabajo<\/p>\n<\/li>\n Tablas de base de datos<\/p>\n<\/li>\n Atributos de clase<\/p>\n<\/li>\n Reglas de negocio detalladas<\/p>\n<\/li>\n Dise\u00f1os de pantalla<\/p>\n<\/li>\n Algoritmos internos<\/p>\n<\/li>\n<\/ul>\n Esos pertenecen a diagramas de actividad, diagramas de clase, diagramas de secuencia o requisitos escritos.<\/p>\n El siguiente ejemplo modela el Realizar pedido<\/strong> caso de uso y comportamiento relacionado.<\/p>\n1. \u00bfQu\u00e9 es un caso de uso?<\/h2>\n
\n
\n
Nombres de casos de uso deficientes y mejorados<\/h3>\n
\n\n
\n \nNombre deficiente<\/th>\n Nombre mejorado<\/th>\n Raz\u00f3n<\/th>\n<\/tr>\n<\/thead>\n \n Pantalla de inicio de sesi\u00f3n<\/td>\n Autenticar usuario<\/td>\n Describe un objetivo<\/td>\n<\/tr>\n \n Actualizaci\u00f3n de base de datos<\/td>\n Registrar pago<\/td>\n Describe el valor empresarial<\/td>\n<\/tr>\n \n Haga clic en el bot\u00f3n Enviar<\/td>\n Presentar reclamaci\u00f3n de gastos<\/td>\n Evita terminolog\u00eda espec\u00edfica de la interfaz de usuario<\/td>\n<\/tr>\n \n Validar cuenta<\/td>\n Crear cuenta de cliente<\/td>\n Hace que el resultado sea claro<\/td>\n<\/tr>\n \n Procesar pedido<\/td>\n Realizar pedido<\/td>\n Utiliza un objetivo centrado en el actor<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n 2. Conceptos clave<\/h1>\n
2.1 Actores<\/h2>\n
\n
\n
Actores principales y de apoyo<\/h3>\n
\n
2.2 L\u00edmite del sistema<\/h2>\n
\n
\n
2.3 Caso de uso<\/h2>\n
\n
2.4 Precondiciones<\/h2>\n
\n
\n
\n
2.5 Poscondiciones<\/h2>\n
\n
\n
pedidos<\/code> tabla se actualiza.<\/p>\n<\/blockquote>\n\n
2.6 Escenario principal de \u00e9xito<\/h2>\n
\n
\n
\n
\n
2.7 Flujos alternativos<\/h2>\n
\n
\n
\nEn el Paso 6, el cliente selecciona un m\u00e9todo de pago guardado. El sistema solicita autorizaci\u00f3n utilizando ese m\u00e9todo y luego contin\u00faa en el Paso 7.<\/p>\n<\/blockquote>\n2.8 Flujos de excepciones<\/h2>\n
\n
\n
\n
\nEn el Paso 7, la Pasarela de Pago rechaza la transacci\u00f3n. El sistema muestra el motivo, marca el pedido como no pagado y permite al cliente seleccionar otro m\u00e9todo de pago.<\/p>\n<\/blockquote>\n2.9 Relaciones de Incluir y Extender<\/h2>\n
incluir<\/code><\/h3>\nincluir<\/code> cuando un caso de uso siempre invoca otro comportamiento reutilizable.<\/p>\n\n
Realizar Pedido <<include>> Calcular Total\r\n<\/code><\/pre>\nextender<\/code><\/h3>\nextender<\/code> cuando un comportamiento opcional o condicional complementa un caso de uso base.<\/p>\n\n
Aplicar C\u00f3digo de Descuento <<extend>> Realizar Pedido\r\n<\/code><\/pre>\n\n
incluir<\/code> y extender<\/code> simplemente para dividir cada flujo en peque\u00f1as partes. Una descomposici\u00f3n excesiva hace que el modelo sea dif\u00edcil de entender.<\/p>\n2.10 Generalizaci\u00f3n<\/h2>\n
\n
Manager --|> Empleado\r\n<\/code><\/pre>\n3. Plantilla est\u00e1ndar de descripci\u00f3n de caso de uso<\/h1>\n
ID del caso de uso:\r\nNombre del caso de uso:\r\nObjetivo:\r\nAlcance:\r\nNivel:\r\nActor principal:\r\nActores de soporte:\r\nPartes interesadas e intereses:\r\n\r\nDisparador:\r\n\r\nPrecondiciones:\r\n\r\nGarant\u00edas m\u00ednimas:\r\n\r\nGarant\u00edas de \u00e9xito:\r\n\r\nEscenario principal de \u00e9xito:\r\n1.\r\n2.\r\n3.\r\n\r\nFlujos alternativos:\r\nA1.\r\nA2.\r\n\r\nFlujos de excepci\u00f3n:\r\nE1.\r\nE2.\r\n\r\nRequisitos especiales:\r\n- Rendimiento\r\n- Seguridad\r\n- Usabilidad\r\n- Disponibilidad\r\n- Cumplimiento\r\n\r\nReglas de negocio:\r\n\r\nRequisitos de datos:\r\n\r\nFrecuencia y volumen:\r\n\r\nSupuestos:\r\n\r\nPreguntas abiertas:\r\n\r\nCasos de uso relacionados:\r\n<\/code><\/pre>\nExplicaci\u00f3n de los campos<\/h2>\n
\n\n
\n \nCampo<\/th>\n Prop\u00f3sito<\/th>\n<\/tr>\n<\/thead>\n \n ID del caso de uso<\/td>\n Proporciona una referencia estable, como UC-001<\/td>\n<\/tr>\n \n Nombre del caso de uso<\/td>\n Nombra el objetivo del actor<\/td>\n<\/tr>\n \n Objetivo<\/td>\n Resume el resultado empresarial previsto<\/td>\n<\/tr>\n \n Alcance<\/td>\n Identifica el sistema o subsistema<\/td>\n<\/tr>\n \n Nivel<\/td>\n Indica si es un objetivo del usuario, un resumen o una subfunci\u00f3n<\/td>\n<\/tr>\n \n Actor principal<\/td>\n Identifica qui\u00e9n inicia el caso de uso<\/td>\n<\/tr>\n \n Actores de soporte<\/td>\n Lista a los participantes externos<\/td>\n<\/tr>\n \n Partes interesadas e intereses<\/td>\n Captura lo que espera cada parte interesada<\/td>\n<\/tr>\n \n Disparador<\/td>\n Explica qu\u00e9 inicia el caso de uso<\/td>\n<\/tr>\n \n Precondiciones<\/td>\n Define qu\u00e9 debe ser ya verdadero<\/td>\n<\/tr>\n \n Garant\u00edas m\u00ednimas<\/td>\n Describe qu\u00e9 permanece verdadero tras un fallo<\/td>\n<\/tr>\n \n Garant\u00edas de \u00e9xito<\/td>\n Describe los resultados exitosos<\/td>\n<\/tr>\n \n Escenario principal de \u00e9xito<\/td>\n Documenta el flujo normal<\/td>\n<\/tr>\n \n Flujos alternativos<\/td>\n Describe variaciones v\u00e1lidas<\/td>\n<\/tr>\n \n Flujos de excepciones<\/td>\n Describe fallos y recuperaci\u00f3n<\/td>\n<\/tr>\n \n Requisitos especiales<\/td>\n Captura restricciones no funcionales<\/td>\n<\/tr>\n \n Reglas de negocio<\/td>\n Registra pol\u00edticas y reglas del dominio<\/td>\n<\/tr>\n \n Requisitos de datos<\/td>\n Lista la informaci\u00f3n introducida, le\u00edda o producida<\/td>\n<\/tr>\n \n Preguntas abiertas<\/td>\n Rastrea problemas sin resolver<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n 4. Ejemplo: Realizar pedido<\/h1>\n
UC-001 \u2014 Realizar pedido<\/h2>\n
\nPermitir a un cliente comprar uno o m\u00e1s productos.<\/p>\n
\nTienda en l\u00ednea<\/p>\n
\nObjetivo del usuario<\/p>\n
\nCliente<\/p>\n\n
\n
\nEl cliente env\u00eda el carrito de compras para finalizar la compra.<\/p>\n\n
\n
\n
Escenario principal de \u00e9xito<\/h3>\n
\n
Flujos alternativos<\/h3>\n
Flujos de excepciones<\/h3>\n
Reglas de negocio<\/h3>\n
\n
Requisitos especiales<\/h3>\n
\n
5. Niveles de casos de uso<\/h1>\n
Caso de uso a nivel de resumen<\/h2>\n
\n
\n
Caso de uso a nivel de objetivo del usuario<\/h2>\n
\n
Caso de uso a nivel de subfunci\u00f3n<\/h2>\n
\n
6. Redacci\u00f3n de descripciones de casos de uso de alta calidad<\/h1>\n
Utilice un lenguaje centrado en el actor<\/h2>\n
\n
\n
Mantenga cada paso at\u00f3mico<\/h2>\n
\n
\n
Describa el comportamiento observable<\/h2>\n
\n
\n
Evite el dise\u00f1o prematuro de la interfaz de usuario<\/h2>\n
\n
\n
Mantenga el flujo principal exitoso<\/h2>\n
Identifique las reglas de negocio por separado<\/h2>\n
Haga expl\u00edcito el comportamiento de fallo<\/h2>\n
\n
7. De los requisitos a los casos de uso<\/h1>\n
\n
An\u00e1lisis de actor-objetivo<\/h2>\n
\n\n
\n \nActor<\/th>\n Objetivo<\/th>\n Caso de uso candidato<\/th>\n<\/tr>\n<\/thead>\n \n Cliente<\/td>\n Comprar productos<\/td>\n Realizar pedido<\/td>\n<\/tr>\n \n Cliente<\/td>\n Verificar el progreso del env\u00edo<\/td>\n Rastrear pedido<\/td>\n<\/tr>\n \n Agente de soporte<\/td>\n Resolver una queja<\/td>\n Resolver queja<\/td>\n<\/tr>\n \n Auxiliar de almac\u00e9n<\/td>\n Preparar un pedido<\/td>\n Recoger pedido<\/td>\n<\/tr>\n \n Pasarela de pago<\/td>\n Autorizar el pago<\/td>\n Autorizar pago<\/td>\n<\/tr>\n \n Administrador<\/td>\n Controlar el acceso<\/td>\n Gestionar cuentas de usuario<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n \n
8. Notaci\u00f3n del diagrama de casos de uso<\/h1>\n
\n
\n
9. Ejemplo de diagrama PlantUML<\/h1>\n
![\"\"](\"https:\/\/www.cybermedian.com\/wp-content\/uploads\/2026\/09\/img_6aba3bd13facb.png\")
<\/p>\n\n\nPlantUML<\/span>
\n
\n