Información recolectada
Trae entrevistas, observaciones, encuestas o documentos de tu proyecto. Si todavía no tienes evidencia, usa el caso ficticio de control de ingreso para practicar sin inventar información de tu proyecto.
Programa Análisis y Desarrollo de Software (ADSO)
Construye la base documental del software antes de programar.
Guía 2 · Fase de análisis de requerimientos.
Partirás de información recolectada y producirás, paso a paso, un documento de análisis con contexto, lenguaje del negocio, actores, historias de usuario, requisitos, criterios de aceptación, pruebas, trazabilidad y decisiones iniciales de arquitectura.
01 contexto
✓ verificable
Resultado de Aprendizaje (RAP) 02
Resultado de aprendizaje
Establecer los requisitos del software de acuerdo con la información recolectada.
Antes de comenzar · No necesitas conocer las siglas
Primero entiende el recorrido. Después aprende los nombres técnicos.
Esta guía está escrita para una primera aproximación al análisis de requerimientos. Cada término se presenta con su nombre completo antes de usar una forma abreviada.
Analizar antes de diseñar
Convertirás frases ambiguas en decisiones claras, relacionadas y comprobables. Las dudas no se ocultan: se registran como preguntas para validar con las personas interesadas.
Documento de análisis de requerimientos
Entregarás un paquete que explique qué problema se resolverá, para quién, qué debe hacer el software, con qué calidad, cómo se comprobará y qué decisiones iniciales pueden orientar su construcción.
Requerimiento y requisitoEn conversación suelen usarse como equivalentes. En esta guía, “requerimiento” nombra la necesidad que se analiza y “requisito” el enunciado documentado, claro y verificable que resulta del análisis.
ArtefactoEs un producto de trabajo que conserva una decisión: puede ser un documento, tabla, diagrama, lista, modelo o conjunto de criterios.
InteresadoEs una persona u organización afectada por el software o con autoridad para aportar información, validar una decisión o aprobar el alcance.
TrazabilidadEs la capacidad de seguir una decisión desde su fuente hasta el requisito, la prueba y la parte del software que la implementará.
Un documento que crece por capítulos
Los ocho artefactos que construirás en orden
Cada resultado usa el anterior como entrada. Así evitas saltar de una conversación directamente a pantallas, tablas o tecnologías sin justificación.
- 01Contexto y alcanceProblema, objetivo, fuentes, actores, límites, supuestos y preguntas abiertas.
- 02Glosario, reglas y permisosLenguaje compartido del negocio, reglas verificables y matriz de responsabilidades.
- 03Historias de usuarioNecesidades expresadas desde el actor, con acción, beneficio y prioridad.
- 04Catálogo de requisitosCapacidades funcionales y cualidades medibles derivadas de las historias.
- 05Criterios y casos de usoEjemplos de aceptación, flujo principal, alternativas, errores y permisos.
- 06Trazabilidad y plan de pruebasRelaciones desde la fuente hasta la prueba que demostrará cada resultado.
- 07Lienzo de construcciónDatos, interfaz, lógica, seguridad, componentes y arquitectura candidatos.
- 08Documento final revisadoVersión, responsables, decisiones validadas, pendientes y anexos listos para orientar el desarrollo.
Regla de avance:no pases al siguiente artefacto hasta poder explicar de dónde salió el actual, qué decisión registra y quién debe validarlo.
Entrada obligatoria · Guía 1 → Guía 2
No empieces con una pantalla: empieza con el paquete de hallazgos.
La Guía 1 no entrega requisitos terminados. Entrega evidencia y candidatos que aquí se deben ordenar, preguntar, priorizar y convertir en una especificación verificable.
Regla de transferencia:si un dato no tiene fuente, fecha, estado o responsable de validación, se conserva como pregunta abierta; no se convierte en una tabla, permiso ni pantalla.
| Insumo que traes de la Guía 1 | Qué debes comprobar al recibirlo | En qué se transforma aquí |
|---|---|---|
| Dossier de caracterizaciónSIPOC, flujo AS-IS, proceso y alcance. | ¿El proceso, sus límites y sus fuentes están claros? | Contexto y alcance CTX-*. |
| Matriz de hallazgos validadosDato observable, fuentes trianguladas, decisión y estado. | ¿El hallazgo está validado o sigue en discusión? | Identificadores de evidencia E-*, historias y requisitos candidatos. |
| Candidatos del dominioActores, datos, reglas, eventos y calidades. | ¿La responsabilidad o regla se observó y quién la confirma? | Glosario, reglas, roles, permisos, modelo de datos y RNF. |
| Preguntas abiertas y restriccionesImpacto, responsable y estado. | ¿Qué decisión bloquea o cambia el alcance? | Escenarios alternativos, criterios BDD, pruebas y decisiones pendientes. |
- 01Selecciona un hallazgoElige uno que tenga actor, situación, resultado observable y fuente.
- 02Conserva las preguntasMarca qué falta confirmar antes de redactar un requisito definitivo.
- 03Abre la trazabilidadUsa el mismo identificador de evidencia en contexto, historia, requisito y prueba.
Si todavía no tienes proyecto: usa el caso ficticio “Control de ingreso de equipos”, conserva la etiqueta ejemplo didáctico y reemplázalo por evidencia autorizada en la transferencia a tu proyecto.
Orientación para quien empieza desde cero
Primero completa la ruta esencial; después profundiza donde tu proyecto lo necesite
La guía contiene material profesional amplio, pero el producto mínimo no exige memorizarlo todo ni producir documentos por volumen. La ruta esencial construye una sola capacidad de extremo a extremo.
Ruta esencial
- Elige una evidencia y un hallazgo validado de G1.
- Escribe contexto, alcance, actor, regla y preguntas.
- Prioriza una Historia de Usuario pequeña y valiosa.
- Deriva los RF/RNF necesarios y criterios de aceptación.
- Diseña pruebas, conserva trazabilidad y registra la revisión.
- Entrega una tarea lista para prototipar en G3.
Profundización profesional
Amplía con más historias, modelo de datos, matriz de permisos, caso de uso detallado, integraciones, arquitectura candidata, SOW o métricas avanzadas solo cuando ayuden a tomar una decisión real.
Regla: profundizar agrega claridad y control de riesgo; nunca reemplaza una cadena mínima coherente.
Identificadores que continúan en toda la serie
E-01 → H-01 → CTX-01 → HU-01 → RF/RNF-01 → CA-01 → PR-01 → UI-01 → VAL-01 → BL-01G2 construye hasta prueba y backlog; G3 agrega interfaz y validación; G4 planea el ítem sin romper los vínculos.Diccionario inicialQué significan las siglas que encontrarás
Una sigla forma una palabra corta con letras iniciales; una abreviatura reduce una palabra o expresión. No debes memorizarlas de inmediato: vuelve a este diccionario cuando lo necesites.
Programa y aprendizaje
- Servicio Nacional de Aprendizaje (SENA)
- Entidad colombiana en la que se enmarca esta ruta de formación.
- Análisis y Desarrollo de Software (ADSO)
- Nombre del programa de formación.
- Resultado de Aprendizaje (RAP)
- Capacidad observable que se espera desarrollar y demostrar.
- Sistema de Gestión del Aprendizaje (LMS)
- Plataforma virtual donde se consulta una actividad o se entrega una evidencia.
Análisis de requerimientos
- Historia de Usuario (HU)
- Frase que expresa quién necesita una capacidad, qué busca y para qué le aporta valor.
- Requisito Funcional (RF)
- Comportamiento o capacidad que el software debe ofrecer y que puede observarse o probarse.
- Requisito No Funcional (RNF)
- Condición de calidad o restricción medible, como rendimiento, seguridad o disponibilidad.
- Caso de Uso (CU)
- Descripción paso a paso de cómo un actor y el sistema colaboran para alcanzar un objetivo.
- Desarrollo Guiado por Comportamiento (BDD)
- Práctica colaborativa que aclara el comportamiento esperado mediante ejemplos escritos como “Dado”, “Cuando” y “Entonces”. Las letras provienen del nombre inglés Behavior-Driven Development.
- Gherkin y Cucumber
- Gherkin es una sintaxis legible para escribir ejemplos estructurados; Cucumber es una herramienta que puede conectar esos ejemplos con pruebas automatizadas. No son sinónimos de BDD.
- Desarrollo Conjunto de Aplicaciones (JAD)
- Taller facilitado en el que usuarios y equipo analizan y acuerdan necesidades. Las letras provienen de Joint Application Development.
Evidencia y trazabilidad
- Identificador de Evidencia (E-*)
- Código único que indica de dónde salió el requisito o necesidad (el origen). Ejemplos: E-OBS (Observación), E-ENT (Entrevista), E-DOC (Documento revisado).
- Contexto (CTX)
- Identificador que agrupa información clave sobre el problema, el entorno y los actores relacionados con una evidencia.
- Criterio de Aceptación (CA)
- Condición específica que debe cumplirse obligatoriamente para que una Historia de Usuario se considere terminada (muy asociado al enfoque BDD).
- Prueba (PR)
- Identificador del escenario de verificación formal que asegura que el sistema cumple el requisito (puede ser unitaria, funcional o de carga).
Revisión y priorización
- Independiente, Negociable, Valiosa, Estimable, Pequeña y Comprobable (INVEST)
- Recordatorio para revisar la calidad de una Historia de Usuario. Las letras provienen de las palabras equivalentes en inglés.
- Debe tener, Debería tener, Podría tener y No tendrá por ahora (MoSCoW)
- Método para priorizar el alcance. Las letras provienen de las expresiones en inglés y las dos “o” solo facilitan pronunciar el nombre.
- Crear, Consultar, Actualizar y Eliminar (CRUD)
- Cuatro operaciones usadas para revisar qué puede hacer cada rol con una entidad. Las letras vienen de Create, Read, Update, Delete.
- Declaración de Trabajo (SOW)
- Documento complementario que delimita entregables, alcance, exclusiones, tiempos y control de cambios. Las letras vienen de Statement of Work.
- Definición de Listo para Iniciar (DoR)
- Acuerdo del equipo sobre la información mínima que debe tener un ítem antes de comenzar su construcción.
Tecnología y entrega
- Identificador (ID) y Localizador Uniforme de Recursos (URL)
- Un identificador distingue un artefacto o registro; una URL indica la dirección de un recurso en la web.
- Base de Datos (BD) y Lenguaje de Consulta Estructurado (SQL)
- La base conserva información; el lenguaje SQL permite definirla y consultarla en sistemas relacionales.
- Clave Primaria (PK) y Clave Foránea (FK)
- Una clave primaria identifica un registro; una clave foránea relaciona ese registro con otro.
- Interfaz de Programación de Aplicaciones (API)
- Contrato para que dos componentes de software intercambien solicitudes y respuestas.
- Interfaz de Usuario (UI)
- Parte visible con la que una persona interactúa, como formularios, mensajes y botones.
- Código de Respuesta Rápida (QR)
- Código gráfico que un dispositivo puede leer para recuperar un identificador o dato.
- Inteligencia Artificial (IA)
- Tecnologías que apoyan tareas como generar o analizar texto; no sustituyen la validación con las personas interesadas.
- Formato de Documento Portátil (PDF)
- Formato de archivo usado para conservar la presentación del documento final.
- Peso colombiano (COP)
- Código internacional de la moneda usado en los ejemplos de presupuesto.
- Servidor Privado Virtual (VPS) y Unidad Central de Procesamiento (CPU)
- Un servidor virtual aloja la aplicación; la unidad de procesamiento ejecuta sus instrucciones.
- Sistema de Nombres de Dominio (DNS)
- Servicio que traduce un nombre web legible al destino de red correspondiente.
- Protocolo de Transferencia de Hipertexto (HTTP) y su versión segura (HTTPS)
- Reglas de comunicación de la web; la versión segura cifra el tránsito.
- Transferencia de Estado Representacional (REST) y Notación de Objetos de JavaScript (JSON)
- REST orienta el diseño de servicios web; JSON es un formato de texto para intercambiar datos.
- Protocolo de Control de Transmisión (TCP)
- Protocolo de red que entrega datos de forma ordenada y confiable entre dos extremos.
- Certificado de seguridad web, comúnmente llamado SSL
- Credencial digital usada para autenticar un sitio y habilitar una conexión cifrada. El nombre histórico significa Secure Sockets Layer.
- Lista de trabajo pendiente (backlog) e iteración corta (sprint)
- El backlog ordena el trabajo por realizar; un sprint es un periodo corto en el que el equipo intenta completar una parte priorizada.
- Interfaz web (frontend), servicio interno (backend) y marco de desarrollo (framework)
- El frontend presenta la experiencia; el backend aplica reglas y accede a datos; un framework ofrece una estructura reutilizable para desarrollar.
- Credencial temporal (token) y percentil 95
- Un token representa información o autorización durante un tiempo; el percentil 95 indica que 95 de cada 100 mediciones quedaron en el valor señalado o por debajo.
Cómo leer los códigos de los artefactos
El prefijo indica el tipo de documento y el número permite encontrarlo: CTX-03 es “Contexto 03”; HU-03, “Historia de Usuario 03”; RF-03, “Requisito Funcional 03”; RNF-03, “Requisito No Funcional 03”; CA-03, “Criterio de Aceptación 03”; CU-03, “Caso de Uso 03”; PR-03, “Prueba 03”; BL-03, “Elemento de backlog 03”; CMP-03, “Componente 03”; I-03, “Instrumento 03”; GLOS-03, “Término de glosario 03”; RN-03, “Regla de Negocio 03”; y E-OBS-03, “Evidencia de Observación 03”. Usar el mismo número ayuda a leer, pero no demuestra por sí solo que dos artefactos estén relacionados: la relación debe escribirse en la plantilla o en la matriz de trazabilidad.
Regla fácil para no confundirse:
la Historia de Usuario explica qué necesita una persona y para qué; el Requisito Funcional explica qué debe hacer el sistema; el criterio de aceptación explica cómo sabremos que lo hizo bien. Una historia puede producir varios requisitos y un requisito puede apoyar varias historias.
Palabras de relación:
deriva de significa “salió de”; satisface significa “responde a la necesidad”; afecta significa “también debe cumplirlo”; verifica significa “lo comprueba”; e implementa significa “lo convierte en una parte construible del software”.
Cuando aparezca una sigla después de esta sección, ya podrás relacionarla con su nombre completo. Si no la recuerdas, vuelve a este diccionario: comprender el artefacto es más importante que memorizar sus letras.
00 · Ingeniería de contexto
La IA puede generar código. No puede adivinar tu intención.
El contexto convierte conversaciones, restricciones y decisiones del negocio en información útil para diseñar.
01
Pregunta antes de completar
Cuando una frase permite varias interpretaciones, el equipo debe detenerse y recolectar información. Es más barato aclarar una palabra hoy que corregir un producto mañana.
02
Conserva el porqué
El beneficio explica la decisión. Si solo documentamos botones y pantallas, perdemos la oportunidad de evaluar si la solución realmente aporta valor.
03
Haz visible lo verificable
Un buen requisito permite imaginar una prueba: una condición, una acción y un resultado que otra persona puede observar.
ClaroUna sola interpretación
CompletoActor, acción y valor
VerificableSe puede probar
TrazableConecta con el objetivo
Criterio humano ante inteligencia artificial
Una respuesta convincente no es una especificación validada
La IA puede proponer redacciones, escenarios alternativos o preguntas de calidad. No conoce por sí sola la fuente, el presupuesto, las obligaciones, los conflictos entre actores ni el impacto de una decisión. La persona analista debe verificar, negociar, registrar incertidumbre y asumir la responsabilidad.
Puede apoyarDetectar ambigüedad, generar contraejemplos, comparar variantes y revisar consistencia de identificadores.
Debes verificarCada afirmación contra E-*, H-* y CTX-*; cada umbral con interesados y cada solución con el equipo técnico.
Debes protegerDatos personales, secretos, derechos de autor, accesibilidad, seguridad y grupos afectados por sesgos.
BITÁCORA HUMANO–IA · G2
Uso: [no utilizada / utilizada]
Artefacto apoyado: [HU / RF / RNF / CA / PR / otro]
Propósito y prompt:
Datos compartidos y anonimización:
Salida recibida:
Fuentes, pruebas o personas usadas para verificar:
Errores, sesgos o riesgos detectados:
Decisión humana: [aceptar / modificar / rechazar]
Justificación, responsable y fecha:Sin automatización ciega: nunca copies una salida de IA como requisito aprobado. Si no usaste IA, registra “No utilizada” y describe tu método de revisión.
01 · Cadena de derivación
Cada artefacto tiene una fuente. Nada se inventa al final.
El aprendiz debe poder seguir una misma evidencia hasta el código y la base de datos, y explicar por qué existe cada decisión.
CASO GUÍA
Control de ingreso de equipos
En la garita, el guarda tarda en confirmar si un visitante tiene un ingreso vigente y qué equipos están autorizados. El equipo necesita reducir la espera sin exponer información innecesaria.
-
01FUENTE
Información recolectada
Entrevistas, observación, encuestas, documentos y JAD dejan hallazgos con fuente, fecha y contexto.
“El guarda verifica el QR, llama al encargado y anota el ingreso cuando el visitante trae equipos.”
Salida: E-OBS-03 · hallazgo verificable y preguntas abiertas. -
02INTERPRETACIÓN
Roles y permisos
Los roles nacen de responsabilidades repetidas, decisiones y límites observados; no de cargos escogidos al azar.
Guarda: consulta y decide el ingreso. Administrador: configura usuarios y permisos.
Salida: matriz actor–rol–permiso y principio de mínimo privilegio. -
03VALOR
Historia de usuario
El rol se convierte en el punto de vista de una necesidad con valor para el negocio.
Historia de Usuario 03 (HU-03): Como guarda, quiero consultar el registro del visitante mediante su código QR para reducir la espera y tomar una decisión trazable.
Salida: una historia pequeña, valiosa, negociable y revisable. -
04PRECISIÓN
Requisitos funcionales
El verbo de la historia se separa en capacidades, entradas, reglas, excepciones y resultados observables.
Requisito Funcional 03 (RF-03): El sistema debe permitir al guarda leer el código QR, localizar el ingreso vigente y mostrar solo datos autorizados.
Complemento: el Requisito No Funcional 03 (RNF-03) mide el rendimiento; los ejemplos BDD comprueban los casos vigente, vencido y sin permiso. -
05CONSTRUCCIÓN
Implementación por historia
El equipo toma una Historia de Usuario priorizada y construye un corte vertical completo, no una capa aislada.
Interfaz para escanear → servicio de aplicación mediante una API → reglas de autorización → consulta → auditoría → pruebas.
Incremento: la Historia de Usuario 03 funciona de extremo a extremo antes de sumar reportes o administración. -
06PERSISTENCIA
Modelo relacional
Los datos que RF y BDD necesitan conservar se convierten en entidades, claves, relaciones, restricciones e índices candidatos.
Visitante → Ingreso; Ingreso ↔ Equipo mediante IngresoEquipo; Usuario → Rol; Ingreso → Auditoría.
Validación: cardinalidad, obligatoriedad, unicidad, privacidad, historial y consultas de RF.
02 / CÓMO NACEN LOS ROLESEvidencia → permiso
Un rol es una responsabilidad observable
No confundas actor con rol: Juan es una persona; Guarda es el conjunto de responsabilidades y permisos con los que Juan opera.
| Hallazgo | Rol derivado | Permiso justificado |
|---|---|---|
| E-OBS-03: verifica QR y decide ingreso | Guarda | Leer ingreso vigente; registrar decisión; no administrar usuarios. |
| E-ENT-02: configura usuarios, equipos y permisos | Administrador | Crear, consultar, actualizar y desactivar catálogos autorizados. |
| E-OBS-03: presenta QR para ser validado | Visitante | Identificarse ante el proceso; no obtiene acceso al panel interno. |
06 / CÓMO NACE LA BASE DE DATOSRequisitos + criterios → tablas
Del comportamiento al modelo relacional
Primero se pregunta qué debe recordar el sistema para cumplir el Requisito Funcional 03; luego se valida el modelo con las consultas y escenarios, antes de escribir instrucciones en Lenguaje de Consulta Estructurado (SQL).
1
Extraer datosQR, vigencia, visitante, equipos, usuario y decisión.
2
Nombrar entidadesVisitante, Ingreso, Equipo, Usuario, Rol y Auditoría.
3
Resolver relacionesLas N:M necesitan una tabla intermedia: IngresoEquipo.
4
Agregar reglasClave Primaria (PK), Clave Foránea (FK), campos obligatorios, valores únicos, estados, historial e índices.
ROL 1 — N USUARIO_ROL N — 1 USUARIOVISITANTE 1 — N INGRESOINGRESO 1 — N INGRESO_EQUIPO N — 1 EQUIPOINGRESO 1 — N EVENTO_AUDITORIAPRUEBA DEL DISEÑO
Requisito Funcional 03: localizar el ingreso vigente por código QR exige conservar una credencial temporal, el estado y la vigencia; por eso se valida la unicidad y una consulta eficiente antes de escribir SQL.
RF-03 → consulta QR + estado vigente → criterios BDD: vigente / vencido / sin permisoRegla: un sustantivo sugiere una entidad; solo una necesidad validada y una relación comprobada justifican una tabla.
E-OBS-03→ROL-GUARDA→HU-03→RF-03 / RNF-03→HU-03 implementada→modelo relacional candidato
Esta cadena no es una fila rígida:
una Historia de Usuario puede abrir varias ramas —por ejemplo, comportamiento, rendimiento y seguridad— y un Requisito No Funcional puede cruzar varias historias. La matriz registra esas conexiones para que nadie tenga que adivinarlas.
Actividad de trazabilidad
Ahora completa la cadena con tu propio caso
Parte de un hallazgo real de tu proyecto. No saltes directamente a la tabla: justifica cada decisión y deja las dudas como preguntas abiertas.
- 01Fuente¿Qué entrevista, observación o documento respalda el hallazgo?
- 02Rol¿Quién realiza la acción y qué permiso necesita?
- 03Historia¿Qué quiere lograr el rol y qué beneficio obtiene?
- 04Requisito¿Qué comportamiento, regla, calidad y prueba se derivan?
- 05Construcción¿Qué corte vertical se puede entregar con esa historia?
- 06Datos¿Qué debe persistir, cómo se relaciona y qué restricción necesita?
Ver una respuesta posible para el caso guía
Hallazgo: el guarda verifica un QR y necesita decidir el ingreso sin llamar al encargado.
Cadena: Guarda → HU-03 → RF-03 + RNF-03 → pantalla de consulta, caso de uso, autorización, auditoría y pruebas → Ingreso, Visitante, Usuario/Rol y EventoAuditoría.
Pregunta que permanece: ¿el QR identifica solo un ingreso o también los equipos autorizados? La respuesta define la relación y no debe suponerse.
02 · Fundamentos
Primero entiende el problema. Luego escribe la solución.
La ingeniería de requisitos conecta la necesidad del negocio con un comportamiento que el equipo puede desarrollar y probar.
01Expresa valor
Historia de usuario
El puente del valor
Resume la necesidad desde la perspectiva del actor: quién necesita algo, qué quiere lograr y para qué.
Analogía: es el pedido del cliente en un restaurante: expresa qué quiere y por qué, sin dictar cómo debe organizarse la cocina.
EjemploComo guarda, quiero consultar el registro mediante QR para reducir la espera.
02Define capacidad
Requisito funcional
La precisión del comportamiento
Descompone la acción de la historia en una capacidad verificable: actor, entradas, reglas, excepciones y resultado observable.
Analogía: es la receta que convierte el pedido en pasos observables: ingredientes, reglas, resultado y qué hacer si falta algo.
DerivaciónEl sistema debe permitir al guarda leer el QR y recuperar el registro vigente.
Anatomía de una historia
01 — 0301
Rol
¿Quién necesita esta capacidad?
02
Acción
¿Qué quiere poder hacer?
03
Beneficio
¿Qué valor obtiene y por qué importa?
03 · De la historia a la especificación
Primero expresa el valor. Después especifica y mide.
La historia conserva la intención del actor; el Requisito Funcional (RF) detalla la capacidad y el Requisito No Funcional (RNF) define la calidad o el límite que debe demostrarse.
RF
Requisitos funcionales
Se derivan de la acción de la historia. Responden: ¿qué debe hacer el sistema? Incluyen actor, disparador, entradas, reglas, excepciones y salida observable.
RNF
Requisitos no funcionales
Se derivan de la evidencia, los riesgos y las restricciones. Responden: ¿con qué calidad y bajo qué límites? Incluyen atributo, entorno, medida, umbral y método de verificación.
Regla de construcción
Una historia no se copia como requisito: se analiza su acción y su beneficio, se separan capacidades y reglas en Requisitos Funcionales (RF), y se traducen las expectativas de calidad en Requisitos No Funcionales (RNF) medibles.
| Artefacto | Pregunta guía | Ejemplo derivado del mismo hallazgo | ¿Cómo se verifica? |
|---|---|---|---|
| HU-03 | ¿Quién necesita qué valor? | Como guarda, quiero consultar el registro del visitante mediante su QR para reducir la espera. | Revisión con el actor y comprobación de que la historia sea pequeña, valiosa y comprobable. |
| RF-03 | ¿Qué capacidad y reglas materializan la acción? | El sistema debe permitir al guarda leer el QR y recuperar el registro vigente, mostrando solo datos autorizados. | Prueba funcional, reglas de negocio y escenarios BDD de éxito, vencimiento y permiso. |
| RNF-03 | ¿Qué calidad debe demostrarse? | Con 150 solicitudes concurrentes, el 95 % de las lecturas debe responder en menos de 3 segundos. | Prueba de carga con entorno, datos, versión y percentil registrados. |
01 / RFComportamiento
Cómo se construye un requisito funcional
- 01Extrae el verbo y el objetoConvierte la acción de la historia en una capacidad singular.
- 02Completa el comportamientoDefine disparador, entradas y pasos observables.
- 03Explicita reglas y excepcionesIncluye vigencia, permisos, datos faltantes y errores.
- 04Conecta la evidenciaConserva fuente, resultado, prioridad y criterio de prueba.
Ejemplo completo · RF-03
Fuente: E-OBS-03.
Actor y disparador: el guarda recibe un visitante con QR.
Regla: el registro debe estar vigente y los datos deben estar autorizados.
Resultado: el guarda puede continuar o detener el ingreso con una decisión trazable.
02 / RNFCalidad
Cómo se construye un requisito no funcional
Rendimientotiempo de respuesta, concurrencia, consumo.
Seguridadautenticación, autorización, cifrado, auditoría.
Disponibilidadhorario, porcentaje de tiempo operativo y recuperación.
Usabilidadaccesibilidad, aprendizaje, navegación con teclado.
Mantenibilidadregistros técnicos, pruebas, modularidad y documentación.
Compatibilidadnavegadores, dispositivos, versiones e integraciones.
Transforma lo vago en medible
✕ “La consulta debe ser rápida.”
✓ “Con 150 solicitudes concurrentes, el 95 % de las lecturas responde en menos de 3 s, medido con una prueba de carga.”
Método de Análisis Temprano
Análisis de Actores, Roles y Permisos
Antes de detallar RF y permisos necesitas saber quién participa, qué valor busca y qué límites tiene.
Actor vs. Rol
Actor: La persona, organización o sistema externo que interactúa con el software. Ejemplos: Juan o la Interfaz de Programación de Aplicaciones (API) de un banco.
Rol: El conjunto de permisos lógicos en el sistema (Ej: Administrador, Cliente). Un actor asume un rol para operar.
Principio de Mínimo Privilegio
Un requerimiento de seguridad (RNF) clave. Nunca des más permisos de los estrictamente necesarios. Si el Recepcionista solo necesita leer inventario, no le des un rol que le permita borrar productos.
Herramienta: Matriz de Roles y Permisos (CRUD)
Mapea los roles contra los módulos del sistema usando el acrónimo CRUD (Create/Crear, Read/Leer, Update/Actualizar, Delete/Borrar).
| Módulo / Entidad | Rol: Guarda | Rol: Administrador | Rol: Empleado |
|---|---|---|---|
| Equipos (Inventario) | C, R (Crear, Leer) | C, R, U, D (Total) | Sin Acceso |
| Reportes Ingreso | R (Solo Leer suyos) | C, R, U, D (Total) | R (Solo Leer suyos) |
Método de Análisis de Requisitos
Priorización MoSCoW y matriz de trazabilidad
MoSCoW agrupa el trabajo en “Debe”, “Debería”, “Podría” y “No tendrá por ahora”. Sirve para acordar qué se construirá primero sin perder la conexión con el negocio.
DEBE TENER · MUST HAVE
Sin esto no hay software
Requisitos críticos del núcleo del sistema. Ejemplo: autenticación y registro de ingreso.
DEBERÍA TENER · SHOULD HAVE
Alto valor esperado
Funcionalidades importantes pero con alternativas temporales. Ejemplo: exportación a una hoja de cálculo o a Formato de Documento Portátil (PDF).
PODRÍA TENER · COULD HAVE
Deseable si hay tiempo
Mejoras de experiencia o reportes avanzados. Ejemplo: modo oscuro o notificaciones automáticas.
NO TENDRÁ POR AHORA · WON'T HAVE
Fuera de alcance inicial
Requisitos pospuestos explícitamente para versiones futuras. Ejemplo: Reconocimiento facial por IA.
Ejemplo de matriz de trazabilidad: objetivo del negocio → Requisito Funcional → criterio de aceptación BDD
| Identificador del requisito | Necesidad del Negocio | Requisito Funcional redactado | MoSCoW | Criterio Verificable (BDD) |
|---|---|---|---|---|
| RF-01 | Seguridad de activos e ingresos | El sistema debe validar las credenciales del usuario y registrar su rol antes de conceder acceso a la plataforma. | Must | Dado un usuario registrado, cuando ingresa credenciales válidas, entonces accede al panel de su rol. |
| RF-02 | Reducción de tiempos en garita | El sistema debe localizar el registro vigente por número de cédula y mostrar los datos autorizados para el proceso de ingreso. | Must | Dado un registro vigente, cuando el guarda busca la cédula, entonces observa los datos autorizados del visitante. |
Ejercicios guiados
Practica antes de pasar al laboratorio
01Construye la historiaHallazgo → HU+
Hallazgo: “En tres observaciones, localizar una herramienta tomó entre 4 y 6 minutos”. Construye una historia con actor, acción y beneficio.
Respuesta orientadora
Historia: Como encargado del almacén, quiero consultar la disponibilidad por código para reducir el tiempo de entrega y evitar préstamos duplicados.
02Deriva el RFHU → capacidad+
Deriva un RF de esta historia: “Como encargado del almacén, quiero consultar la disponibilidad por código para reducir el tiempo de entrega”. Incluye salida y una excepción.
Ejemplo de solución
RF: el sistema debe permitir consultar una herramienta por código y mostrar su disponibilidad; si tiene un préstamo activo, debe informar el estado y no permitir duplicar el préstamo.
03Completa la verificaciónRNF + BDD+
Completa la cadena con un RNF y un criterio BDD para la consulta de disponibilidad.
Ejemplo de solución
RNF: el 95 % de las consultas responde en menos de 2 s bajo la carga acordada. BDD: Dado un código válido, cuando el encargado consulta, entonces observa disponibilidad o el estado de préstamo.
Concepto clave antes de construir
Caso de uso: describe una interacción completa
Un caso de uso explica cómo un actor alcanza un objetivo con ayuda del sistema. Sirve para conversar el comportamiento paso a paso y descubrir reglas, excepciones, datos y evidencias antes de diseñar pantallas, endpoints o tablas.
Historia de usuarioExpresa valorQuién necesita qué y para qué.
Caso de usoExplica el procesoCómo interactúan actor y sistema para lograrlo.
BDDComprueba un ejemploQué condición, acción y resultado deben observarse.
Cómo construirlo
- 01Delimita el objetivoEscribe un verbo y un resultado observable. “Consultar ingreso vigente” es mejor que “gestionar acceso”.
- 02Identifica actor y alcanceIndica quién inicia, qué sistema responde y qué queda fuera del caso.
- 03Declara condicionesRegistra precondiciones, datos necesarios, permisos y reglas que deben cumplirse.
- 04Narra el flujo principalNumera acciones alternadas entre actor y sistema; cada paso debe poder observarse o verificarse.
- 05Agrega alternativas y erroresExplica qué sucede si el dato falta, está vencido, no hay permiso o una integración falla.
- 06Cierra con la postcondiciónDescribe qué queda logrado, guardado, informado o auditado y qué evidencia lo demuestra.
Método reutilizable
Cómo hacer tu propio análisis, paso a paso
Repite esta secuencia con cualquier proyecto. Avanza solo cuando el resultado de un paso tenga fuente, propósito y una pregunta de validación.
- 01RecolectaConserva hallazgo, fuente, fecha y contexto; separa hechos de opiniones.
- 02DelimitaDefine problema, objetivo, actores, alcance, exclusiones, supuestos y restricciones.
- 03Aclara lenguajeConstruye glosario, estados y reglas de negocio; deja dudas como preguntas abiertas.
- 04Expresa valorRedacta historias pequeñas con actor, acción, beneficio y prioridad.
- 05EspecificaDeriva RF, RNF, casos de uso y escenarios BDD; no agregues soluciones sin evidencia.
- 06ValidaRevisa con interesado, instructor y equipo: claridad, completitud, consistencia y verificabilidad.
- 07TrazaConecta evidencia → contexto → Historia de Usuario → requisitos → criterios BDD → prueba → componente → tarea.
- 08Prepara construcciónDefine datos, permisos, estados, corte vertical, riesgos y la Definición de Listo para Iniciar (DoR).
Puerta de salida:si una decisión no tiene fuente o validación, no la conviertas todavía en requisito, tabla, punto de acceso técnico ni pantalla. Regístrala como pregunta pendiente.
04 · Instrumentos de especificación
De una evidencia a una tarea que puede construirse.
Avanza de lo más cercano al problema hacia lo más preciso y construible. Estudia la cadena resuelta, copia las plantillas y genera un primer paquete para tu proyecto; todo resultado debe revisarse con interesados, instructor y equipo técnico.
- 01EvidenciaHallazgo validado
- 02ContextoActor, alcance y reglas
- 03HistoriaValor del actor
- 04RFCapacidad observable
- 05RNFCalidad medible
- 06BDDEjemplo verificable
- 07TrazabilidadFuente, prueba y estado
- 08Trabajo pendienteCorte construible para el backlog
Secuencia didáctica SENA
Comprender, practicar, demostrar y transferir
- ReflexiónCompara interpretaciones de un requisito ambiguo.Evidencia: preguntas de aclaración.
- ContextualizaciónOrdena un hallazgo en contexto e historia de usuario.Evidencia: actor, acción, valor, reglas y preguntas abiertas.
- ApropiaciónDeriva Requisitos Funcionales, Requisitos No Funcionales, criterios BDD y trazabilidad del mismo caso.Evidencia: paquete revisado y priorizado.
- TransferenciaAplica el método a tu proyecto formativo.Producto: especificación, lienzo de construcción y lista inicial de trabajo pendiente.
Ejemplo completamente resuelto
Cadena del caso “Control de ingreso de equipos”
| Artefacto | Identificador | Ejemplo diligenciado | Pregunta de revisión |
|---|---|---|---|
| Evidencia | E-OBS-03 | En tres observaciones, el registro manual tomó entre 230 y 270 segundos por persona. | ¿La muestra cubre franjas y actores representativos? |
| Contexto | CTX-03 | Actor: guarda. Objetivo: reducir espera. Alcance: consultar un registro vigente por QR. Regla: mostrar solo datos autorizados. | ¿El alcance, las reglas y las preguntas abiertas están explícitos? |
| Historia | HU-03 | Como guarda, quiero consultar el registro mediante QR para reducir la espera en el acceso. | ¿Explica quién obtiene valor y para qué? |
| RF | RF-03 | El sistema debe permitir al guarda leer el código QR del visitante y recuperar su registro vigente. | ¿Expresa una sola capacidad observable? |
| RNF | RNF-03 | Con 150 solicitudes concurrentes, el 95 % de las lecturas debe mostrar respuesta en menos de 3 segundos. | ¿Tiene contexto, medida, umbral y método de prueba? |
| BDD | CA-03 | Dado un visitante con registro vigente, cuando el guarda lee su QR, entonces observa los datos autorizados y puede continuar el ingreso. | ¿Describe comportamiento sin imponer implementación? |
| Prueba | PR-03 | Prueba funcional de lectura y prueba de carga con 150 usuarios virtuales; registrar percentil 95. | ¿La evidencia demuestra RF y RNF por separado? |
| Lista de trabajo pendiente | BL-03 | Implementar consulta de registro por código QR con criterios CA-03 y prueba PR-03; prioridad “Debe tener”. | ¿Está lista para estimar y conserva sus vínculos? |
| Componentes | CMP-03 | Derivar datos persistentes, caso de uso, interfaz y estados, permisos y pruebas para un incremento vertical. | ¿Cada decisión se justifica con RF, RNF o BDD? |
I-00Glosario del dominio y reglas de negocioCaptura el lenguaje común antes de derivar historias y requisitos. Sin glosario, los artefactos posteriores pueden significar cosas distintas para cada actor.Ejemplo + plantilla
Por qué construirlo primero
El glosario es el contrato de lenguaje del equipo
Un mismo hallazgo puede generar historias incompatibles si cada actor usa la misma palabra con significado diferente. El glosario congela las definiciones acordadas; las reglas de negocio formalizan las condiciones que el sistema debe respetar. Ambos artefactos se construyen antes de redactar RF y RNF para que la especificación no cambie de significado entre sesiones.
Problema sin glosario
"Ingreso" puede ser el evento de acceso del visitante o el registro en la base de datos. Si no se acuerda, el RF y la tabla hablan de conceptos distintos.
Solución con glosario
GLOS-02: Ingreso = evento de acceso de un visitante autorizado con fecha, hora y equipos registrados. Diferente de Entrada = paso físico por la garita.
Ejemplo diligenciado — caso "Control de ingreso de equipos"
| Identificador | Término | Definición acordada | Sinónimos que generan confusión | Estado |
|---|---|---|---|---|
| GLOS-01 | Visitante | Persona externa que solicita acceso temporal al edificio, identificada por su número de documento y un QR de sesión. | "Externo", "invitado", "tercero" | Validado |
| GLOS-02 | Ingreso | Evento de acceso de un visitante: incluye fecha, hora de inicio, estado (vigente / vencido / denegado) y los equipos autorizados en esa sesión. | "Entrada", "visita", "registro" | Validado |
| GLOS-03 | Equipo | Dispositivo tecnológico (laptop, cámara, tablet) que el visitante lleva consigo y que debe quedar registrado en el ingreso. | "Artículo", "ítem", "activo" | En revisión |
| RN-01 | Vigencia de QR | Un QR de ingreso es vigente mientras el visitante no haya salido y la fecha-hora de expiración acordada no haya transcurrido. Un QR vencido no puede reutilizarse. | Origen: E-OBS-03 · RF relacionado: RF-03 | |
| RN-02 | Mínimo privilegio | El rol Guarda puede consultar y registrar ingresos; no puede crear ni eliminar cuentas de usuario ni modificar el catálogo de permisos. | Origen: E-ENT-02 · RF relacionado: RF-01 | |
Plantilla reutilizable — Glosario
Términos del dominio
IDENTIFICADOR: GLOS-[número]
TÉRMINO: [nombre exacto como lo usan los actores]
DEFINICIÓN ACORDADA: [qué significa en este sistema, no en general]
SINÓNIMOS O NOMBRES ALTERNATIVOS: [otras formas que los actores usan para el mismo concepto]
FUENTE: [quién lo mencionó o en qué hallazgo aparece]
ESTADO: [propuesto / en revisión / validado]
TÉRMINOS RELACIONADOS: [identificadores de glosario vinculados]Plantilla reutilizable — Regla de negocio
IDENTIFICADOR: RN-[número]
NOMBRE: [enunciado breve de la regla]
ORIGEN: [identificador de evidencia o de contexto]
CONDICIÓN: [cuándo aplica — qué debe cumplirse]
CONSECUENCIA: [qué ocurre si la regla se viola o no se cumple]
EXCEPCIONES: [casos en que la regla no aplica, si los hay]
ESTADO: [propuesto / validado / aprobado]
REQUISITO RELACIONADO: [identificador de requisito funcional o no funcional]
Consejo de construcción
Construye el glosario junto con los actores: muestra los términos en una sesión corta y pide que cada persona los lea en voz alta. Si alguien lo interpreta diferente, la definición todavía no está acordada.
Las reglas de negocio no son reglas técnicas: describen condiciones que el negocio impone. Si la regla no puede explicarse sin código, probablemente no es una regla de negocio sino una decisión de implementación.
I-01Tarjeta de historia de usuario e INVESTConvierte un hallazgo en valor conversable y revisa si la historia está lista para derivar requisitos.Ejemplo + plantilla
Ejemplo diligenciado
HU-03 · Agilizar consulta de ingreso
Como guarda, quiero consultar el registro del visitante mediante su QR para reducir la espera y tomar una decisión trazable.
- I · Independiente: puede planearse sin el módulo de reportes.
- N · Negociable: el QR es una opción acordada, no una excusa para omitir conversación.
- V · Valiosa: reduce espera y mejora trazabilidad.
- E · Estimable: entradas, salida y dependencias están visibles.
- S · Pequeña: una sola consulta, no todo el control de acceso.
- T · Comprobable: tiene criterios funcionales y de rendimiento.
Plantilla reutilizable
Historia + revisión INVEST
IDENTIFICADOR: HU-[número]
FUENTE: [evidencia y contexto relacionado]
ACTOR/ROL: [quién obtiene valor]
PRIORIDAD: [MoSCoW]
Como [rol específico]
quiero [capacidad o intención]
para [beneficio observable].
INVEST
[ ] Independiente o dependencias explícitas
[ ] Negociable, sin diseño cerrado innecesario
[ ] Valiosa para un actor
[ ] Estimable por el equipo
[ ] Suficientemente pequeña
[ ] Comprobable con criterios
REGLAS Y PREGUNTAS ABIERTAS: [dudas]
RELACIONES: deriva_de [evidencia/contexto]; después se vinculará con [RF/RNF]
DEFINICIÓN DE LISTO PARA INICIAR (DoR): [condiciones mínimas antes de derivar RF y RNF]I-02Ficha de requisito funcionalDeriva una capacidad singular de la historia, con reglas, entradas, excepciones y salida observable.Ejemplo + plantilla
Ejemplo diligenciado
RF-03 · Consultar registro por QR
- Fuente
- HU-03, CTX-03, E-OBS-03 y entrevista E-ENT-01.
- Actor/disparador
- El guarda recibe a un visitante con código QR.
- Entrada
- Identificador contenido en el código; no incluye datos personales visibles.
- Comportamiento
- Localizar el registro vigente y mostrar únicamente los datos autorizados.
- Excepción
- Si el código vence o no existe, informar el motivo y ofrecer el flujo manual autorizado.
- Resultado
- El guarda puede continuar o detener el ingreso con una decisión trazable.
Plantilla reutilizable
Especificación RF
IDENTIFICADOR: RF-[número]
HISTORIA(S) DE ORIGEN: [HU-03; escribe varios identificadores si aplica]
TIPO DE RELACIÓN: deriva_de [la historia o historias que precisas]
NOMBRE: [verbo + objeto]
FUENTE: [identificador de evidencia, contexto o entrevista]
OBJETIVO RELACIONADO: [identificador del objetivo]
ACTOR Y DISPARADOR: [quién y cuándo]
ENTRADAS: [datos necesarios]
ENUNCIADO
El sistema debe permitir a [actor] [acción singular] para [resultado de negocio].
REGLAS: [condiciones que deben cumplirse]
EXCEPCIONES: [qué ocurre si falta algo]
SALIDA OBSERVABLE: [resultado visible o registrable]
DEPENDENCIAS: [otros requisitos o sistemas]
PRIORIDAD: [Must/Should/Could/Won't]
ESTADO: [propuesto/validado/aprobado]Ejercicio de catálogo consolidado
De dos historias a un catálogo de requisitos
Un proyecto real tiene varias historias. El catálogo junta todos los RF y RNF derivados en una tabla con fuente, prioridad y estado. Estudia cómo HU-01 (autenticación) y HU-03 (consulta por QR) producen cuatro requisitos distintos, cada uno con su vínculo trazable.
| Identificador | Historia o alcance | Enunciado (resumen) | Tipo | Prioridad | Estado |
|---|---|---|---|---|---|
| RF-01 | HU-01 | El sistema debe validar las credenciales del usuario y asignar el rol antes de conceder acceso. | RF | Must | Validado |
| RNF-01 | HU-01 | Con 200 intentos de autenticación concurrentes, el 95 % debe recibir respuesta en menos de 2 s. | RNF · Rendimiento | Must | Propuesto |
| RF-03 | HU-03 | El sistema debe permitir al guarda leer el QR y recuperar el registro vigente, mostrando solo datos autorizados. | RF | Must | Validado |
| RNF-03 | HU-03 | Con 150 solicitudes concurrentes, el 95 % de las lecturas QR debe responder en menos de 3 s. | RNF · Rendimiento | Must | Propuesto |
Ejemplo de requisito transversal
RNF-SEG-01 · Protección de datos: puede afectar HU-01 y HU-03 al mismo tiempo. No se copia dentro de cada historia: se registra una vez y se enlaza con todas las capacidades que deben cumplirlo.
Regla del catálogo
Cada Requisito Funcional debe señalar la Historia de Usuario que precisa. Un Requisito No Funcional puede señalar una historia, uno o varios requisitos funcionales, o indicar que es transversal porque afecta varias capacidades. En todos los casos debe conservar su fuente, justificación y alcance. Si no puedes explicar de dónde salió, déjalo como pregunta abierta. El catálogo se ordena primero por prioridad MoSCoW y luego por necesidad, no por tipo de artefacto.
CATÁLOGO DE REQUISITOS FUNCIONALES Y NO FUNCIONALES — [Nombre del proyecto]
Versión: [x.x] Fecha: [año-mes-día] Responsable: [nombre]
| Identificador | Historia o alcance | Enunciado (resumen) | Tipo | Prioridad | Estado |
|--------|----------|--------------------------------------------|---------------|-----------|-----------|
| RF-01 | HU-01 | [El sistema debe ...] | RF | Must | Propuesto |
| RNF-01 | HU-01 | [Con [N] carga, el 95% responde en [X] s] | RNF·Rendim. | Must | Propuesto |
| RF-02 | HU-02 | [El sistema debe ...] | RF | Should | Propuesto |
| RNF-02 | HU-02 | [En [entorno], el sistema debe ...] | RNF·Seguridad | Should | Propuesto |
NOTA: Todo Requisito Funcional debe vincular una o más Historias de Usuario. Un Requisito No Funcional también puede ser transversal: en ese caso vincula la fuente y las capacidades que afecta. Si no puedes explicar su origen, es una pregunta abierta.I-03Escenario de calidad para RNFDeriva de la evidencia una condición medible y define cómo se comprobará.Ejemplo + plantilla
Ejemplo diligenciado
RNF-03 · Rendimiento de lectura
- Atributo
- Rendimiento.
- Fuente
- E-OBS-03 y expectativa de operación en hora pico.
- Estímulo
- Una solicitud válida de consulta por QR.
- Entorno
- Hora pico con 150 solicitudes concurrentes y datos de prueba representativos.
- Respuesta
- Mostrar los datos autorizados o un error controlado.
- Medida/umbral
- Latencia de extremo a extremo en percentil 95 menor de 3 segundos.
Plantilla reutilizable
Especificación RNF
IDENTIFICADOR: RNF-[número]
HISTORIA(S) Y RF AFECTADOS: [HU/RF relacionados; varios si aplica]
ALCANCE: [una historia / varias capacidades / transversal]
TIPO DE RELACIÓN: afecta [la historia, RF o capacidades que deben cumplirlo]
ATRIBUTO DE CALIDAD: [rendimiento/seguridad/usabilidad/...]
FUENTE Y JUSTIFICACIÓN: [evidencia o restricción]
ESTÍMULO: [evento que activa la respuesta]
ENTORNO: [carga, dispositivo, horario, red o condición]
RESPUESTA ESPERADA: [comportamiento observable]
MEDIDA: [unidad o indicador]
UMBRAL: [valor mínimo/máximo]
MÉTODO DE VERIFICACIÓN: [prueba, revisión o inspección]
RESPONSABLE DE VALIDAR: [rol]
ENUNCIADO
En [entorno], cuando [estímulo], el sistema debe [respuesta] cumpliendo [medida y umbral].I-04Matriz de criterios BDDDescribe ejemplos concretos de flujo exitoso, alternativa y error.Ejemplo + plantilla
Ejemplo diligenciado
CA-03 · Tres escenarios esenciales
Dado un visitante con registro vigente, cuando el guarda lee el QR, entonces observa los datos autorizados y puede continuar.
Dado un QR vencido, cuando se intenta consultar, entonces se informa la causa y se ofrece el flujo manual autorizado.
Dado un usuario sin rol de guarda, cuando intenta consultar el QR, entonces se rechaza la operación y se registra el intento.
Plantilla reutilizable
Matriz BDD
IDENTIFICADOR: CA-[número]
HISTORIA Y REQUISITO(S) QUE VERIFICA: [HU/RF relacionados]
TIPO DE RELACIÓN: verifica [qué comportamiento demuestra]
ESCENARIO: [nombre orientado al comportamiento]
Dado que [contexto verificable]
Y [condición adicional necesaria]
Cuando [actor ejecuta una acción]
Entonces [resultado observable]
Y [regla o efecto adicional]
DATOS DE EJEMPLO: [valores ficticios controlados]
TIPO: [feliz/alternativo/error/permiso/límite]
AUTOMATIZABLE: [sí/no y razón]
EVIDENCIA ESPERADA: [captura, log, respuesta o métrica]I-05Matriz de trazabilidad y entrada al backlogEvita requisitos huérfanos y conserva la relación con pruebas y decisiones.Ejemplo + plantilla
Ejemplo diligenciado
Fila lista para revisión
FuenteE-OBS-03
ContextoCTX-03
HistoriaHU-03
RequisitosRF-03 · RNF-03
CriteriosCA-03.1 a CA-03.3
PruebasPR-03-A · PR-03-C
Prioridad/estadoDebe tener · validado
Lista para desarrollar cuando: las fuentes están identificadas, las dudas críticas resueltas, los criterios son comprobables, las dependencias están visibles y el equipo puede estimarla.
Plantilla reutilizable
Trazabilidad + Definición de Listo para Iniciar (DoR)
OBJETIVO: [identificador del objetivo]
EVIDENCIA: [identificador de la evidencia (Ej: E-OBS-01. Código único para rastrear el origen: Observación, Entrevista, etc.)]
CONTEXTO: [identificador del contexto]
REGLA DE NEGOCIO: [identificador de la regla]
HISTORIA: [identificador de la Historia de Usuario]
REQUISITO FUNCIONAL: [identificador del Requisito Funcional]
REQUISITO NO FUNCIONAL: [identificador del Requisito No Funcional]
CRITERIOS: [identificadores de los criterios de aceptación]
PRUEBAS: [identificadores de las pruebas]
ARTEFACTO O MÓDULO: [componente]
RELACIONES EXPLÍCITAS: deriva_de [fuente] · satisface [necesidad] · verifica [criterio/prueba] · implementa [componente]
PRIORIDAD: [MoSCoW]
ESTADO / VERSIÓN: [dato]
DEFINICIÓN DE LISTO PARA INICIAR (DoR)
[ ] Fuente y valor de negocio confirmados
[ ] Reglas, excepciones y datos aclarados
[ ] RNF medibles vinculados
[ ] Criterios BDD revisados
[ ] Dependencias y riesgos visibles
[ ] Tamaño estimable por el equipoI-06Plan de pruebas por historiaDefine qué se va a probar, con qué datos, cómo se determina que pasó o falló, y qué tipo de prueba cubre cada criterio BDD o RNF.Ejemplo + plantilla
Por qué el plan de pruebas es un artefacto separado
Los criterios BDD describen el qué; el plan de pruebas detalla el cómo
Un escenario BDD describe el comportamiento esperado en lenguaje de negocio. El plan de pruebas añade: los datos exactos de entrada, el resultado esperado verificable, quién ejecuta la prueba y bajo qué condición se considera que pasó. Sin el plan, el equipo puede creer que probó algo sin haber acordado qué evidencia es suficiente.
Aceptación (BDD)
Verifica que el comportamiento descrito en Given/When/Then se cumple desde el punto de vista del usuario.
Unidad
Verifica una regla de negocio o función aislada: vigencia de QR, cálculo de permisos, validación de formato.
Integración
Verifica que la consulta, el caso de uso y la base de datos trabajan juntos correctamente.
Carga (RNF)
Verifica el umbral del RNF bajo la carga acordada: solicitudes concurrentes, percentil 95, tiempo de respuesta.
Ejemplo diligenciado — HU-03 (consulta QR)
| Identificador de prueba | Tipo | Criterio o requisito de calidad | Datos de entrada | Resultado esperado | Pasa cuando |
|---|---|---|---|---|---|
| PR-03-A | Aceptación | CA-03 (flujo exitoso) | QR con token válido y vigente del visitante V-007 | El guarda ve nombre, documento y lista de equipos autorizados | Los datos mostrados coinciden exactamente con los registrados en el ingreso |
| PR-03-B | Aceptación | CA-03 (QR vencido) | Token con fecha de expiración anterior a ahora | Mensaje de error con causa y opción de flujo manual | El sistema no muestra datos y registra el intento en auditoría |
| PR-03-U | Unidad | RN-01 (vigencia de QR) | Token con timestamp de expiración = ahora − 1 segundo | Función devuelve estado "vencido" | El resultado es "vencido" independientemente del rol del usuario |
| PR-03-C | Carga (RNF-03) | RNF-03 · percentil 95 menor de 3 segundos | 150 usuarios virtuales consultando QR distintos en simultáneo | Percentil 95 de latencia extremo a extremo menor de 3 000 milisegundos | El reporte registra un percentil 95 menor o igual a 3 segundos sin errores de servidor |
Plantilla reutilizable
Plan de pruebas por historia
PLAN DE PRUEBAS — [identificador de la Historia de Usuario] · [Nombre de la historia]
Versión: [x.x] Fecha: [año-mes-día] Responsable: [nombre]
| Identificador | Tipo | Criterio o RNF | Datos de entrada | Resultado esperado | Pasa cuando |
|-----------|---------------|-----------------------|----------------------------|-------------------------------|--------------------------------------|
| PR-[n]-A | Aceptación | CA-[n] (flujo feliz) | [datos representativos] | [comportamiento observable] | [condición verificable] |
| PR-[n]-B | Aceptación | CA-[n] (alternativa) | [datos de error/límite] | [mensaje o acción del sistema]| [condición verificable] |
| PR-[n]-U | Unidad | RN-[n] | [valor límite o frontera] | [resultado de la función] | [resultado exacto sin dependencias] |
| PR-[n]-I | Integración | RF-[n] | [combinación de módulos] | [respuesta del sistema] | [estado en BD o respuesta HTTP] |
| PR-[n]-C | Carga (RNF) | RNF-[n] | [cantidad] usuarios | percentil 95 < [X] ms, sin errores | Reporte registra el umbral |
HERRAMIENTAS CANDIDATAS
- Aceptación / integración: [Postman, Playwright, pytest, etc.]
- Unidad: [Jest, JUnit, pytest, etc.]
- Carga: [k6, JMeter, Locust, etc.]
ENTORNO DE PRUEBA
- Versión del código: [rama o tag]
- Base de datos: [con datos de prueba representativos]
- Red: [latencia y capacidad acordadas]Taller de transferencia
Construye el primer paquete de tu proyecto
¡Llegó la hora de la verdad! Usa un hallazgo real que hayas contrastado. Este generador te ayudará a organizar la información, pero recuerda que eres tú quien valida la lógica con las personas interesadas.
Antes de comenzar (Consejos de oro)
- Si no estás seguro de un campo, discútelo primero con tu equipo o tutor.
- No incluyas nombres reales, cédulas, contraseñas ni información confidencial real. Usa ejemplos o nombres ficticios seguros.
- Piensa siempre en el usuario más inexperto que usaría tu sistema y valida las ideas con ellos.
Borrador generado
Paquete de especificación para revisar
Revisión obligatoria: confirma primero el contexto y la historia con el interesado; después separa RF y RNF, prueba los escenarios y completa el lienzo de construcción antes de crear tablas, servicios o pantallas.
05 · Laboratorio interactivo
Construye. Ordena. Valida.
Simulador listo
Antes de usar cualquier simulador
Primero entiende el propósito; después practica.
Los simuladores no “adivinan” requisitos ni reemplazan la conversación con el interesado. Son espacios de ensayo para que aprendas a transformar una necesidad en artefactos revisables.
- AHistoriaResume el valor: como quién, quiero qué, para qué. Es el pedido.
- BBDDConvierte la historia en condición, acción y resultado. Es el ensayo.
- CAmbigüedadDetecta qué falta preguntar. Es la lupa del detective.
- DCaso de usoDetalla pasos, alternativas y cierre. Es el libreto.
Orden recomendadoLee la ayuda → carga o escribe un ejemplo → ejecuta el control → revisa el mensaje → copia solo después de validar.
ImportanteUn resultado “válido” es una primera revisión formal, no una aprobación del cliente ni una prueba completa del sistema.
A
USER_STORY
Constructor 01
Historia de Usuario
Selecciona cada pieza lógica. Una historia útil expresa valor, no solo una lista de tareas.
Cómo usarlo (Paso a paso para principiantes)
Si es tu primera vez, ¡no te preocupes! Sigue esta guía paso a paso para construir una historia con sentido:
- Piensa en la persona (actor): Elige quién realiza la acción en el proceso de ingreso (por ejemplo, el guarda). ¿Qué responsabilidad observaste en la Guía 1?
- Define qué quiere hacer (acción): Elige la capacidad del caso guía (por ejemplo, consultar un ingreso mediante QR). No pienses en botones o bases de datos: piensa en la acción humana.
- Descubre el valor real (beneficio): Define el “¿para qué?”. ¿Qué mejora del proceso se espera observar (por ejemplo, reducir la espera)?
Pista: Si la historia suena muy técnica ("quiero usar una API para conectar la BD"), cámbiala para que hable de las necesidades del usuario ("quiero consultar mi progreso").
SignificaUna frase de valor que cualquier persona puede entender, no un diseño de interfaz técnica.
Listo cuandoAlguien externo al proyecto (incluso alguien sin experiencia técnica) puede leerla y entender el objetivo.
Analogía: Imagina que vas a un restaurante. Tú (el cliente) dices "quiero pedir una pizza (acción) para calmar mi hambre (beneficio)". No le dices al chef cómo encender el horno.
Vista previa compilada
Como [rol], quiero [acción] para [beneficio].
Completa las tres piezas para validar la historia.
B
Gherkin
Constructor 02
Escenario BDD
>_
Arrastra un bloque o haz clic para añadirlo al escenario básico. El orden debe ser Dado → Cuando → Entonces (Given → When → Then en inglés); después amplía la historia con escenarios alternativos en la matriz de criterios BDD.
Guía paso a paso: De la teoría a la práctica
El formato Gherkin te ayuda a organizar el pensamiento sin programar. Sigue este orden mental:
- Prepara el escenario (Dado que): Define qué debe existir antes. Pregúntate: ¿Qué permisos, registros o datos necesita tener el usuario para empezar?
- El momento clave (Cuando): Define la acción desencadenante. Pregúntate: ¿Cuál es el clic fundamental o la acción clave que el usuario realiza?
- El final esperado (Entonces): Define cómo sabemos que funcionó. Pregúntate: ¿Qué mensaje ve el usuario o qué se guardó que demuestre el éxito o el error esperado?
Dado quecondición inicialCuandoacción del actorEntoncesresultado observable
Ayuda de interacción: Haz clic en los botones para agregar los bloques en el editor. Usa las flechas ↑ y ↓ de cada bloque para corregir el orden sin depender del ratón.
SignificaUn ejemplo concreto (un "ensayo de prueba") que conecta una condición con una acción y un resultado claro.
Listo cuandoPuedes usar este mismo texto para verificar con el cliente y probarlo manualmente sin conocer los detalles de código.
Analogía: Es como una receta de cocina: Dado que tengo los ingredientes listos, Cuando los horneo a cierta temperatura, Entonces obtengo un pastel delicioso.
Bloques disponibles
+Haz clic en un bloque
o suéltalo aquí
o suéltalo aquí
Aún no hay bloques en tu escenario.
Pista de ingeniería: un criterio de aceptación no describe cómo programar; describe qué debe observarse cuando el sistema funciona.
Gherkin en una mirada
BDD convierte conversaciones en ejemplos ejecutables.
El escenario debe poder ser leído por una persona no técnica y, al mismo tiempo, servir como contrato para automatizar pruebas.
Regla de oroDescribe comportamiento, no implementación.
De dónde sale
BDD nace para que negocio, análisis, desarrollo y pruebas hablen del mismo ejemplo.
El Desarrollo Guiado por Comportamiento (BDD, del inglés Behavior-Driven Development) surgió a partir del Desarrollo Guiado por Pruebas (TDD, del inglés Test-Driven Development). En vez de comenzar por nombres técnicos, el equipo conversa sobre el comportamiento que una persona necesita observar.
La secuencia Dado / Cuando / Entonces (Given / When / Then) describe una condición inicial, un evento y un resultado. Cucumber puede conectar esa estructura, escrita con la sintaxis Gherkin, con pruebas automatizadas.
No confundas las capas
BDDPráctica de colaboración y especificación por ejemplos.
GherkinSintaxis estructurada: Funcionalidad, Escenario, Dado, Cuando, Entonces, Y, Pero; las palabras originales en inglés son Feature, Scenario, Given, When, Then, And y But.
CucumberHerramienta que puede enlazar pasos de Gherkin con código de prueba.
Para ADSO: primero se valida el ejemplo con el interesado; automatizarlo es una decisión posterior.
El estado, los datos y los permisos que deben existir antes de actuar.
Una acción relevante del actor o un evento del sistema, no una secuencia de clics.
Lo que el usuario, un sistema o una medición puede comprobar después.
Escenario no significa “caso feliz”: para una historia importante escribe ejemplos separados para éxito, alternativa, error, permiso insuficiente y límite. Usa Y / And para ampliar una condición o resultado, sin esconder varias reglas distintas en una sola frase.
C
ANALIZADORSimulador 03
Detector de ambigüedad
Escribe un requerimiento del cliente y observa qué información está presente y qué deberías preguntar antes de construir.
Tu papel aquí: Aprende a hacer las preguntas correctas
Es muy común que el cliente no sepa expresar lo que necesita. ¡Eso es normal y humano! El simulador te ayudará a encontrar qué preguntas debes hacerle al cliente antes de programar.
Copia un requisito o escribe una idea. El analizador resaltará palabras vagas (ambigüedades) y te sugerirá qué preguntar:
- Actor ausente: Si no dice quién, pregúntate: ¿quién realiza o recibe exactamente la capacidad?
- Acción dudosa: Si usa verbos vagos como "gestionar" o "manejar", pregúntate: ¿qué comportamiento observable ocurre (crear, modificar, listar)?
- Beneficio oculto: Si falta el "para qué", pregúntate: ¿qué problema de negocio resolvemos haciendo esto realmente?
- Verificación indefinida: Si dice que debe ser "rápido" o "fácil", pregúntate: ¿cómo mediremos el éxito numéricamente?
SignificaUna herramienta para practicar cómo aclarar ideas confusas y evitar suposiciones en el equipo.
Listo cuandoYa no tienes dudas sobre la intención original y puedes escribir una historia clara y verificable.
Analogía: Actúa como un detective interrogando a un testigo. No asumas nada: si el testigo dice "vi un auto", tú preguntas "¿de qué color, tamaño y marca era?".
Prueba con:
El análisis aparecerá aquí.
Kit de análisis ADSO
Practica la fase de análisis como una cadena de evidencias.
La guía debe dejar una evidencia observable en cada estación: una decisión conversada, un artefacto diligenciado, una revisión y una pregunta pendiente. Así el aprendiz no solo memoriza formatos: aprende cuándo usarlos y cómo relacionarlos.
- 01Contextoproblema, alcance, actores y objetivos
- 02Lenguajeglosario, reglas y procesos
- 03Especificaciónhistorias, RF, RNF y BDD
- 04Validaciónpreguntas, revisión y trazabilidad
- 05Construccióncasos de uso, datos y estados
- 06EntregaDocumento PDF, lista de trabajo, riesgos y DoR
Ficha de contexto y alcance
Problema, objetivo, actores, fuera de alcance, supuestos y restricciones.
Práctica: separar una necesidad real de una solución prematura.Glosario y reglas de negocio
Términos del dominio, definición acordada, estados, invariantes y excepciones.
Práctica: detectar palabras que significan algo distinto para cada actor.Historia de usuario
Actor, intención, beneficio, reglas iniciales, prioridad y preguntas abiertas.
Práctica: convertir un hallazgo en una necesidad conversable y pequeña.Catálogo de RF y RNF
Capacidad, fuente, reglas, excepciones, atributo, medida, umbral y método.
Práctica: derivar el qué y el cómo sin perder el vínculo con la historia.BDD, trazabilidad y pruebas
Ejemplos de éxito, alternativa, error, permisos y límites conectados con pruebas.
Práctica: encontrar requisitos huérfanos o pruebas sin requisito.Lienzo de construcción
Casos de uso, datos candidatos, relaciones, estados, permisos, componentes y corte vertical.
Práctica: derivar decisiones sin convertir sustantivos en tablas automáticamente.Reto 1 · comprenderConvierte un hallazgo validado en contexto y una historia de usuario.Evidencia: actor, acción, beneficio, reglas y preguntas abiertas.
Reto 2 · construirDeriva RF, RNF y criterios BDD del mismo enunciado.Evidencia: paquete copiable con fuente, medida y prueba.
Reto 3 · defenderRelaciona la especificación con caso de uso, datos, estados y componentes.Evidencia: revisión por pares, riesgos y decisiones candidatas.
D
ARTEFACTOSimulador 04
Constructor de caso de uso
Diligencia una ficha de comportamiento antes de derivar pantallas, endpoints o tablas. Usa datos ficticios y deja visibles las preguntas que todavía requieren validación.
Guía detallada: Construye el libreto del software
Un Caso de Uso es simplemente una conversación estructurada entre el actor (usuario) y el sistema. ¡Pensemos juntos y llenemos la ficha paso a paso!
- El Vínculo: Relaciona este caso con la Historia de Usuario y los requisitos (ej: HU-04, RF-04) para no perder la trazabilidad de por qué lo hacemos.
- El Objetivo: ¿Qué intenta lograr el usuario de forma observable? Escríbelo claro.
- Las Precondiciones: ¿Qué tiene que ser verdad antes de empezar? (ej. "el usuario debe tener una sesión activa con rol administrador").
- El Flujo Principal: Escribe como en un guion de cine, alternando siempre: Paso 1. El actor hace X. Paso 2. El sistema muestra Y. Sé específico pero no menciones el color de botones ni frameworks técnicos.
- El Plan B (Alternativas): ¿Qué pasa si algo sale mal? (ej. "Si la contraseña es incorrecta, el sistema muestra alerta de error y le permite reintentar tres veces").
SignificaEl libreto completo de la interacción (paso a paso) para lograr un objetivo específico y qué hacer ante errores.
Listo cuandoUn desarrollador y un probador de calidad pueden leerlo juntos y saber exactamente qué construir y qué probar sin ambigüedades.
Analogía: Es como el libreto de una obra de teatro. Define quién entra a escena, qué dice cada uno, y detalla exactamente qué debe pasar si un actor olvida su línea (un escenario alternativo).
Artefacto generado
Ficha de caso de uso para revisar
06 · Puente hacia la construcción
Cada historia se implementa como un corte completo.
La historia expresa valor; los RF y BDD describen comportamiento; los RNF fijan límites. Con esos insumos el equipo implementa una historia de extremo a extremo y propone un modelo relacional sin inventar tablas o pantallas desconectadas del problema.
- 01Extrae lenguaje del dominioActores, objetos, estados, eventos y reglas.
- 02Decide qué persisteEntidades, atributos, relaciones, historial y restricciones.
- 03Asigna responsabilidadesInterfaz presenta; aplicación coordina; dominio decide; datos conservan.
- 04Diseña un corte verticalUna historia pequeña que atraviesa interfaz, servicio de aplicación y datos.
- 05Construye con pruebasBDD guía aceptación; reglas y RNF requieren pruebas propias.
Ejemplo resuelto · HU-03
Del texto de la historia a decisiones de diseño
Como guarda, quiero consultar el registro del visitante mediante su QR para reducir la espera y tomar una decisión trazable.
| Fragmento o criterio | Qué revela | Candidato de construcción | Qué falta preguntar |
|---|---|---|---|
| “Como guarda” | Actor, tarea y límite de acceso. | Rol, autorización y vista de consulta. | ¿Qué datos puede ver y qué acciones puede ejecutar? |
| “consultar el registro” | Caso de uso y resultado esperado. | Servicio de aplicación, consulta de datos y respuesta controlada. | ¿Cuál registro está vigente y cómo se selecciona? |
| “visitante mediante QR” | Objetos del dominio e identificador. | Visitante, ingreso, equipo y token QR como conceptos candidatos. | ¿Qué dato identifica sin exponer información personal? |
| “reducir la espera” + RNF-03 | Objetivo y atributo de rendimiento. | Percentil 95, índices o estrategia de consulta sujetos a prueba. | ¿Cuál carga representa la hora pico real? |
| BDD: vigente, vencido y sin permiso | Estados, alternativas y errores. | Pantallas de éxito/error, códigos de respuesta y pruebas de permiso. | ¿Cuál es el flujo manual autorizado? |
Modelo relacional candidato
- Visitante: identificador interno y datos mínimos autorizados.
- Ingreso: fecha, estado y vínculo con visitante.
- Equipo: identificador y serial validado.
- IngresoEquipo: relación entre un ingreso y sus equipos.
- Usuario, Rol y UsuarioRol: identidad, permisos y relación de acceso.
- Autorización y EventoAuditoría: decisión, vigencia y trazabilidad.
Visitante 1 — N IngresoIngreso N — M EquipoIngreso 1 — N AutorizaciónIngreso 1 — N EventoAuditoríaAntes de crear tablas: valida cardinalidad, obligatoriedad, unicidad, conservación, privacidad y qué cambios necesitan historial.
Caso de uso y reglas
- Recibir identificador QR sin confiar en datos del navegador.
- Comprobar usuario, rol, firma y vigencia.
- Localizar el ingreso activo con los datos autorizados.
- Aplicar la regla de excepción o devolver un resultado controlado.
- Registrar el evento de auditoría.
Candidato: caso de uso ConsultarIngresoPorQr. La dirección web (URL), el marco de desarrollo (framework) y el patrón de código se deciden después.
Pantalla y estados
- Listo para escanear.
- Procesando, sin permitir doble envío.
- Registro vigente y acción permitida.
- QR vencido o inexistente.
- Permiso insuficiente.
- Sin conexión y alternativa autorizada.
Accesibilidad: foco visible, anuncio del resultado, instrucciones sin depender solo del color y alternativa al uso de cámara.
Controles derivados
- Acceso por rol y mínimo privilegio.
- Credencial temporal sin datos personales legibles.
- Auditoría sin registrar secretos.
- Conservación y eliminación acordadas.
- Rendimiento en el percentil 95 vinculado al Requisito No Funcional 03.
- Recuperación y comportamiento sin red.
Corte vertical inicial
- Aceptación: vigente, vencido y sin permiso.
- Unidad: vigencia y reglas de autorización.
- Integración: consulta y registro de auditoría.
- Accesibilidad: teclado, foco y anuncios.
- Rendimiento: percentil 95 bajo la carga acordada.
Incremento: una consulta QR funcional de extremo a extremo. Reportes, administración y analítica permanecen en historias separadas.
Instrumento reutilizable
Lienzo de derivación para un incremento
Completa un lienzo por historia priorizada. Si una decisión no tiene fuente, conviértela en pregunta y no en código.
PROYECTO: [nombre]
HISTORIA: [identificador de Historia de Usuario y enunciado]
REQUISITOS: [Requisitos Funcionales y No Funcionales relacionados]
CRITERIOS BDD: [identificadores de los criterios de aceptación]
RELACIONES: implementa [HU/RF] · verifica [CA/PR] · afecta [RNF transversal, si aplica]
LENGUAJE DEL DOMINIO
- Actores y permisos: [roles]
- Objetos o conceptos: [sustantivos validados]
- Eventos: [qué ocurre]
- Estados: [ciclo de vida]
- Reglas: [condiciones e invariantes]
DATOS CANDIDATOS
- Entidades: [nombre y propósito]
- Atributos mínimos: [dato, tipo conceptual, obligatorio]
- Relaciones y cardinalidad: [1:1 / 1:N / N:M]
- Identificadores y unicidad: [reglas]
- Historial, privacidad y conservación: [decisiones]
PARTES DEL SOFTWARE
- Interfaz y estados: [carga/éxito/vacío/error/sin permiso/sin conexión]
- Caso de uso o servicio: [responsabilidad]
- Reglas de dominio: [validaciones]
- Persistencia: [operaciones necesarias]
- Integraciones: [sistema externo y contrato]
- Seguridad y operación: [roles/auditoría/registros técnicos/recuperación]
PRUEBAS
- Aceptación BDD: [escenarios]
- Unidad: [reglas]
- Integración: [datos y servicios]
- RNF: [métrica, umbral y entorno]
CORTE VERTICAL
- Incluye: [mínimo extremo a extremo]
- No incluye: [historias futuras]
- Preguntas pendientes: [lista]
- Decisión, responsable y fecha: [registro]Instrumento I-07
Lista de trabajo pendiente (backlog) de cortes verticales
La lista de trabajo pendiente organiza las historias en orden de entrega. Cada fila debe tener información suficiente para estimarse antes de ingresar al siguiente periodo de trabajo. Si la Definición de Listo para Iniciar (DoR) tiene condiciones sin cumplir, la historia todavía no puede comenzar.
Un corte vertical es una historia que atraviesa todas las capas del sistema —interfaz, servicio de aplicación y datos— y entrega un incremento funcional completo. El backlog los ordena de mayor a menor prioridad MoSCoW, de modo que el equipo trabaja primero lo que tiene más valor para el negocio y está mejor especificado.
| # | Historia de Usuario | Enunciado breve | Prioridad | DoR ✓ | Tamaño | Iteración o sprint | Requisitos vinculados |
|---|---|---|---|---|---|---|---|
| 1 | HU-01 | Autenticación y asignación de rol | Debe tener | ✅ | Mediano (M) | 1 | RF-01 · RNF-01 |
| 2 | HU-03 | Consultar registro del visitante por QR | Debe tener | ✅ | Mediano (M) | 1 | RF-03 · RNF-03 |
| 3 | HU-04 | Registrar nuevo ingreso con equipos | Debe tener | ⚠️ Falta aclarar relación QR ↔ equipos | Grande (L) | 2 | RF-04 |
| 4 | HU-05 | Exportar reporte de ingresos del día | Debería tener | 🔲 Pendiente de validación con administrador | Pequeño (S) | 3 | RF-05 |
Definición de Listo para Iniciar (DoR)
Una historia está lista para entrar a la iteración o sprint cuando la fuente está identificada, las dudas críticas están resueltas, los criterios BDD son comprobables, las dependencias son visibles y el equipo puede estimarla. Una historia sin DoR completa genera retrabajo.
LISTA DE TRABAJO PENDIENTE (BACKLOG) — [Nombre del proyecto]
Versión: [x.x] Fecha: [año-mes-día] Responsable: [nombre]
LEYENDA DE TAMAÑO: S = pequeño (< 1 jornada) · M = mediano (1-2 jornadas) · L = grande (> 2 jornadas; considera dividir)
LEYENDA DE DoR: ✅ = listo · ⚠️ = dudas menores · 🔲 = pendiente de validación
| # | Historia | Enunciado breve | Prioridad | DoR ✓ | Tamaño | Iteración | Requisitos vinculados |
|---|-------|--------------------------------------------|-----------|-------|--------|--------|---------------------|
| 1 | HU-01 | [Lo que el actor quiere lograr] | Debe tener | ✅ | M | 1 | RF-01 · RNF-01 |
| 2 | HU-02 | [Lo que el actor quiere lograr] | Debe tener | ✅ | S | 1 | RF-02 |
| 3 | HU-03 | [Lo que el actor quiere lograr] | Debe tener | ⚠️ | L | 2 | RF-03 · RNF-03 |
| 4 | HU-04 | [Lo que el actor quiere lograr] | Debería tener | 🔲 | M | 3 | RF-04 |
DEFINICIÓN DE LISTO PARA INICIAR (DoR) — lista de verificación por historia
[ ] Fuente y valor de negocio confirmados con el interesado
[ ] Reglas, excepciones y datos aclarados (sin dudas críticas)
[ ] RNF medibles vinculados con umbral y método de verificación
[ ] Criterios BDD revisados y comprobables
[ ] Dependencias con otras historias o sistemas visibles
[ ] Tamaño estimable por el equipo sin información adicional
NOTA: Ordena la lista por prioridad MoSCoW. Dentro del mismo nivel, ubica primero la historia con mayor valor y menor riesgo.Ahora con tu historia
Genera un mapa inicial de construcción
Escribe decisiones ya conversadas. El resultado propone preguntas y responsabilidades; no genera SQL, endpoints ni pantallas definitivas.
Borrador generado
Mapa del incremento para revisar
Siguiente estación: usa este mapa para justificar la arquitectura, seleccionar tecnologías y dividir el trabajo del equipo.
Continuar a arquitectura07 · Vista de sistema
Una aplicación es un flujo. No solo una pantalla.
La arquitectura general muestra quién consume el sistema, dónde vive cada responsabilidad y cómo circulan los datos.
Vocabulario antes del diagrama
DNS ubica el destino de un nombre web; HTTPS transporta solicitudes cifradas; una API define cómo se comunican los componentes; un proxy inverso recibe y dirige el tráfico; y un VPS es un servidor virtual donde puede ejecutarse la solución. Sus nombres completos están en el diccionario inicial.
01 · EntradaUsuario / navegador / móvilInterfaz, sesión y acciones del usuario
02 · Borde de redSistema DNS · conexión HTTPS · proxy inversoUbica el destino, recibe solicitudes, cifra el tránsito y dirige el tráfico
03 · Aplicación
Interfaz web (frontend)presenta la experiencia
Servicio de aplicación (backend y API)aplica reglas de negocio
Proceso de tareas (worker)ejecuta trabajos en segundo plano
04 · Estado
Base de datosinformación estructurada
Memoria temporal (caché) y colavelocidad y trabajos pendientes
Archivosimágenes y documentos
↗Integracionescorreo, pagos, mapas o proveedor de IA mediante API
◌Operaciónregistros técnicos, métricas, alertas, copias de seguridad y recuperación
05 · PlataformaServidor Privado Virtual (VPS) o nube · Docker · CoolifyLa infraestructura aloja; Docker empaqueta; Coolify despliega y opera la aplicación.
De la arquitectura al despliegue
Cada herramienta responde una decisión técnica.
Primero se define el requisito de calidad; después se elige la plataforma que puede demostrarlo con evidencia.
01
Dónde se ejecuta
Nube y Servidor Privado Virtual (VPS)
La nube ofrece cómputo, red y almacenamiento bajo demanda. Un VPS es un servidor virtual concreto dentro de esa infraestructura, con Unidad Central de Procesamiento (CPU), memoria, disco y sistema operativo administrables.
Decisión vinculadaCapacidad, disponibilidad, costo, cortafuegos de red y copias de seguridad.
02
Cómo se empaqueta
Docker
Convierte la aplicación y sus dependencias en una imagen reproducible. Cada contenedor ejecuta esa imagen con la misma configuración acordada por el equipo.
Decisión vinculadaVersiones, puertos, variables, persistencia y límites de recursos.
03
Cómo se despliega y opera
Coolify
Se instala sobre el servidor, conecta el repositorio y coordina servicios Docker, variables, dominios y HTTPS. Simplifica la operación, pero no sustituye monitoreo, actualizaciones ni recuperación.
Decisión vinculadaAutomatización del despliegue, secretos, certificados, registros técnicos y reversión a una versión estable.
Flujo de entrega
Del cambio versionado a una aplicación disponible
01GitCódigo, Dockerfile y configuración versionada
→
02CoolifyDetecta el cambio y prepara el despliegue
→
03DockerConstruye la imagen y ejecuta el contenedor
→
04VPS + dominioPublica con HTTPS, persistencia y observabilidad
Flujo de una petición
- El navegador resuelve el dominio y abre una conexión segura HTTPS.
- El intermediario de red envía la solicitud a la interfaz web o a la API.
- La API valida identidad y reglas; consulta datos o llama a un servicio externo.
- La respuesta vuelve al cliente y la operación queda registrada en los registros técnicos.
Qué debe decidir el equipo
- Responsabilidades: qué pertenece a la interfaz, al servicio de aplicación y a la base de datos.
- Datos: qué es persistente, qué puede perderse y qué debe respaldarse.
- Escala: cuántos usuarios, solicitudes y archivos se esperan.
- Riesgo: qué pasa si falla la base de datos, el proveedor de Inteligencia Artificial o el servidor virtual.
La Inteligencia Artificial como apoyo arquitectónico
La IA puede ayudar a explorar alternativas, convertir restricciones en preguntas y proponer pruebas. Una instrucción útil entrega contexto y pide evidencia:
Contexto: aplicación web con interfaz, API y base de datos PostgreSQL.
Restricción: desplegar con Docker en un VPS usando Coolify.
Tarea: propone arquitectura, riesgos, RNF y pruebas.
No inventes secretos; justifica cada decisión.Revisa la propuesta con requisitos, pruebas de carga, seguridad y presupuesto antes de aplicarla.
A-01 Cómo producir un diagrama de arquitectura que ayude a construir Recurso de apoyo opcional: permite revisar responsabilidades, datos y dependencias del corte vertical. No es un componente obligatorio del producto entregable. Abrir apoyo
Primero la evidencia; después el dibujo
Representa una sola historia de extremo a extremo
El objetivo no es decorar el documento ni adivinar tecnologías. El diagrama debe permitir que otra persona identifique quién inicia la acción, qué responsabilidad atiende cada parte, qué datos circulan, dónde se aplica una regla y qué podría fallar.
Cuándo usarlo
Úsalo si el equipo necesita aclarar una integración, separar responsabilidades o conversar una decisión técnica. Si una tabla o el lienzo de construcción ya lo explica, no dupliques información.
Antes de dibujar, reúne estos insumos de la guía
- una Historia de Usuario priorizada y su Requisito Funcional;
- criterios de aceptación para éxito y error;
- reglas, permisos, datos de entrada y resultado esperado;
- un Requisito No Funcional medible y las dependencias conocidas.
Si falta un dato, escríbelo como pregunta abierta. No lo reemplaces por una tecnología inventada.
- 01Delimita el corte
Escribe arriba el identificador de la historia y una oración con inicio y resultado: “El guarda consulta el código QR y obtiene una decisión registrada”.
- 02Ubica actores y sistemas externos
Dibuja solo personas, dispositivos o servicios que envían o reciben información en esa historia. Lo que no participa queda fuera.
- 03Agrupa responsabilidades
Crea únicamente los bloques necesarios: interfaz, coordinación del caso de uso, reglas del dominio, datos e integración. Nómbralos por lo que hacen, no por un producto tecnológico.
- 04Traza el flujo y sus fallos
Conecta los bloques en orden. Etiqueta cada flecha con el dato o resultado que circula e incluye al menos un camino de error o rechazo.
- 05Vincula la especificación
Anota junto a bloques y flechas los identificadores relacionados:
RF-*,RN-*,RNF-*,CA-*oPR-*. Así cada elemento tiene una razón verificable. - 06Revisa y marca el estado
Señala qué está validado, qué es candidato y qué sigue abierto. Registra revisor y fecha. Exporta o comparte el diagrama solo si mejora la conversación del equipo.
Ejemplo resuelto · HU-03
Guarda envía código QR → Consultar ingreso valida permiso y vigencia (RF-03, RN-02) → Registro de ingresos devuelve estado → la interfaz muestra autorizado o rechazado y registra auditoría (CA-03, RNF-03).
Pregunta abierta: ¿qué respuesta debe ofrecerse si el servicio de códigos QR no está disponible?
Plantilla de cada bloque
Responsabilidad: [verbo + resultado]
Entrada / salida: [dato que recibe / resultado que entrega]
Fuente: [RF, regla, criterio o prueba]
Estado: [validado / candidato / pregunta abierta]
Tecnología: [solo si ya fue decidida y justificada]
El diagrama es útil cuando otra persona puede responder “sí” a todo:
- ¿Se entiende el recorrido completo de una historia?
- ¿Cada bloque tiene una responsabilidad distinta y una fuente?
- ¿Las flechas dicen qué dato o resultado circula?
- ¿Aparece al menos un error, permiso o dependencia relevante?
- ¿Las decisiones candidatas están separadas de las validadas?
Herramienta: puedes usar papel, tablero, diagrams.net, Excalidraw o formas de una presentación. La calidad se evalúa por la claridad y la trazabilidad, no por la aplicación elegida.
Idea central: los requisitos dicen qué debe lograrse; la arquitectura organiza responsabilidades; la infraestructura aporta el entorno donde el sistema puede ejecutarse, observarse y recuperarse.
08 · Evidencia final integradora
Construye tu primer corte vertical documentado.
Práctica principal05 incrementos
De la Guía 1 a la base del software
Esta evidencia reúne todo el aprendizaje de la ruta.
No se trata de entregar pantallazos ni de inventar una aplicación completa. Ejecutarás una práctica incremental: recuperarás evidencia, precisarás una necesidad, comprobarás su comportamiento y dejarás preparado el primer corte que luego podrá prototiparse y construirse.
Producto centralUn paquete técnico donde una necesidad puede seguirse desde su fuente hasta una prueba y una tarea de construcción.
| Incremento | Ejecuta el aprendiz | Entrega y criterio de avance |
|---|---|---|
| 01Retomar la Guía 1 | Selecciona un hallazgo validado, revisa el SIPOC/AS-IS, identifica actores y separa hechos de preguntas. | CTX-01 + E-*La fuente, el alcance y las preguntas abiertas están visibles. |
| 02Organizar el dominio | Completa glosario, reglas, roles y permisos; identifica las historias necesarias y prioriza una para el corte. | GLOS-* + RN-* + HU-*La historia priorizada expresa valor, tiene alcance pequeño y conserva su origen. |
| 03Especificar comportamiento | Deriva los RF y RNF que necesita la historia priorizada; define criterios BDD de éxito y situaciones no exitosas, y completa su ficha de caso de uso. | RF-* + RNF-* + CA-* + CU-*Entradas, reglas, resultados y excepciones pueden ser revisados por otra persona. |
| 04Comprobar coherencia | Construye trazabilidad, plan de pruebas y realiza una revisión con un par, instructor o interesado. | PR-* + matriz de trazabilidadLa prueba demuestra el criterio y registra pasa/falla. |
| 05Preparar construcción | Define datos de entrada y salida, estados de interfaz, responsabilidades, dependencias, preguntas abiertas y una tarea priorizada. | BL-01 + ficha de construcciónEl corte cumple la Definición de Listo para Iniciar y el equipo no necesita inventar comportamiento para comenzar. |
Puerta de calidad de la evidencia finalEl documento no se considera completo si contiene capítulos aislados. Debe mostrar al menos una cadena completa:
E-* → CTX-* → HU-* → RF/RNF-* → CA-* → PR-* → BL-*.Transferencia a la Guía 3Entrega la historia priorizada, sus criterios BDD, datos candidatos, estados de interfaz y preguntas de validación para que el prototipo pueda comprobar el comportamiento definido aquí.
Hallazgo de la Guía 1 · contexto por precisar
“En la garita, el guarda verifica el QR, llama al encargado y anota el ingreso cuando el visitante trae equipos.”
El hallazgo describe una situación real, pero todavía hay que precisar el objetivo de la persona, el resultado que debe observarse y qué ocurre cuando el QR está vencido o no hay permiso.
03
Tu misión · checkpoint del incremento 03
Convierte el hallazgo en comportamiento comprobable
Paso 1: Ve al laboratorio y configura la Historia de Usuario para el rol guarda que necesita consultar un ingreso mediante su código QR para reducir la espera y tomar una decisión trazable. Después, arma el escenario BDD con autorización, escaneo y resultado visible.
Paso 2: Vuelve aquí, valida el checkpoint y copia el resultado en el capítulo de la evidencia final que corresponde a HU-03, CA-03 y su relación con E-OBS-03.
Puerta de calidadHistoria completa + Dado / Cuando / Entonces + fuente conservada
Formación SENA por Proyectos
Evidencia final y producto entregable
En la metodología de Formación por Proyectos del Servicio Nacional de Aprendizaje (SENA), esta evidencia demuestra que puedes avanzar desde información recolectada hasta una base de software construible. El documento final debe mostrar los cinco incrementos, no solo el resultado de los simuladores: cada capítulo recibe el anterior, agrega una decisión y deja un producto reutilizable para la Guía 3.
Mapa de estudio y producción
La base de conocimiento termina en una evidencia transferible
Usa esta secuencia para saber qué leer, qué practicar y qué evidencia guardar. No entregues pantallazos sueltos: cada resultado debe quedar dentro del PDF técnico.
01 · TEORÍA
Entiende los conceptos
Contexto, actores, historias, RF, RNF, BDD, datos, responsabilidades y trazabilidad.
Ir a fundamentos y ruta →
02 · FORMATOS
Copia las plantillas
Instrumentos I-00 a I-07: glosario, historias, requisitos, aceptación, trazabilidad, pruebas y lista de trabajo pendiente.
Ir a instrumentos →
03 · EJERCICIOS
Construye y valida
Practica con los retos guiados, los constructores de historias y escenarios, el caso de uso y el detector de ambigüedad; copia los resultados al documento.
Ir al laboratorio →
04 · EVIDENCIA
Ejecuta la evidencia final
Completa los cinco incrementos, revisa la trazabilidad y entrega un primer corte vertical documentado para la Guía 3.
Ir al reto final →
🛠️
De cada sección sale una parte del producto
- Entrada de la Guía 1 + I-00: contexto, alcance, fuente, términos, reglas y permisos que evitan construir sobre supuestos.
- I-01 a I-04: historia priorizada, requisitos necesarios, calidad medible, criterios de aceptación y ficha de caso de uso que describen el comportamiento.
- Laboratorio y simuladores: práctica guiada para corregir ambigüedad y comprobar historias, escenarios y excepciones antes de llevarlos al documento.
- I-05 e I-06: trazabilidad y pruebas con datos, resultado esperado y condición de aprobación para que control de calidad pueda verificar el corte.
- Lienzo de construcción + I-07: datos, estados, responsabilidades, dependencias, tarea priorizada y Definición de Listo para Iniciar para que el equipo pueda comenzar.
📦
Producto a entregar: paquete mínimo listo para construcción
Consolida un documento técnico en Formato de Documento Portátil (PDF). Su unidad de trabajo es un corte vertical priorizado: una capacidad pequeña que atraviesa interfaz, reglas, datos y pruebas. El producto está completo cuando desarrollo, diseño y pruebas pueden continuar sin inventar comportamiento, aunque existan decisiones técnicas registradas como pendientes.
-
✅
Portada y control de versión: Datos del Proyecto Formativo, aprendices, ficha, centro de formación, versión, fecha y responsable de cada revisión.
Ver campos requeridos en la portada →
Usa el membrete oficial del SENA. La portada debe contener todos estos campos, en este orden:
SERVICIO NACIONAL DE APRENDIZAJE — SENA Regional: [nombre de la regional] Centro de Formación: [nombre del centro, ej. Centro Agroempresarial] ───────────────────────────────────────── TÍTULO DEL DOCUMENTO Especificación de Requisitos de Software y Diseño de Arquitectura — GA2-220501093-AA1-EV02 ───────────────────────────────────────── PROGRAMA DE FORMACIÓN Análisis y Desarrollo de Software (ADSO) Código: 228118 Versión: 1 FICHA DE CARACTERIZACIÓN Número de ficha: [xxxx] Modalidad: [Presencial / Virtual / Mixta] Jornada: [Mañana / Tarde / Noche] PROYECTO FORMATIVO Nombre del proyecto: [nombre completo del proyecto] Fase del proyecto: Análisis Actividad: Especificar y validar los requisitos del sistema de información. APRENDICES 1. Primer Nombre Completo — Documento: [tipo] [número] 2. Segundo Nombre Completo — Documento: [tipo] [número] (repetir para cada integrante del equipo) INSTRUCTOR(A) Nombre: [nombre completo del instructor] Especialidad: Análisis y Desarrollo de Software FECHA DE ENTREGA [Ciudad], [día] de [mes] de [año] - ✅ 01 · Contexto y alcance del corte: hallazgo y fuente de la Guía 1, problema, objetivo, actor, incluido, fuera de alcance, restricciones y preguntas abiertas. Debe distinguir hechos validados de supuestos.
- ✅ 02 · Lenguaje y necesidad priorizada: términos indispensables, reglas, permisos e historias identificadas; selecciona una Historia de Usuario pequeña y valiosa para desarrollar de extremo a extremo. Usa I-00 e I-01.
- ✅ 03 · Contrato de comportamiento: Requisitos Funcionales y No Funcionales necesarios para la historia, prioridad, criterios de aceptación de éxito y situaciones no exitosas, y ficha de caso de uso. La cantidad depende del comportamiento; la evidencia mínima exige una cadena completa y verificable. Usa I-02, I-03 e I-04.
- ✅ 04 · Verificación y trazabilidad: matriz que conecta fuente, historia, requisito, criterio, prueba y tarea; casos de prueba con datos, resultado esperado y condición de aprobación; y registro de la revisión. Usa I-05 e I-06.
- ✅ 05 · Ficha lista para construcción: entradas y salidas, datos que deben conservarse, reglas, permisos, estados de interfaz, responsabilidades, dependencias, riesgos, preguntas pendientes y una tarea priorizada con Definición de Listo para Iniciar. Usa el lienzo de construcción e I-07.
- ✅ 06 · Control de cambios y validación: versión, fecha, responsables, comentarios recibidos, decisión tomada y asuntos que todavía requieren confirmación del interesado, instructor o equipo.
- ✅ 07 · Bitácora humano–IA: declaración de uso o no uso. Si se utilizó IA, incluye propósito, datos protegidos, salida, verificación, riesgos, decisión humana, responsable y fecha.
El diagrama no forma parte del producto mínimo.
El apoyo A-01 de arquitectura se usa solo cuando aclara responsabilidades o integraciones, o cuando el instructor lo solicita de manera expresa. Una imagen no reemplaza la ficha de construcción, la trazabilidad ni las pruebas.
DiseñoPuede prototipar
Conoce actor, objetivo, datos, estados de interfaz, mensajes y excepciones.
DesarrolloPuede estimar y comenzar
Conoce entradas, reglas, salidas, permisos, responsabilidades, dependencias y límites.
PruebasPuede verificar
Conoce criterios, datos de prueba, resultado esperado, umbral y condición de aprobación.
Copiar estructura completa del documento final
Usa esta estructura como índice y reemplaza los campos entre corchetes. Agrega filas cuando el comportamiento lo requiera; no agregues artefactos solo para aumentar el volumen.
PAQUETE MÍNIMO DE ESPECIFICACIÓN LISTO PARA CONSTRUCCIÓN
Evidencia: GA2-220501093-AA1-EV02
Proyecto: [nombre] Versión: [x.x] Fecha: [año-mes-día]
Responsables: [nombres] Estado: [borrador / revisado / validado]
1. CONTEXTO Y ALCANCE DEL CORTE
Hallazgo y fuente: [E-* + dato observable + fecha]
Problema / objetivo: [situación actual / cambio esperado]
Actor principal: [rol]
Incluido: [capacidad que sí se trabajará]
Fuera de alcance: [lo que no se trabajará]
Restricciones y preguntas abiertas: [dato + responsable + estado]
2. LENGUAJE Y NECESIDAD PRIORIZADA
Términos indispensables: [GLOS-*]
Reglas y permisos: [RN-* + rol + acción autorizada]
Historia priorizada: [HU-* · Como / quiero / para]
Prioridad y fuente: [MoSCoW + E-* / CTX-*]
3. CONTRATO DE COMPORTAMIENTO
Requisitos funcionales necesarios: [RF-* · entrada / regla / salida / excepción]
Requisitos no funcionales necesarios: [RNF-* · medida / umbral / condición / verificación]
Criterios de aceptación: [CA-* · éxito + situaciones no exitosas relevantes]
Caso de uso: [CU-* · precondición / flujo / alternativa / postcondición]
4. VERIFICACIÓN Y TRAZABILIDAD
Cadena: [E-* → CTX-* → HU-* → RF/RNF-* → CA-* → PR-* → BL-*]
Pruebas: [PR-* · datos / pasos / resultado esperado / condición de aprobación]
Resultado de revisión: [observación / decisión / responsable]
5. FICHA LISTA PARA CONSTRUCCIÓN
Entradas y salidas: [datos recibidos / resultado observable]
Datos que se conservan: [concepto / identificador / relación / sensibilidad]
Estados de interfaz: [inicial / cargando / éxito / vacío / error / sin permiso]
Responsabilidades: [interfaz / caso de uso / regla / datos / integración]
Dependencias y riesgos: [dependencia / fallo esperado / respuesta]
Tarea priorizada: [BL-* · título / alcance / criterios / pruebas / tamaño]
Definición de Listo para Iniciar: [cumple / no cumple + condición pendiente]
6. BITÁCORA HUMANO–IA
Uso: [no utilizada / utilizada]
Artefacto y propósito: [qué se apoyó y para qué]
Datos compartidos y protección: [anonimización / exclusiones]
Salida y verificación: [resultado / fuentes / pruebas / personas]
Riesgos y decisión humana: [aceptar / modificar / rechazar + motivo]
Responsable y fecha: [nombre / rol / fecha]
7. VALIDACIÓN Y CONTROL DE CAMBIOS
Revisó: [persona y rol] Fecha: [año-mes-día]
Observaciones: [comentarios]
Cambios aceptados: [decisión y motivo]
Pendientes no bloqueantes: [pregunta + responsable + fecha esperada]
Próximo uso: [qué recibe la Guía 3 para prototipar y validar]Ruta mínima del aprendiz
Qué hacer en orden para producir el PDF
| Paso | Estudia y revisa | Ejercicio en la web | Guarda en el PDF |
|---|---|---|---|
| 01Retomar Guía 1 | Paquete de entrada | Selecciona un hallazgo y revisa su fuente, alcance y preguntas. | Contexto, fuentes, preguntas abiertas y alcance. |
| 02Organizar | I-00 e I-01 | Construye glosario, reglas, permisos e historias; prioriza una. | Lenguaje acordado y una historia pequeña, valiosa y trazable. |
| 03Especificar | Requisitos y criterios BDD | Deriva lo necesario para la historia, valida el checkpoint y completa el caso de uso. | RF/RNF, criterios de aceptación, excepciones y caso de uso. |
| 04Comprobar | I-05 e I-06 | Relaciona evidencia, requisito, criterio, prueba y tarea; luego practica la revisión en el laboratorio. | Matriz, plan de pruebas y registro de revisión. |
| 05Preparar | Lienzo e I-07 | Define datos, estados, responsabilidades, dependencias y la tarea priorizada. | Ficha de construcción y primer corte con Definición de Listo para Iniciar. |
| 06Entregar | Evidencia final | Integra la cadena, completa la bitácora humano–IA, registra la revisión y aplica el control de calidad. | PDF y paquete reutilizable por diseño, desarrollo y pruebas. |
Antes de subir
Control de calidad del producto entregable
- El documento identifica un solo corte vertical prioritario y explica por qué aporta valor.
- La cadena
E → HU → RF/RNF → CA → PR → BLestá completa; cada vínculo puede comprobarse. - Los Requisitos Funcionales declaran entrada, regla, salida y excepción; los Requisitos No Funcionales declaran medida, umbral, condición y método de verificación.
- Los criterios y pruebas cubren el éxito y las situaciones no exitosas relevantes, incluidos permisos o dependencias cuando aplican.
- La ficha de construcción define datos, estados, responsabilidades y límites sin convertir decisiones pendientes en hechos.
- La tarea priorizada cumple la Definición de Listo para Iniciar: es pequeña, estimable, trazable, comprobable y no tiene una pregunta bloqueante.
- La revisión registra quién participó, qué observó y qué cambió; no quedan marcadores como
[completar]. - La bitácora declara el uso o no uso de IA; toda salida utilizada muestra cómo fue verificada y qué decidió la persona responsable.
- El PDF se abre correctamente, usa la nomenclatura solicitada y permite continuar en la Guía 3 sin volver a levantar la misma información.
📤
Protocolo y Nomenclatura de Entrega SENA
Sube tu documento en Formato de Documento Portátil (PDF) al Sistema de Gestión del Aprendizaje (LMS), por ejemplo Zajuna o Territorium, en la actividad correspondiente a:
Evidencia: GA2-220501093-AA1-EV02 — Especificación de requisitos de software y diseño inicial de arquitectura con criterios BDD
Nomenclatura recomendada del archivo: GA2-220501093-AA1-EV02_PrimerNombre_PrimerApellido.pdf
GA2-220501093-AA1-EV02 es el identificador institucional de la evidencia. Consérvalo exactamente como lo indique el instructor o la plataforma; esta guía no inventa ni modifica su significado curricular.