System Design
Fundamentos de requisitos
Explica cómo convertir necesidades en requisitos claros, verificables, trazables y priorizados sin confundir reglas, restricciones y soluciones técnicas.
- Última actualización
- Actualizada
- Nivel
- Fundamentos
System Design
Explica cómo convertir necesidades en requisitos claros, verificables, trazables y priorizados sin confundir reglas, restricciones y soluciones técnicas.
Un requisito no es una idea suelta ni una solución técnica disfrazada. Es una necesidad o condición trazable que debe poder entenderse, discutirse, diseñarse y verificarse.
Los requisitos conectan el problema descubierto con el comportamiento y las cualidades que el sistema debe ofrecer.
problema y objetivos
→ necesidades
→ requisitos
→ diseño
→ implementación
→ evidencia de cumplimientoSu valor no está en llenar una plantilla, sino en reducir interpretaciones incompatibles y dejar claro por qué se construye algo y cómo se sabrá que funciona.
Sin requisitos explícitos, cada persona completa los vacíos con sus propias suposiciones. Producto puede imaginar una regla, desarrollo otra y pruebas validar una tercera.
Ejemplo:
“controlar inventario”Puede significar registrar cantidades, impedir ventas sin stock, manejar reservas, auditar movimientos o predecir compras. Antes de diseñar, el alcance debe transformarse en condiciones observables.
Necesidad
→ evitar vender unidades inexistentes
Requisito
→ el sistema debe impedir confirmar una venta que exceda el stock vendible
Regla de negocio
→ stock vendible = físico − reservado − bloqueado
Soluciones candidatas
→ actualización condicional, lock, reserva temporal o control optimistaLa necesidad y la regla pueden permanecer aunque cambie la implementación. Mezclar estos niveles convierte decisiones reversibles en obligaciones falsas.
Explican resultados organizacionales: reducir pérdidas, cumplir regulación o aumentar capacidad.
Describen qué resultado necesita una persona o sistema externo.
Especifican comportamientos, datos y cualidades que la solución debe proporcionar.
Cubren migración, capacitación, convivencia y retiro del sistema anterior.
Estos niveles deben conectarse. Un requisito de sistema sin objetivo o stakeholder necesita una justificación explícita.
La clasificación ayuda a aplicar técnicas distintas, pero no debe fragmentar la comprensión. Una operación de pago tiene comportamiento, seguridad, latencia y recuperación al mismo tiempo.
descubrir
→ redactar hipótesis
→ aclarar con ejemplos
→ revisar conflictos
→ priorizar
→ diseñar
→ verificar
→ cambiar o retirarLos requisitos no se congelan al aprobarlos. Evolucionan con aprendizaje, regulación y operación. Lo importante es controlar el cambio y sus consecuencias.
Útiles para objetivos, decisiones y excepciones, pero las personas pueden describir el proceso ideal en vez del real.
Revela workarounds, información informal y dependencias invisibles.
Tickets, hojas de cálculo, formularios, logs y reportes muestran datos y errores reales.
Permiten enfrentar perspectivas y construir ejemplos compartidos.
Reducen incertidumbre cuando el comportamiento es difícil de imaginar verbalmente.
Ninguna técnica es suficiente por sí sola. Triangula fuentes.
Contribuye a un objetivo, obligación o riesgo real.
Dos lectores competentes obtienen una interpretación equivalente.
Expresa una capacidad o condición que puede discutirse y verificarse con foco.
No contradice otras reglas o estados.
Puede satisfacerse dentro de restricciones conocidas.
Existe evidencia observable para decidir cumplimiento.
Se conecta con fuente, objetivo, diseño y prueba.
Su importancia y coste de incumplimiento son conocidos.
No todos los requisitos alcanzan certeza completa de inmediato. Las preguntas abiertas deben quedar visibles, no ocultas con lenguaje ambiguo.
ID y nombre:
Tipo:
Enunciado:
Motivación y objetivo relacionado:
Fuente / owner:
Actores o sistemas afectados:
Condiciones y reglas:
Prioridad:
Dependencias:
Criterio de verificación:
Supuestos y preguntas abiertas:
Estado y vigencia:La plantilla debe adaptarse al alcance. Campos vacíos no agregan calidad.
RF-INV-07: Reservar stock al confirmar pedido
Enunciado:
Al confirmar un pedido, el sistema debe reservar las cantidades aceptadas en la sucursal correspondiente.
Motivación:
Evitar que dos pedidos consuman las mismas unidades.
Precondiciones:
Pedido pendiente, sucursal válida y productos vendibles.
Reglas:
La cantidad reservada no puede superar el stock vendible.
Resultado:
El pedido queda confirmado y la reserva registrada atómicamente, o la operación falla sin cambios parciales.
Verificación:
Dos confirmaciones concurrentes no producen stock negativo ni reservas duplicadas.El ejemplo no exige PostgreSQL ni un algoritmo concreto. Sí exige atomicidad porque forma parte del resultado esperado.
Una frase declarativa puede ser insuficiente para comprender alternativas. Complementa con escenarios:
Dado stock vendible de 5
cuando dos pedidos de 4 se confirman a la vez
entonces solo uno puede reservar completamenteLos escenarios no sustituyen el requisito; muestran cómo se interpreta.
Los requisitos pueden competir:
Proceso:
No escondas el conflicto en una implementación arbitraria.
problema
→ objetivo
→ requisito
→ regla / caso de uso
→ decisión de diseño
→ componente / contrato
→ prueba / métricaLa trazabilidad permite responder por qué existe una funcionalidad, qué se afecta al cambiarla y qué evidencia protege el comportamiento.
No requiere una matriz burocrática para todo proyecto; puede implementarse con IDs, enlaces y relaciones consistentes.
Clasifica información como:
Un supuesto escrito como requisito produce falsa certeza. Asigna owner y fecha de validación.
Registra la discrepancia y quién decide. No combines silenciosamente versiones.
Busca una señal observable o conviértelo en objetivo de investigación.
Versiona vigencia y artefactos afectados.
Puede expirar después de migración; no lo confundas con comportamiento permanente.
Expresa garantía mínima y estrategia si no está disponible.
“Usar Kafka” no explica necesidad. Pregunta qué cualidad o integración se busca.
“Siempre”, “nunca” y “todos” exigen comprobar excepciones.
Dificulta priorización y pruebas. Divide cuando cada parte puede variar independientemente.
Luego nadie puede resolver dudas.
El cambio es normal; el problema es perder razones, impacto o versiones.
La ambigüedad suele aparecer al intentar un caso concreto.
Mayor precisión es necesaria en regulación, seguridad, pagos, sistemas distribuidos, equipos múltiples y contratos externos. En un producto pequeño pueden usarse historias y criterios ligeros, siempre que conserven decisiones esenciales.
Requisitos funcionales desarrolla cómo especificar comportamiento, entradas, estados, errores y resultados.