Levantamiento de requerimientos
"Si le hubieras preguntado a la gente qué quería, habrían dicho caballos más rápidos." — atribuido a Henry Ford.
Pero el problema real era: moverse más rápido. A veces el cliente no sabe expresar lo que necesita. Tu trabajo es descubrirlo.
Qué vas a aprender en este capítulo
El levantamiento de requerimientos es la habilidad más crítica — y más infravalorada — del análisis de sistemas. Un programador puede estar meses construyendo algo perfectamente codificado que no resuelve el problema real. Este capítulo te enseña a hacer las preguntas correctas, a estructurar lo que el cliente te dice, y a documentarlo de forma que tanto el cliente como el programador puedan verificar que están de acuerdo.
2.1 Técnicas de levantamiento
💡 Intuición
Levantamiento de requerimientos es básicamente investigación periodística: hacés preguntas, observás, leés documentos existentes, y armás el cuadro completo. No le creés ciegamente a lo primero que te dicen — porque muchas veces el cliente sabe qué síntoma tiene, pero no sabe cuál es la enfermedad.
La trampa del síntoma vs la causa:
El dueño de La Esquina dice: "Quiero que el sistema imprima tickets más rápido."
Si solo escuchás eso, vas a optimizar la impresión. Pero si preguntás más, descubrís que el problema real es que los mozos caminan hasta la cocina para dar órdenes verbalmente (y se equivocan), luego la cocina imprime el ticket. La solución es enviar pedidos desde la mesa a la cocina directamente — ni siquiera es un problema de velocidad de impresión.
📐 Fundamento
Técnicas principales:
1. Entrevistas
La más efectiva. Se hacen con todos los tipos de usuarios del sistema.
- Estructurada: Preguntas definidas de antemano. Útil para comparar respuestas.
- No estructurada: Conversación abierta. Más información, menos comparable.
- Semi-estructurada: Mix. La más recomendada en la práctica.
Preguntas clave: ¿Qué hace usted actualmente? ¿Qué problemas tiene? ¿Qué le gustaría que el sistema hiciera? ¿Qué no puede faltar? ¿Qué errores comete con el proceso actual?
2. Observación directa
Mirar al usuario trabajar sin interrumpir. Se descubren pasos que el usuario hace inconscientemente y nunca mencionaría en una entrevista.
3. Análisis de documentos
Revisar formularios, reportes, registros existentes. Los formularios de papel son una mina de oro: ya definen qué datos importan al negocio.
4. Cuestionarios / encuestas
Útiles cuando hay muchos usuarios distribuidos. Menos profundidad que la entrevista.
5. Prototipos (prototipado exploratorio)
Mostrar maquetas de la interfaz y preguntarle al usuario si esto es lo que quiere. Muy efectivo para usuarios que no saben describir lo que quieren pero sí saben reconocerlo cuando lo ven.
Stakeholders (partes interesadas):
No solo el cliente que paga. También:
- Usuarios finales (quienes usarán el sistema día a día)
- Gerentes (quienes usarán los reportes)
- IT / sistemas (quienes lo van a instalar y mantener)
- Clientes del cliente (si el sistema los afecta)
🛠️ En la práctica
Entrevista inicial con el dueño de La Esquina:
Analista: "Cuénteme cómo funciona el proceso de tomar un pedido hoy."
Dueño: "El mozo anota en un papel, va a la cocina, da la orden verbal, y el cocinero prepara. Luego al final el mozo vuelve a la cocina, saca el papel y calcula la cuenta a mano."
Analista: "¿Qué problemas tiene este proceso?"
Dueño: "Los mozos se equivocan al anotar. A veces olvidan platillos. La cuenta a veces sale mal. Y si viene el contador, no tengo como mostrarle las ventas del mes pasado."
Analista: "¿Cuántas mesas tiene? ¿Cuántos mozos?"
Dueño: "10 mesas, 2 mozos. En fin de semana a veces 3."
Analista: "¿Tienen internet en el local?"
Dueño: "Sí, tenemos wifi."
Analista: "¿Tienen tablets o teléfonos disponibles?"
Dueño: "Tenemos 2 tablets viejas y los mozos tienen teléfono propio."
Con esta información ya podemos plantear: una app web para los mozos (funciona en móvil sin instalar), pantalla en cocina que recibe pedidos, reporte de ventas para el dueño.
2.2 Historias de usuario
💡 Intuición
Una historia de usuario (User Story) es una forma concisa de expresar un requerimiento desde la perspectiva del usuario, no del sistema.
El formato clásico:
Como [tipo de usuario], quiero [funcionalidad], para [beneficio o razón].
Por ejemplo:
"Como mozo, quiero enviar un pedido desde mi teléfono a la cocina, para no tener que caminar hasta allá cada vez."
La gracia es que no prescribe la implementación ("enviar desde el teléfono") — eso es decisión técnica. Solo describe qué necesita el usuario y por qué.
📐 Fundamento
Estructura de una historia de usuario:
| Elemento | Descripción |
|---|---|
| ID | Identificador único (HU-001, HU-002...) |
| Título | Nombre corto descriptivo |
| Como | Tipo de usuario / rol |
| Quiero | La acción o funcionalidad |
| Para | El objetivo de negocio o beneficio |
| Criterios de aceptación | Lista de condiciones que deben cumplirse para que la HU se considere "completa" |
| Prioridad | Alta / Media / Baja |
| Estimado | Story points o tiempo estimado |
Criterios de aceptación (Acceptance Criteria):
Son los "tests" que el Product Owner usa para verificar que la historia se implementó correctamente. Formato típico: "Dado [contexto], cuando [acción], entonces [resultado esperado]" (Gherkin/BDD).
El criterio INVEST (buenas historias de usuario son):
- Independent — Independiente de otras HU en lo posible
- Negotiable — El "cómo" se puede negociar
- Valuable — Genera valor al usuario
- Estimable — Se puede estimar el esfuerzo
- Small — Pequeña (cabe en un sprint)
- Testable — Tiene criterios de aceptación verificables
🛠️ En la práctica
Historias de usuario para La Esquina:
HU-001: Registrar pedido
- Como: mozo
- Quiero: registrar los platillos de un pedido seleccionando desde el menú en mi teléfono
- Para: enviar la orden a la cocina sin tener que escribir nada en papel
Criterios de aceptación:
- Dado que estoy en la pantalla de nueva orden, cuando selecciono un platillo y su cantidad, entonces el platillo aparece en el resumen del pedido.
- Dado que el pedido tiene al menos un platillo, cuando presiono "Enviar a cocina", entonces el pedido aparece en la pantalla de cocina en menos de 5 segundos.
- Si envío un pedido vacío, el sistema muestra un mensaje de error.
HU-002: Ver cuenta de mesa
- Como: mozo
- Quiero: ver el total de la cuenta de una mesa incluyendo IVA
- Para: cobrar correctamente sin hacer cuentas a mano
Criterios de aceptación:
- El sistema muestra subtotal, IVA (13%) y total por separado.
- Si una mesa no tiene pedidos activos, muestra $0.00.
HU-003: Ver reporte de ventas
- Como: administrador
- Quiero: ver el total de ventas del día, desglosado por platillo
- Para: saber cuáles platillos son más rentables
Criterios de aceptación:
- El reporte muestra cantidad vendida y monto total por cada platillo.
- El reporte se puede filtrar por fecha.
2.3 Diagrama de casos de uso
💡 Intuición
Un caso de uso modela una interacción entre un usuario (o sistema externo) y el sistema. Es una descripción de qué puede hacer el usuario con el sistema — no cómo el sistema lo implementa.
El diagrama de casos de uso da una vista rápida de las funcionalidades del sistema y quién las usa. Es como el menú de un restaurante: te dice qué podés pedir (casos de uso) y quiénes son los clientes (actores).
📐 Fundamento
Elementos del diagrama de casos de uso (UML):
| Elemento | Representación | Significado |
|---|---|---|
| Actor | Figura de palito | Persona o sistema externo que interactúa con el sistema |
| Caso de uso | Óvalo | Funcionalidad del sistema |
| Límite del sistema | Rectángulo | Separa lo que está dentro del sistema de lo externo |
| Asociación | Línea sólida | Actores que participan en un caso de uso |
| < |
Flecha punteada | El caso A siempre incluye el caso B |
| < |
Flecha punteada | El caso A opcionalmente puede extender B |
| Generalización | Flecha con triángulo | Herencia entre actores o entre casos de uso |
<
A <<include>> B: Cada vez que se ejecuta A, se ejecuta B obligatoriamente. Ejemplo: "Registrar pedido" siempre incluye "Autenticar usuario".A <<extend>> B: A puede opcionalmente agregar comportamiento a B. Ejemplo: "Imprimir ticket" puede extender "Cerrar cuenta" (a veces el cliente quiere ticket, a veces no).
Descripción de caso de uso (plantilla):
| Campo | Contenido |
|---|---|
| Nombre | Verbo + objeto (Registrar pedido) |
| Actor principal | Quién inicia la interacción |
| Precondición | Qué debe ser verdad antes de que empiece |
| Flujo principal | Pasos normales del éxito |
| Flujos alternativos | Variaciones (platillo agotado, cancelar) |
| Flujos de excepción | Errores (sin conexión, sesión expirada) |
| Postcondición | Estado del sistema al terminar |
🛠️ En la práctica
Diagrama de casos de uso — La Esquina (texto):
Sistema: Gestión de Pedidos La Esquina
Actores:
- Mozo
- Administrador
- Pantalla de Cocina (actor secundario)
Casos de uso:
Mozo:
- Iniciar sesión
- Registrar pedido <<include>> Iniciar sesión
- Modificar pedido
- Cerrar cuenta <<include>> Calcular total con IVA
- Imprimir ticket <<extend>> Cerrar cuenta
Administrador:
- Iniciar sesión
- Gestionar menú (agregar, editar, desactivar platillos)
- Ver reporte de ventas <<include>> Iniciar sesión
- Gestionar empleados
Pantalla de Cocina:
- Recibir pedido (sistema externo que muestra órdenes)
- Marcar pedido como listo
Descripción del caso de uso "Registrar pedido":
- Actor principal: Mozo
- Precondición: El mozo tiene sesión iniciada. La mesa está asignada al mozo.
- Flujo principal:
- El mozo selecciona la mesa.
- El mozo elige platillos del menú y cantidades.
- El sistema muestra el resumen del pedido.
- El mozo confirma.
- El sistema envía el pedido a la pantalla de cocina.
- El sistema guarda el pedido con timestamp y estado "en preparación".
- Flujo alternativo 4a: El mozo quiere agregar una nota especial (ej: "sin cebolla"). El sistema permite texto libre por platillo.
- Flujo de excepción 5a: Sin conexión. El sistema muestra error y mantiene el pedido en borrador.
- Postcondición: El pedido aparece en cocina y en el historial de la mesa.
2.4 Documento de especificación de requerimientos (ERS simplificado)
📐 Fundamento
El ERS (Especificación de Requerimientos de Software) — o SRS en inglés — es el documento maestro que captura todos los requerimientos del sistema. Es el contrato técnico entre el analista y el desarrollador, y entre el cliente y el equipo.
Secciones típicas de un ERS:
-
Introducción
- Propósito del documento
- Alcance del sistema
- Definiciones y acrónimos
- Referencias
-
Descripción general
- Perspectiva del producto (contexto, sistemas con los que interactúa)
- Funciones principales
- Características de los usuarios
- Restricciones generales
-
Requerimientos funcionales
- Listados por módulo o por caso de uso
- Numerados: RF-001, RF-002...
-
Requerimientos no funcionales
- Rendimiento, disponibilidad, seguridad, usabilidad, portabilidad
- Numerados: RNF-001, RNF-002...
-
Restricciones
- Tecnologías obligatorias, presupuesto, plazos
-
Apéndices
- Diagramas, glosario, casos de uso detallados
🛠️ En la práctica
ERS simplificado — La Esquina (fragmento):
1. Alcance
Sistema web para gestión de pedidos y facturación de la Pupusería La Esquina, San Miguel. Permite a mozos tomar pedidos desde dispositivos móviles, a la cocina recibirlos en tiempo real, y al administrador ver reportes de ventas.
2. Requerimientos funcionales
| ID | Requerimiento |
|---|---|
| RF-001 | El sistema debe permitir al mozo iniciar sesión con usuario y contraseña. |
| RF-002 | El sistema debe mostrar el menú del día con nombre, descripción y precio de cada platillo. |
| RF-003 | El sistema debe permitir al mozo crear un pedido asociado a una mesa, con uno o más platillos y sus cantidades. |
| RF-004 | Al confirmar el pedido, el sistema debe mostrarlo en la pantalla de cocina en tiempo real. |
| RF-005 | El sistema debe calcular automáticamente el subtotal, el IVA (13%) y el total de cada mesa. |
| RF-006 | El sistema debe generar un reporte de ventas diarias con cantidad y monto por platillo. |
| RF-007 | El administrador puede agregar, editar y desactivar platillos del menú. |
3. Requerimientos no funcionales
| ID | Requerimiento |
|---|---|
| RNF-001 | El sistema debe funcionar en Chrome y Firefox en sus dos últimas versiones. |
| RNF-002 | El sistema debe cargar la pantalla de toma de pedidos en menos de 3 segundos con conexión de 5 Mbps. |
| RNF-003 | Las contraseñas deben almacenarse hasheadas (bcrypt). |
| RNF-004 | El sistema debe funcionar con hasta 3 mozos tomando pedidos simultáneamente. |
2.5 Ejercicios
✏️ Ejercicio 2.1 — Historias de usuario
Escribí una historia de usuario con criterios de aceptación para:
a. "El cliente de La Esquina quiere pagar con tarjeta." b. "El administrador quiere que el sistema le avise cuando un platillo se ha vendido más de 50 veces en el día."
Solución
a. HU: Pago con tarjeta
- Como: mozo
- Quiero: registrar que una cuenta se pagó con tarjeta
- Para: cerrar la cuenta correctamente y llevar el registro del método de pago
Criterios:
- Al cerrar una cuenta, el mozo puede elegir "efectivo" o "tarjeta".
- Si elige tarjeta, el sistema registra el método de pago en el historial.
- El reporte diario muestra ventas en efectivo y en tarjeta por separado.
b. HU: Alerta de platillo popular
- Como: administrador
- Quiero: recibir una alerta cuando un platillo supere 50 ventas en el día
- Para: preparar más ingredientes antes de quedarse sin stock
Criterios:
- La alerta aparece como notificación en el panel del administrador.
- La alerta incluye el nombre del platillo y el conteo actual.
- El umbral de 50 puede configurarse en ajustes.
✏️ Ejercicio 2.2 — Casos de uso
Para un sistema de biblioteca universitaria:
a. Identificá al menos 3 actores.
b. Listá 6 casos de uso principales.
c. Indicá al menos un <<include>> y un <<extend>> con justificación.
Solución
Actores: Estudiante, Docente, Bibliotecario, Sistema de Correo (actor secundario).
Casos de uso:
- Buscar libro
- Reservar libro
- Prestar libro
- Devolver libro
- Renovar préstamo
- Ver historial de préstamos
<<<include>> "Autenticar usuario" — porque siempre se necesita saber quién reserva.
<<<extend>> "Devolver libro" — cuando se devuelve un libro, el sistema opcionalmente puede enviar un correo de confirmación al estudiante (no siempre, depende de la configuración).
✏️ Ejercicio 2.3 — Requerimientos ocultos
El dueño de una ferretería te dice: "Quiero un sistema para llevar el inventario." En la entrevista descubrís que tiene 3 proveedores, recibe pedidos por WhatsApp, y a veces vende al crédito a clientes frecuentes.
a. Identificá 5 requerimientos que NO mencionó explícitamente pero que probablemente necesita. b. Escribí las preguntas de seguimiento que harías para confirmar estos requerimientos.
Solución
Requerimientos ocultos:
- Gestión de proveedores (quién surte qué producto, tiempos de entrega, precios de compra).
- Registro de crédito por cliente (cuánto debe cada quien, fecha de vencimiento).
- Alerta de stock mínimo (cuándo pedir más de un producto).
- Registro de pedidos recibidos por WhatsApp (posiblemente integración o al menos formulario para capturar).
- Reporte de cuentas por cobrar (listado de clientes con crédito pendiente).
Preguntas de seguimiento:
- ¿Con cuánta anticipación le avisan los proveedores cuando hay retrasos?
- ¿Cómo decide usted cuándo pedir más de un producto?
- ¿Lleva registro de cuánto le debe cada cliente? ¿En papel o en algún cuaderno?
- ¿Los pedidos por WhatsApp tienen algún formato? ¿O varía por cliente?
- ¿Necesita saber el margen de ganancia por producto (precio compra vs precio venta)?
2.6 Para profundizar
- Wiegers & Beatty, Software Requirements — el libro de referencia sobre el tema.
- Cohn, User Stories Applied — el libro definitivo sobre historias de usuario.
- Siguiente: UML estático — Diagrama de clases — modelar la estructura del sistema.
Definiciones nuevas: levantamiento de requerimientos, stakeholder, historia de usuario, criterio de aceptación, criterio INVEST, caso de uso, actor, <