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

<> vs <>:

  • 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:
    1. El mozo selecciona la mesa.
    2. El mozo elige platillos del menú y cantidades.
    3. El sistema muestra el resumen del pedido.
    4. El mozo confirma.
    5. El sistema envía el pedido a la pantalla de cocina.
    6. 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:

  1. Introducción

    • Propósito del documento
    • Alcance del sistema
    • Definiciones y acrónimos
    • Referencias
  2. Descripción general

    • Perspectiva del producto (contexto, sistemas con los que interactúa)
    • Funciones principales
    • Características de los usuarios
    • Restricciones generales
  3. Requerimientos funcionales

    • Listados por módulo o por caso de uso
    • Numerados: RF-001, RF-002...
  4. Requerimientos no funcionales

    • Rendimiento, disponibilidad, seguridad, usabilidad, portabilidad
    • Numerados: RNF-001, RNF-002...
  5. Restricciones

    • Tecnologías obligatorias, presupuesto, plazos
  6. 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."

✏️ 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.

✏️ 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.


2.6 Para profundizar


Definiciones nuevas: levantamiento de requerimientos, stakeholder, historia de usuario, criterio de aceptación, criterio INVEST, caso de uso, actor, <>, <>, ERS/SRS, requerimiento oculto.