Presentación — Unidad II
Al finalizar esta unidad podrás
Section titled “Al finalizar esta unidad podrás”Derivar requisitos funcionales, no funcionales y reglas de negocio verificables.
Construir criterios de aceptación y escenarios a partir de casos de uso o historias de usuario.
Establecer relaciones requisito–prueba y prueba–defecto, y construir una matriz de trazabilidad.
Antes de empezar
Section titled “Antes de empezar”En la Unidad 1 aprendiste por qué se prueba: para reducir riesgo y aumentar la confianza en el software.
Pero antes de poder probar algo, hace falta responder una pregunta previa:
¿qué, exactamente, debe probarse?
Una situación
Section titled “Una situación”Un equipo construye un formulario de registro de usuarios. Al entregarlo, alguien reporta que “no valida bien los correos”. El equipo responde que “sí funciona, así lo pidieron”. Nadie escribió, antes de construirlo, qué significaba “validar bien” un correo.
Pregunta orientadora
Section titled “Pregunta orientadora”Mapa de la unidad
Section titled “Mapa de la unidad”Qué debe hacer el sistema y qué reglas debe respetar.
Cómo se describe una interacción y cuándo se considera “cumplida”.
Cómo se relaciona cada requisito con lo que se probó de él.
El pipeline completo de la unidad
Section titled “El pipeline completo de la unidad”
Cada flecha es un bloque de esta unidad, al final vas a recorrer este mismo camino dos veces con ejemplos distintos.
Para pensarlo antes de empezar
Section titled “Para pensarlo antes de empezar”Retomando la situación del formulario de registro: ¿qué tendría que haber escrito el equipo, antes de construirlo, para que “validar bien un correo” fuera una condición verificable y no una opinión?
Bloque 1 — Los requisitos como base de las pruebas
Section titled “Bloque 1 — Los requisitos como base de las pruebas”Antes de diseñar una prueba necesitamos saber:
¿Qué debe cumplir el producto y por qué?
¿Qué problema estamos intentando resolver?
Section titled “¿Qué problema estamos intentando resolver?”Un equipo recibe la petición:
“Necesitamos que los estudiantes puedan inscribirse fácilmente a sus materias.”
El equipo comienza a desarrollar.
Cuando entrega el sistema, alguien pregunta:
“¿Por qué no permite inscribirse a este estudiante?”
El desarrollador responde:
“Porque no cumple el prerrequisito.”
El usuario responde:
“Pero eso nunca se había dicho.”
El problema comenzó antes de programar.
No existía una definición suficientemente clara de lo que debía cumplirse.
Antes del requisito existe una necesidad
Section titled “Antes del requisito existe una necesidad”Necesidad
Expresa algo que un stakeholder necesita lograr o que debe resolverse.
Requisito
Expresa de forma precisa qué debe cumplirse para responder a esa necesidad.
Prueba
Proporciona evidencia de que una condición definida se cumple.
Basado en ISO/IEC/IEEE 29148 e INCOSE Needs and Requirements Manual.
De una necesidad a un requisito
Section titled “De una necesidad a un requisito”Una necesidad todavía no es un requisito.
La necesidad expresa qué necesita lograr alguien.
El requisito expresa qué condición debe cumplir la solución para responder a esa necesidad.
El estudiante necesita saber si todavía puede cancelar su inscripción.
El sistema deberá informar si la cancelación se encuentra dentro del plazo permitido.
Comprobar el comportamiento cuando la solicitud ocurre antes, exactamente en y después del límite.
¿De dónde vienen los requisitos?
Section titled “¿De dónde vienen los requisitos?”Stakeholders
Usuarios, clientes, administradores, operadores y otras personas afectadas por el producto.
Negocio y procesos
Objetivos, políticas, procedimientos, reglas y restricciones de la organización.
Entorno
Leyes, reglamentos, normas, contratos, riesgos y condiciones externas.
Arquitectura y tecnología
Restricciones, interfaces, plataformas y decisiones que condicionan la solución.
Riesgos
Amenazas, fallos potenciales, seguridad, privacidad y continuidad.
Otros requisitos
Requisitos de niveles superiores que deben transformarse o descomponerse.
Un requisito debe poder responder una pregunta fundamental:
¿De dónde salió y qué necesidad o condición justifica que exista?
¿Quién define un requisito?
Section titled “¿Quién define un requisito?”No existe una única persona que “escriba todos los requisitos”.
La definición de requisitos es una actividad colaborativa en la que participan diferentes stakeholders y responsables del producto.
| Participante | Contribución posible |
|---|---|
| Cliente / negocio | Necesidades y objetivos |
| Usuario | Necesidades operativas |
| Analista / ingeniería de requisitos | Elicitación, análisis y documentación |
| Product Owner | Valor, alcance y prioridades |
| Seguridad | Requisitos de protección y controles |
| Área legal | Obligaciones regulatorias |
| Arquitectura | Restricciones e interfaces |
| Pruebas | Verificabilidad, ambigüedades y cobertura |
Importante: quien redacta un requisito no necesariamente es quien tiene autoridad para decidir que esa necesidad es obligatoria.
Necesidad, requisito y decisión técnica
Section titled “Necesidad, requisito y decisión técnica”Necesidad
El estudiante necesita conocer por qué no puede inscribirse.
Requisito
El sistema debe informar la condición que impide completar la inscripción.
Implementación
El equipo decide mostrar el motivo mediante un mensaje en pantalla.
No debemos confundir qué necesita cumplirse con cómo decidimos implementarlo.
Los requisitos existen en diferentes niveles
Section titled “Los requisitos existen en diferentes niveles”¿Qué necesita lograr la organización?
¿Qué necesita el usuario o actor involucrado?
¿Qué debe cumplir la solución?
¿Qué debe cumplir el componente de software?
Un requisito debe redactarse en el nivel de abstracción apropiado. No todo requisito tiene como sujeto al “sistema” y no todo requisito debe describir una decisión técnica.
ISO/IEC/IEEE 29148, INCOSE Systems Engineering Handbook.
Un mismo problema visto en diferentes niveles
Section titled “Un mismo problema visto en diferentes niveles”Necesidad del stakeholder
El estudiante necesita conocer oportunamente por qué no puede completar una inscripción.
Requisito del sistema
La solución debe informar la condición que impide completar la inscripción.
Requisito de software
El módulo de inscripción debe mostrar el prerrequisito incumplido cuando la validación falle.
Implementación
El equipo decide mostrar un mensaje junto al botón "Inscribirme".
Cada nivel responde una pregunta diferente.
Necesidad → qué se necesita.
Requisito → qué debe cumplirse.
Diseño → cómo se realizará.
¿Qué es un requisito?
Section titled “¿Qué es un requisito?”Un requisito es una expresión precisa de una necesidad, condición o restricción que debe satisfacerse.
Capacidad
Algo que el producto debe hacer o proporcionar.
Característica
Una propiedad o nivel de calidad que debe alcanzarse.
Restricción
Una condición, regla o limitación que debe respetarse.
Para que sea útil para pruebas, el requisito debe permitir determinar objetivamente si se cumple.
¿Por qué muchos requisitos utilizan “shall”?
Section titled “¿Por qué muchos requisitos utilizan “shall”?”INCOSE recomienda utilizar shall en una declaración formal de requisito para indicar que se trata de una condición obligatoria que será objeto de verificación.
Ejemplo
Section titled “Ejemplo”The system shall allow an authenticated student to submit an enrollment request.
En español podemos expresarlo como:
El sistema deberá permitir que un estudiante autenticado envíe una solicitud de inscripción.
“Debe”, “deberá” o “shall” no convierten mágicamente una frase en un buen requisito. La declaración todavía debe ser necesaria, correcta, clara, factible y verificable.
INCOSE Guide to Writing Requirements v4, 2023.
“Debe” no es la definición de requisito
Section titled ““Debe” no es la definición de requisito”| Redacción | Problema |
|---|---|
| El sistema debe ser fácil de usar | “Fácil” no está definido |
| El sistema debe funcionar rápido | “Rápido” no es medible |
| El sistema debe manejar errores correctamente | No define qué significa correctamente |
| El sistema debe permitir la inscripción | Puede faltar información sobre las condiciones |
La pregunta no es:
“¿Tiene la palabra debe?”
La pregunta es:
“¿Podemos determinar con precisión qué condición debe cumplirse?”
Del lenguaje cotidiano al requisito
Section titled “Del lenguaje cotidiano al requisito”Petición
"La inscripción debe ser rápida y sencilla."
Pregunta del analista
¿Qué significa "rápida"? ¿Para quién? ¿En qué condiciones? ¿Cómo se medirá?
Posible requisito
Section titled “Posible requisito”El sistema deberá mostrar los grupos disponibles en un tiempo máximo de 2 segundos bajo una carga de hasta 100 usuarios concurrentes.
La segunda redacción proporciona una condición que posteriormente puede ser verificada.
¿Qué hace que un requisito esté bien formado?
Section titled “¿Qué hace que un requisito esté bien formado?”Existe una razón que justifica su existencia.
Representa adecuadamente la necesidad o fuente de la que proviene.
Puede interpretarse de una sola manera razonable.
Puede cumplirse dentro de las restricciones conocidas.
Puede demostrarse objetivamente si se cumple.
Puede relacionarse con su fuente y con la evidencia correspondiente.
Características sintetizadas a partir de INCOSE GtWR y Systems Engineering Handbook.
Un requisito no se evalúa solo
Section titled “Un requisito no se evalúa solo”Un requisito puede estar bien escrito individualmente y aun así formar parte de un conjunto de requisitos defectuoso.
Requisito individual
¿Es claro? ¿Es necesario? ¿Es correcto? ¿Es verificable? ¿Es factible?
Conjunto de requisitos
¿Está completo? ¿Es consistente? ¿Hay duplicados? ¿Hay contradicciones? ¿Cubren las necesidades?
La calidad debe revisarse tanto requisito por requisito como sobre el conjunto completo.
Ejemplo: dos requisitos que se contradicen
Section titled “Ejemplo: dos requisitos que se contradicen”| ID | Requisito |
|---|---|
| RF-01 | El sistema deberá permitir cancelar una inscripción hasta 24 horas antes del inicio del curso. |
| RF-02 | El sistema deberá permitir cancelar una inscripción en cualquier momento antes del inicio del curso. |
Ambos requisitos pueden parecer claros individualmente.
Juntos son inconsistentes.
La revisión de requisitos debe detectar contradicciones antes de que se conviertan en problemas de diseño o pruebas.
Ejemplo: un requisito incompleto
Section titled “Ejemplo: un requisito incompleto”El sistema deberá enviar una notificación al estudiante.
¿En qué situación?
¿A quién exactamente?
¿Por qué medio?
¿En cuánto tiempo?
¿Qué información debe contener?
¿Qué ocurre si el envío falla?
No necesariamente debemos agregar toda esa información dentro de una sola frase. Debemos determinar qué condiciones son necesarias para que el requisito pueda entenderse y verificarse.
Ejemplo: requisito demasiado grande
Section titled “Ejemplo: requisito demasiado grande”El sistema deberá permitir al estudiante consultar materias, seleccionar grupos, validar prerrequisitos, verificar disponibilidad, registrar la inscripción y enviar una confirmación por correo.
Aquí aparecen varios comportamientos diferentes.
Conviene descomponerlos para facilitar su análisis, diseño, verificación y trazabilidad.
Descomposición del requisito
Section titled “Descomposición del requisito”| ID | Requisito |
|---|---|
| RF-01 | El sistema deberá mostrar las materias disponibles para el estudiante. |
| RF-02 | El sistema deberá mostrar los grupos disponibles de una materia. |
| RF-03 | El sistema deberá validar los prerrequisitos de la materia. |
| RF-04 | El sistema deberá verificar la disponibilidad de lugares. |
| RF-05 | El sistema deberá registrar la inscripción cuando las condiciones se cumplan. |
| RF-06 | El sistema deberá enviar una confirmación después de registrar la inscripción. |
La descomposición permite que cada condición pueda analizarse y verificarse de manera independiente cuando corresponda.
Funcional, calidad y restricciones
Section titled “Funcional, calidad y restricciones”Funcional
Describe un comportamiento o capacidad.
¿Qué debe hacer?
Calidad
Describe una característica o nivel de desempeño.
¿Qué tan bien debe hacerlo?
Restricción
Limita las soluciones posibles o establece una condición obligatoria.
¿Qué debe respetar?
Estas categorías ayudan a analizar los requisitos, pero no deben entenderse como compartimentos completamente aislados.
Las cuatro categorías típicas de calidad (no funcionales)
Section titled “Las cuatro categorías típicas de calidad (no funcionales)”La consulta de grupos deberá responder en menos de 2 segundos bajo la carga definida.
La contraseña debe almacenarse cifrada, nunca en texto plano.
Un estudiante de primer ingreso deberá poder completar una inscripción sin ayuda externa en un máximo de 3 intentos.
El sistema de inscripción deberá estar disponible al menos el 99% del tiempo durante el periodo oficial de inscripciones.
El programa oficial (contenido 2.1.2) identifica estas cuatro categorías como ejemplos de requisitos no funcionales — no son las únicas posibles, pero son el punto de partida del Laboratorio 1.
Ejemplo integrado: inscripción
Section titled “Ejemplo integrado: inscripción”| Tipo | Requisito |
|---|---|
| Funcional | El sistema deberá registrar una inscripción cuando el estudiante cumpla las condiciones requeridas. |
| Calidad | La consulta de grupos deberá responder en menos de 2 segundos bajo la carga definida. |
| Restricción | Un estudiante no podrá inscribirse si no cumple los prerrequisitos. |
Ahora tenemos tres cosas diferentes que probar.
El comportamiento, la característica de calidad y la restricción.
¿Dónde quedan los requisitos de seguridad?
Section titled “¿Dónde quedan los requisitos de seguridad?”La seguridad puede expresarse como:
Bloquear una cuenta después de cinco intentos fallidos.
Proteger las credenciales de autenticación.
No almacenar contraseñas en texto plano.
Registrar los eventos relevantes de autenticación.
La seguridad puede generar requisitos funcionales, requisitos de calidad, restricciones y requisitos derivados de políticas, riesgos o regulación.
Ejemplo: derivar un requisito de seguridad
Section titled “Ejemplo: derivar un requisito de seguridad”El usuario necesita recuperar su cuenta.
Un atacante podría descubrir qué correos están registrados.
No revelar si un correo existe.
Comparar la respuesta para correos registrados y no registrados.
Los requisitos de seguridad pueden derivarse de riesgos y amenazas, no solamente de solicitudes explícitas de los usuarios.
Ejemplo aplicado: recuperación de contraseña
Section titled “Ejemplo aplicado: recuperación de contraseña”Situación
Section titled “Situación”Un usuario solicita recuperar su contraseña mediante su correo.
Riesgo
Section titled “Riesgo”Un atacante podría utilizar la respuesta del sistema para descubrir qué cuentas existen.
Requisito
Section titled “Requisito”El sistema deberá mostrar el mismo mensaje de respuesta tanto para una dirección registrada como para una dirección no registrada.
Criterio verificable
Section titled “Criterio verificable”Dado un correo registrado y uno no registrado, cuando se solicita la recuperación, entonces ambos deben producir una respuesta equivalente que no revele la existencia de la cuenta.
Otro requisito de seguridad
Section titled “Otro requisito de seguridad”Situación
Section titled “Situación”Un atacante puede intentar repetidamente autenticarse.
Riesgo
Section titled “Riesgo”Ataques de fuerza bruta contra las cuentas.
Requisito
Section titled “Requisito”El sistema deberá bloquear temporalmente una cuenta después de cinco intentos consecutivos de autenticación fallidos.
Criterio verificable
Section titled “Criterio verificable”Dado un usuario activo, cuando se realizan cinco intentos consecutivos con credenciales incorrectas, entonces el sistema deberá impedir nuevos intentos durante el periodo definido.
Los requisitos también pueden provenir de la regulación
Section titled “Los requisitos también pueden provenir de la regulación”Una obligación legal o normativa puede convertirse en una fuente de requisitos para el producto.
Regulación, contrato, norma o política.
La organización debe cumplir una obligación.
La solución debe implementar las condiciones necesarias para demostrar ese cumplimiento.
La fuente debe conservarse para poder responder posteriormente:
¿Por qué existe este requisito?
La trazabilidad comienza antes de la prueba
Section titled “La trazabilidad comienza antes de la prueba”| Requisito | Fuente | Justificación |
|---|---|---|
| RF-01 | Necesidad del estudiante | Permitir solicitar inscripción |
| RN-01 | Política académica | Respetar prerrequisitos |
| RS-01 | Análisis de riesgo | No revelar cuentas existentes |
| RNF-01 | Objetivo de desempeño | Respuesta dentro del tiempo definido |
La trazabilidad no significa solamente:
requisito → prueba
También puede comenzar como:
fuente → necesidad → requisito → prueba → evidencia
¿Cómo sabemos que un requisito está bien?
Section titled “¿Cómo sabemos que un requisito está bien?”No lo decidimos solamente porque “suena bien”.
Lo sometemos a verificación y validación de requisitos.
Verificación del requisito
¿Está bien escrito y posee las características necesarias para ser un requisito adecuado?
Validación del requisito
¿Representa realmente la necesidad que debía satisfacerse?
Aquí todavía estamos evaluando el requisito, no ejecutando el software.
INCOSE Needs and Requirements Manual, capítulos 5 y 7.
Verificación vs. validación
Section titled “Verificación vs. validación”Verificación
¿El requisito está expresado correctamente?
- ¿Es claro?
- ¿Es verificable?
- ¿Es factible?
- ¿Es consistente?
Validación
¿Es el requisito correcto?
- ¿Representa la necesidad?
- ¿Tiene una fuente válida?
- ¿Es necesario?
- ¿Conduce a la solución que se necesita?
¿Cómo se revisan los requisitos?
Section titled “¿Cómo se revisan los requisitos?”Personas expertas examinan los requisitos y buscan defectos.
Se comprueba sistemáticamente cada característica esperada.
Se recorren situaciones reales para descubrir omisiones y ambigüedades.
Se utiliza una representación para validar expectativas con stakeholders.
Se comprueba de dónde viene cada requisito y qué otros elementos depende.
Se analiza si puede definirse una forma objetiva de verificarlo.
Checklist de revisión de un requisito
Section titled “Checklist de revisión de un requisito”| Pregunta | Resultado |
|---|---|
| ¿Tiene una fuente identificada? | ☐ |
| ¿Es necesario? | ☐ |
| ¿Es correcto respecto a su fuente? | ☐ |
| ¿Es claro y no ambiguo? | ☐ |
| ¿Es completo para su propósito? | ☐ |
| ¿Es consistente con los demás? | ☐ |
| ¿Es factible? | ☐ |
| ¿Es verificable? | ☐ |
| ¿Tiene un identificador único? | ☐ |
| ¿Puede trazarse hasta su origen? | ☐ |
El checklist no sustituye el análisis. Ayuda a hacerlo sistemáticamente.
Aplicación: revisar un requisito defectuoso
Section titled “Aplicación: revisar un requisito defectuoso”RF-07: El sistema deberá permitir que el estudiante se inscriba rápidamente a cualquier materia que necesite.
Encuentra los problemas
Section titled “Encuentra los problemas”No hay métrica.
Ignora restricciones y prerrequisitos.
No existe una condición objetiva.
Mejorar el requisito
Section titled “Mejorar el requisito”RF-07
El sistema deberá permitir al estudiante solicitar la inscripción a una materia disponible cuando cumpla los prerrequisitos establecidos.
Actor, acción, condición y resultado esperado.
¿Qué significa "disponible"? ¿Cómo se comunica el resultado? ¿Existe alguna otra condición?
Un requisito mejor redactado no necesariamente está terminado.
La revisión puede descubrir nuevas preguntas.
Un requisito puede generar otros requisitos
Section titled “Un requisito puede generar otros requisitos”↓
El estudiante debe cumplir los prerrequisitos.
No debe excederse la capacidad del grupo.
Solo un usuario autenticado puede solicitar la inscripción.
Una necesidad puede producir un conjunto de requisitos relacionados.
Por eso también debemos evaluar el conjunto y no solamente cada frase.
Requisitos de seguridad: una visión más completa
Section titled “Requisitos de seguridad: una visión más completa”¿Qué debemos proteger?
¿Qué podría salir mal?
¿Qué impacto tendría?
¿Qué condición debe cumplirse?
Ejemplo
Section titled “Ejemplo”Activo: cuenta del estudiante
Amenaza: fuerza bruta
Riesgo: acceso no autorizado
Requisito: bloquear temporalmente después de cinco intentos fallidos
Del requisito a la prueba
Section titled “Del requisito a la prueba”Bloquear después de 5 intentos.
El quinto intento produce bloqueo.
Credenciales incorrectas cinco veces.
Comprobar que el sexto intento sea rechazado.
Aquí comienza a aparecer la relación que trabajaremos en los siguientes bloques:
Requisito → criterio → escenario → caso de prueba → evidencia
¿Qué debe poder responder un buen requisito?
Section titled “¿Qué debe poder responder un buen requisito?”Al terminar de analizar un requisito deberíamos poder responder:
¿Qué condición debe cumplirse?
¿Qué stakeholder o actor está involucrado?
¿Qué necesidad, riesgo, regla o fuente lo justifica?
¿Qué evidencia permitirá determinar que se cumple?
Banco de necesidades para construir requisitos
Section titled “Banco de necesidades para construir requisitos”Una necesidad describe algo que un stakeholder necesita lograr, conocer, proteger o controlar. A partir de ella, el equipo puede derivar requisitos.
| Contexto | Necesidad |
|---|---|
| Biblioteca | El estudiante necesita saber si un libro está disponible antes de acudir a solicitarlo. |
| Compras | El cliente necesita conocer el estado de su pedido sin contactar al soporte. |
| Transporte | El pasajero necesita conocer si su ruta tendrá servicio en el horario seleccionado. |
| Eventos | El organizador necesita controlar el número de asistentes registrados. |
| Clínica | El paciente necesita recibir confirmación de su cita y conocer cuándo debe acudir. |
| Restaurante | El cliente necesita saber si su pedido fue recibido y en qué estado se encuentra. |
| Plataforma educativa | El estudiante necesita conocer qué actividades tiene pendientes y sus fechas límite. |
| Soporte técnico | El usuario necesita saber qué ocurrió con la solicitud que reportó. |
No conviertas directamente estas frases en historias de usuario.
Primero identifica:
stakeholder → necesidad → requisito → interacción → criterio de aceptación
Actividad: detectar requisitos defectuosos
Section titled “Actividad: detectar requisitos defectuosos”Analiza los siguientes requisitos y marca qué problema presentan:
| Requisito | Problema |
|---|---|
| “El sistema debe ser muy rápido.” | |
| “El sistema debe manejar correctamente los errores.” | |
| “El sistema debe hacer todo lo necesario para registrar usuarios.” | |
| “El sistema debe permitir el acceso seguro.” | |
| “El sistema debe permitir cancelar y modificar y consultar y eliminar…” |
No los corrijas todavía.
Primero identifica qué característica del requisito está fallando.
Actividad: transformar requisitos
Section titled “Actividad: transformar requisitos”Selecciona dos de los requisitos anteriores.
Para cada uno:
- identifica la ambigüedad o problema
- determina qué información falta
- identifica una posible fuente o stakeholder
- redacta una nueva versión
- explica cómo podría verificarse.
Laboratorio 1 — requisitos y reglas de negocio
Section titled “Laboratorio 1 — requisitos y reglas de negocio”A partir del proyecto base asignado a tu equipo:
1. Identifica fuentes
Section titled “1. Identifica fuentes”Usuarios, negocio, políticas, riesgos, regulación u otras fuentes relevantes.
2. Identifica necesidades
Section titled “2. Identifica necesidades”¿Qué necesita lograr cada stakeholder?
3. Deriva requisitos
Section titled “3. Deriva requisitos”Redacta requisitos funcionales, de calidad y restricciones relevantes.
4. Identifica reglas de negocio
Section titled “4. Identifica reglas de negocio”¿Qué condiciones del dominio deben respetarse?
5. Identifica requisitos de seguridad
Section titled “5. Identifica requisitos de seguridad”¿Qué activos, amenazas o riesgos generan condiciones que el sistema debe cumplir?
Laboratorio 1 — revisión de calidad
Section titled “Laboratorio 1 — revisión de calidad”Antes de entregar tus requisitos, revisa cada uno:
| Criterio | ¿Cumple? |
|---|---|
| Tiene ID único | ☐ |
| Tiene fuente identificada | ☐ |
| Es necesario | ☐ |
| Es claro | ☐ |
| Es consistente | ☐ |
| Es factible | ☐ |
| Es verificable | ☐ |
| Puede trazarse | ☐ |
| Tiene criterios suficientes para probarlo | ☐ |
No entregues solamente una lista de requisitos.
Entrega también la evidencia de que fueron revisados.
Del Bloque 1 al Bloque 2
Section titled “Del Bloque 1 al Bloque 2”Ahora necesitamos convertir esos requisitos en condiciones que permitan decidir cuándo una funcionalidad puede considerarse aceptada.
Necesidades y requisitos
Criterios y escenarios
Trazabilidad
Bloque 2 — Casos de uso, historias de usuario y criterios de aceptación
Section titled “Bloque 2 — Casos de uso, historias de usuario y criterios de aceptación”Caso de uso
Section titled “Caso de uso”Un caso de uso describe una interacción completa entre un actor y el sistema: incluye un flujo principal y, cuando corresponde, flujos alternativos.
Ejemplo: actor “visitante”, flujo principal: envía datos válidos → el sistema crea la cuenta.
¿Dónde se define un caso de uso y cuándo se usa?
Section titled “¿Dónde se define un caso de uso y cuándo se usa?”En la etapa de análisis de requisitos, normalmente por quien levanta y documenta el requerimiento. Queda registrado en la especificación de requisitos del sistema.
Procesos con varios flujos alternos, varios actores, o contextos donde se necesita documentación formal y detallada.
Necesidades para construir casos de uso
Section titled “Necesidades para construir casos de uso”A partir de una necesidad, identifica:
actor → objetivo → interacción → resultado
| Contexto | Necesidad |
|---|---|
| Biblioteca | El estudiante necesita solicitar un libro que desea consultar. |
| Compras | El cliente necesita solicitar la devolución de un producto recibido en malas condiciones. |
| Educación | El profesor necesita registrar las calificaciones de sus estudiantes. |
| Eventos | El organizador necesita cancelar una inscripción cuando el evento fue suspendido. |
| Transporte | El pasajero necesita consultar si una ruta tiene servicio en una fecha determinada. |
| Soporte | El usuario necesita consultar el estado de un reporte que ya registró. |
Preguntas para construir el caso de uso
Section titled “Preguntas para construir el caso de uso”- ¿Quién tiene la necesidad?
- ¿Qué objetivo quiere alcanzar?
- ¿Con qué sistema interactúa?
- ¿Cuál es el flujo principal?
- ¿Qué puede salir diferente?
- ¿Qué resultado debe producirse?
¿Qué resuelve un caso de uso para las pruebas?
Section titled “¿Qué resuelve un caso de uso para las pruebas?”Le da al equipo de pruebas el flujo principal y los flujos alternativos completos de una interacción, de donde derivar escenarios sin tener que adivinar comportamientos que nadie describió por escrito.
Ejemplo completo: préstamo de un libro en biblioteca
Section titled “Ejemplo completo: préstamo de un libro en biblioteca”Un estudiante desea solicitar el préstamo de un libro disponible en la biblioteca universitaria.
Estudiante
Sistema de biblioteca
Registrar el préstamo cuando se cumplen las condiciones.
Flujo principal
Section titled “Flujo principal”- El estudiante se identifica.
- El sistema consulta su situación.
- El estudiante selecciona un libro disponible.
- El sistema verifica las condiciones de préstamo.
- El sistema registra el préstamo.
- El sistema informa la fecha de devolución.
Flujos alternativos
Section titled “Flujos alternativos”- El libro no está disponible.
- El estudiante tiene préstamos vencidos.
- El estudiante alcanzó el límite de préstamos.
- El ejemplar requiere una condición especial de consulta.
¿Quién es el actor?
Section titled “¿Quién es el actor?”Un actor es un rol externo que interactúa con el sistema para alcanzar un objetivo.
Estudiante
Está fuera del sistema y solicita una acción.
Sistema de biblioteca
Es el sistema que estamos describiendo. No es un actor de sí mismo.
Sistema de pagos / servicio externo
Podría ser actor si existe una interacción externa con el sistema de biblioteca.
La biblioteca como organización no es automáticamente un actor.
Si una persona que trabaja en la biblioteca interactúa con el sistema, el actor puede ser Bibliotecario.
Si otro sistema externo intercambia información con nuestro sistema, ese sistema puede modelarse como actor externo.
Actor, sistema y organización no son lo mismo
Section titled “Actor, sistema y organización no son lo mismo”Actor
Rol externo que interactúa con el sistema.
Ejemplos:
Estudiante
Bibliotecario
Administrador
Sistema bajo estudio
La solución cuyo comportamiento estamos describiendo.
Ejemplo:
Sistema de biblioteca
Sistema externo
Otro sistema que interactúa con el sistema bajo estudio.
Ejemplo:
Servicio de correo
El nombre “biblioteca” puede referirse a una organización, un lugar o un sistema. Para identificar un actor debemos describir el rol que interactúa externamente con el sistema.
Más ejemplos de casos de uso
Section titled “Más ejemplos de casos de uso”| Actor | Caso de uso (resumen) |
|---|---|
| Cliente | Solicitar devolución de un producto: indica el motivo → el sistema genera una guía de devolución |
| Administrador | Desactivar una cuenta de usuario: confirma la desactivación → el sistema revoca el acceso |
| Huésped | Reservar una habitación: elige fechas y tipo de habitación → el sistema confirma la disponibilidad y genera la reserva |
Actividad guiada — construir un caso de uso
Section titled “Actividad guiada — construir un caso de uso”Selecciona una de las siguientes necesidades:
| Opción | Necesidad |
|---|---|
| A | El estudiante necesita solicitar un libro disponible en la biblioteca. |
| B | El cliente necesita solicitar la devolución de un producto. |
| C | El usuario necesita consultar el estado de un reporte de soporte. |
| D | El profesor necesita registrar una calificación. |
Construye
Section titled “Construye”1. Actor principal
¿Quién tiene el objetivo?
2. Sistema
¿Con qué sistema interactúa?
3. Objetivo
¿Qué quiere conseguir?
4. Flujo principal
Escribe entre 4 y 6 pasos.
5. Dos flujos alternativos
¿Qué puede impedir o modificar el flujo principal?
6. Resultado
¿Qué debe quedar registrado o informado?
No necesitas dibujar todavía un diagrama UML.
Primero aprende a describir correctamente la interacción.
Historia de usuario
Section titled “Historia de usuario”Una historia de usuario (user story) describe la misma interacción en un formato breve, orientado al valor para el usuario:
Como visitante del sitio quiero registrarme con mi nombre, correo y contraseña para poder acceder a mi cuenta personal
¿Dónde se define una historia de usuario y cuándo se usa?
Section titled “¿Dónde se define una historia de usuario y cuándo se usa?”En el backlog del producto, normalmente redactada o priorizada por quien representa al negocio frente al equipo, junto con el equipo de trabajo.
Equipos con iteraciones cortas, donde se prioriza entregar valor incremental sobre documentación exhaustiva.
Más ejemplos de historias de usuario
Section titled “Más ejemplos de historias de usuario”Como cliente frecuente quiero ver mi historial de pedidos para repetir fácilmente una compra anterior
Como usuario que olvidó su contraseña quiero restablecerla desde mi correo para recuperar el acceso sin contactar a soporte
Del caso de uso a la historia de usuario
Section titled “Del caso de uso a la historia de usuario”Una misma necesidad puede expresarse de forma más detallada mediante un caso de uso o de forma breve mediante una historia de usuario.
Necesidad
Section titled “Necesidad”El estudiante necesita saber si un libro está disponible antes de acudir a la biblioteca.
Historia de usuario
Section titled “Historia de usuario”Como estudiante
quiero consultar la disponibilidad de un libro
para saber si puedo solicitarlo antes de acudir a la biblioteca.
Caso de uso
Section titled “Caso de uso”Consultar disponibilidad de libro
Actor: estudiante
Resultado: el sistema informa si existen ejemplares disponibles.
Caso de uso vs. historia de usuario
Section titled “Caso de uso vs. historia de usuario”| Caso de uso | Historia de usuario | |
|---|---|---|
| Formato | Actor, flujo principal, flujos alternos | Como / quiero / para |
| Extensión | Más detallado | Breve |
| Uso típico | Documentación formal | Equipos ágiles |
No son intercambiables ni equivalentes — son dos formas distintas de llegar al mismo insumo: qué debe cumplir el sistema.
Actividad guiada — construir historias de usuario
Section titled “Actividad guiada — construir historias de usuario”Transforma una de estas necesidades en una historia de usuario usando:
Como [rol], quiero [objetivo], para [valor].
| Contexto | Necesidad |
|---|---|
| Biblioteca | El estudiante necesita conocer la fecha límite para devolver un libro. |
| Compras | El cliente necesita recibir información cuando su pedido cambie de estado. |
| Educación | El estudiante necesita saber qué actividades tiene pendientes. |
| Soporte | El usuario necesita conocer la respuesta de su solicitud. |
| Eventos | El asistente necesita cancelar su registro antes de la fecha permitida. |
Después revisa
Section titled “Después revisa”- ¿El rol está claro?
- ¿El objetivo representa una necesidad?
- ¿El “para” expresa valor?
- ¿La historia describe qué necesita el usuario y no cómo implementarlo?
¿Cuál elegir?
Section titled “¿Cuál elegir?”No es una elección exclusiva: algunos equipos usan ambos formatos según el tipo de funcionalidad. La pregunta que orienta la elección es: ¿necesito documentación formal para un proceso con varios flujos alternos (caso de uso), o priorizar valor incremental en iteraciones cortas (historia de usuario)? En cualquiera de los dos casos, el insumo que sigue es el mismo: los criterios de aceptación.
Criterios de aceptación
Section titled “Criterios de aceptación”Un criterio de aceptación es una condición verificable que determina cuándo una historia o caso de uso se considera cumplido.
Dado que el visitante no tiene cuenta,
cuando envía un nombre, un correo válido no registrado antes y una contraseña que cumple la política,
entonces el sistema crea la cuenta y confirma el registro.
Actividad guiada — convertir una historia en criterios
Section titled “Actividad guiada — convertir una historia en criterios”Historia
Section titled “Historia”Como estudiante
quiero consultar la disponibilidad de un libro
para saber si puedo solicitarlo antes de acudir a la biblioteca.
¿Qué ocurre cuando el libro tiene ejemplares disponibles?
¿Qué ocurre cuando no hay ejemplares disponibles?
¿Qué ocurre si el libro está reservado o tiene una condición especial?
Construye tres criterios
Section titled “Construye tres criterios”Dado que…
Cuando…
Entonces…
Primero piensa en el comportamiento. Después escribe la frase.
Ampliación — formato Gherkin (Given-When-Then)
Section titled “Ampliación — formato Gherkin (Given-When-Then)”El formato dado–cuando–entonces que usas en esta unidad corresponde al lenguaje Gherkin, ampliamente usado en la industria dentro del desarrollo guiado por comportamiento (Behavior-Driven Development, BDD): Given–When–Then. El programa oficial de esta unidad no exige Gherkin como herramienta. Se presenta aquí como la convención más extendida para escribir criterios de aceptación de forma verificable, no como contenido evaluado adicional.
Relación entre criterios de aceptación y pruebas
Section titled “Relación entre criterios de aceptación y pruebas”Un criterio de aceptación bien escrito es casi directamente un caso de prueba: el dado es la precondición, el cuando es la acción o entrada, y el entonces es el resultado esperado — exactamente la estructura que necesita un caso de prueba.
Criterio, escenario y caso de prueba
Section titled “Criterio, escenario y caso de prueba”Condición que debe cumplirse.
Situación concreta que permite comprobar una condición.
Descripción estructurada de cómo verificar el comportamiento.
Resultado obtenido al ejecutar la prueba.
En esta unidad construimos principalmente criterios y escenarios y dejamos preparada la trazabilidad. El diseño formal de casos de prueba se profundizará en la Unidad III.
Más ejemplos de criterios de aceptación
Section titled “Más ejemplos de criterios de aceptación”Dado que un usuario ha fallado 4 intentos de inicio de sesión, cuando falla un quinto intento, entonces el sistema bloquea la cuenta durante 15 minutos.
Dado que un producto tiene 0 unidades en inventario, cuando un cliente intenta agregarlo al carrito, entonces el sistema impide la acción y muestra “sin existencias”.
Escenarios: positivos, negativos y alternos
Section titled “Escenarios: positivos, negativos y alternos”| Escenario | Tipo | Entrada | Resultado esperado |
|---|---|---|---|
| E1 | Positivo | Correo nuevo válido | Cuenta creada |
| E2 | Negativo | Correo ya registrado | Registro rechazado |
| E3 | Alterno / límite | Contraseña del largo mínimo exacto | Cuenta creada |
Buenas prácticas para diseñar escenarios
Section titled “Buenas prácticas para diseñar escenarios”Cubre primero el escenario positivo antes de las variantes.
Por cada regla, diseña al menos un escenario que intente romperla.
No repitas el mismo escenario con datos distintos si verifica exactamente lo mismo.
Lo necesitarás para construir la matriz de trazabilidad (Bloque 3).
Más ejemplos de escenarios — inicio de sesión
Section titled “Más ejemplos de escenarios — inicio de sesión”| Escenario | Tipo | Entrada | Resultado esperado |
|---|---|---|---|
| E7 | Positivo | Correo y contraseña correctos | Acceso concedido |
| E8 | Negativo | Contraseña incorrecta | Acceso denegado, mensaje de error |
| E9 | Alterno / límite | Quinto intento fallido consecutivo | Cuenta bloqueada temporalmente |
Más ejemplos de escenarios — carrito de compras
Section titled “Más ejemplos de escenarios — carrito de compras”| Escenario | Tipo | Entrada | Resultado esperado |
|---|---|---|---|
| E10 | Positivo | Carrito con 3 productos disponibles | Pago procesado |
| E11 | Negativo | Producto sin existencias en el carrito | Pago bloqueado, aviso “sin existencias” |
| E12 | Alterno / límite | Carrito con 0 productos al intentar pagar | Pago bloqueado, mensaje de carrito vacío |
Los límites no son solo de texto o de intentos — E12 es un límite de cantidad, el mismo tipo que verás en tu proyecto base si algo se cuenta, se acumula o se agota.
Condición límite
Section titled “Condición límite”Una condición límite (boundary condition) es un valor exactamente en el borde de un rango válido.
No es solo numérica: también aplica a longitud de texto, número de intentos, fechas. Un escenario “alterno” que no toca un límite real no cumple 2.2.4 — se profundizará formalmente en la Unidad III.
Cómo encontrar condiciones límite
Section titled “Cómo encontrar condiciones límite”Pregúntate: ¿cuál es el valor más pequeño que el sistema debe aceptar? ¿cuál es el más grande? ¿qué pasa justo un paso antes y un paso después de ese borde? Estas preguntas — no una fórmula — son la manera intuitiva de encontrar condiciones límite en esta unidad.
Más ejemplos de condiciones límite
Section titled “Más ejemplos de condiciones límite”| Tipo de límite | Ejemplo |
|---|---|
| Longitud de texto | Contraseña de exactamente 8 caracteres (el mínimo permitido) |
| Cantidad | Carrito con 0 productos al intentar pagar |
| Número de intentos | Quinto intento fallido de inicio de sesión, si el límite es 5 |
| Fecha | Usar una promoción exactamente el último día de su vigencia |
Actividad guiada — encontrar el límite
Section titled “Actividad guiada — encontrar el límite”Para cada regla identifica:
valor mínimo → valor válido → valor máximo → qué ocurre fuera del rango
| Regla | Pregunta |
|---|---|
| Máximo 5 préstamos | ¿Qué ocurre con 4, 5 y 6 préstamos? |
| Contraseña mínima de 8 caracteres | ¿Qué ocurre con 7, 8 y 9 caracteres? |
| Cancelación hasta 24 horas antes | ¿Qué ocurre a 25 h, 24 h y 23 h? |
| Máximo 3 intentos de recuperación | ¿Qué ocurre en el segundo, tercero y cuarto intento? |
Tu tarea
Section titled “Tu tarea”Elige una regla y construye tres escenarios:
- antes del límite
- exactamente en el límite
- después del límite
En esta unidad el objetivo es identificar y describir el escenario límite. Las técnicas formales de valores límite se estudiarán en la Unidad III.
Actividad — Laboratorio 2
Section titled “Actividad — Laboratorio 2”De un requisito a escenarios verificables
Section titled “De un requisito a escenarios verificables”Selecciona un requisito funcional o regla de negocio de tu Laboratorio 1.
Construye en este orden
Section titled “Construye en este orden”1. Requisito
Copia el ID y la redacción.
2. Actor o rol involucrado
¿Quién inicia o participa en la interacción?
3. Caso de uso o historia de usuario
Describe la interacción.
4. Criterios de aceptación
Escribe al menos 2.
5. Escenarios
Construye al menos:
- un escenario positivo
- un escenario negativo
- un escenario alterno o límite.
6. Resultado esperado
Indica qué debería observarse.
La finalidad no es producir muchas pruebas.
La finalidad es demostrar que puedes derivar escenarios a partir de requisitos documentados.
Bloque 3 — Trazabilidad
Section titled “Bloque 3 — Trazabilidad”El recorrido completo
Section titled “El recorrido completo”¿Por qué necesitamos algo?
¿Qué debe cumplirse?
¿Cuándo consideramos cumplida la condición?
¿Qué situación concreta verificaremos?
La trazabilidad permite conservar las relaciones entre estos elementos para poder conocer qué está cubierto, qué falta y qué cambia cuando cambia un requisito.
¿Qué es trazabilidad?
Section titled “¿Qué es trazabilidad?”Trazabilidad (traceability) es la relación documentada entre dos artefactos: por ejemplo, entre un requisito y la prueba que lo verifica.
Sin trazabilidad, no hay forma sistemática de responder: “¿probamos todo lo que teníamos que probar?”
Trazabilidad requisito–caso de prueba
Section titled “Trazabilidad requisito–caso de prueba”Cada requisito debe poder relacionarse con al menos un caso de prueba que lo verifique.
Un requisito sin ningún caso de prueba asociado es una brecha de cobertura — no un detalle de formato.
Ejemplo — una brecha de cobertura
Section titled “Ejemplo — una brecha de cobertura”| ID requisito | Descripción | ID caso de prueba |
|---|---|---|
| RF-03 | Enviar confirmación de registro por correo | — (sin caso de prueba asociado) |
Esta fila no es un error de formato: es una alerta. Si nadie escribió un caso de prueba para RF-03, no hay evidencia de que esa funcionalidad se haya verificado — sin importar si “parece que funciona”.
Trazabilidad caso de prueba–defecto
Section titled “Trazabilidad caso de prueba–defecto”Cada caso de prueba, al ejecutarse, puede relacionarse con un defecto si falla.
En esta unidad esta relación se deja prevista, no ejecutada: no se corren pruebas ni se gestionan defectos todavía (severidad, prioridad, ciclo de vida y herramientas de gestión son contenido de la Unidad VII).
Matriz de trazabilidad
Section titled “Matriz de trazabilidad”| ID requisito | Descripción | ID caso de prueba | ¿Encontró defecto? |
|---|---|---|---|
| RF-01 | Crear cuenta con datos válidos | ESC-01 | Pendiente de ejecutar |
| RN-01 | Rechazar correo ya registrado | ESC-02 | Pendiente de ejecutar |
| RNF-01 | Contraseña cifrada | ESC-03 | Pendiente de ejecutar |
Caso ilustrativo — la versión completa se construye en el Laboratorio 3.
Formato sugerido de matriz de trazabilidad
Section titled “Formato sugerido de matriz de trazabilidad”No existe un formato único obligatorio. ISO/IEC/IEEE 29119 (REF-U2-08) reconoce la matriz de trazabilidad como un artefacto de documentación de pruebas, sin fijar columnas exactas. El formato mínimo recomendado incluye: ID de requisito, descripción, ID(s) de caso(s) de prueba, y estado de ejecución/defecto encontrado.
Un requisito, varios casos de prueba
Section titled “Un requisito, varios casos de prueba”| ID requisito | Descripción | ID caso de prueba | ¿Encontró defecto? |
|---|---|---|---|
| RF-01 | Crear cuenta con datos válidos | ESC-01, E7 | Pendiente de ejecutar |
| RF-01 | Crear cuenta con datos válidos | E9 (límite) | Pendiente de ejecutar |
Un requisito real casi nunca se cubre con un solo caso de prueba: la matriz debe poder mostrar varias filas (o varias columnas) para el mismo requisito — uno por cada escenario relevante.
Una matriz con más filas
Section titled “Una matriz con más filas”| ID requisito | Descripción | ID caso de prueba | ¿Encontró defecto? |
|---|---|---|---|
| RF-01 | Mostrar materias disponibles | ESC-07 | Pendiente de ejecutar |
| RF-02 | Mostrar grupos de una materia | ESC-08 | Pendiente de ejecutar |
| RF-03 | Validar prerrequisitos | ESC-09, ESC-10 | Pendiente de ejecutar |
| RF-04 | Verificar disponibilidad de lugares | ESC-11 | Pendiente de ejecutar |
| RF-05 | Registrar inscripción | ESC-12 | Pendiente de ejecutar |
| RF-06 | Enviar confirmación | — (sin caso de prueba asociado) | — |
Una matriz real casi nunca tiene tres filas ordenadas: mezcla requisitos con 0, 1 o varios casos de prueba — como aquí RF-03 (dos escenarios) y RF-06 (ninguno, la misma brecha de cobertura que viste antes, pero ahora dentro de una matriz de tamaño real).
¿Por qué importa la matriz?
Section titled “¿Por qué importa la matriz?”Revela requisitos que nadie está probando.
Si cambia un requisito, muestra qué pruebas hay que revisar.
La trazabilidad también funciona hacia atrás
Section titled “La trazabilidad también funciona hacia atrás”Hacia adelante
¿Qué pruebas necesitamos cuando aparece o cambia un requisito?
Requisito → criterios → escenarios → pruebas
Hacia atrás
¿Qué requisito justifica esta prueba?
Prueba → escenario → criterio → requisito
Una prueba sin requisito asociado puede indicar una prueba sin justificación documentada.
Un requisito sin prueba asociada puede indicar una brecha de cobertura.
¿Qué pasa si cambia un requisito?
Section titled “¿Qué pasa si cambia un requisito?”Supongamos que cambia esta regla:
La cancelación puede realizarse hasta 24 horas antes.
Ahora se establece:
La cancelación puede realizarse hasta 48 horas antes.
La trazabilidad permite localizar
Section titled “La trazabilidad permite localizar”| Elemento | ¿Debe revisarse? |
|---|---|
| Requisito | Sí |
| Criterios de aceptación | Sí |
| Escenarios de 24 h | Sí |
| Escenarios de 48 h | Sí |
| Casos de prueba relacionados | Sí |
| Evidencia anterior | Debe evaluarse |
| Otros requisitos relacionados | Debe analizarse |
La matriz no solo sirve para comprobar cobertura.
También ayuda a identificar qué artefactos pueden verse afectados por un cambio.
Actividad — Laboratorio 3 (evidencia oficial)
Section titled “Actividad — Laboratorio 3 (evidencia oficial)”Construye la matriz de trazabilidad inicial del proyecto base asignado a tu equipo: relaciona los requisitos y reglas del Laboratorio 1 con las historias o casos de uso, los criterios y los escenarios del Laboratorio 2.
Instrucciones completas en el Laboratorio 3 — evidencia oficial de la Unidad 2.
Segundo ejemplo aplicado — recuperación de contraseña
Section titled “Segundo ejemplo aplicado — recuperación de contraseña”El primer ejemplo fue sobre todo validación de datos este es sobre una regla de negocio de seguridad — mismo pipeline funcionalidad distinta
El requisito y la regla de negocio
Section titled “El requisito y la regla de negocio”RF-02 enviar enlace de recuperación al correo registrado
RNF-02 el enlace expira 30 minutos después de generarse
RN-02 el sistema no debe revelar si un correo está registrado o no
RN-02 no describe qué hace el sistema describe una fuga de información
que no debe ocurrir
Los criterios de aceptación
Section titled “Los criterios de aceptación”Dado que el correo está registrado cuando se solicita recuperación entonces se envía el enlace y se muestra un mensaje genérico
Dado que el correo NO está registrado cuando se solicita recuperación entonces se muestra exactamente el mismo mensaje genérico
Sin el segundo criterio RN-02 podría incumplirse aunque RF-02
funcione
Los escenarios
Section titled “Los escenarios”| Escenario | Tipo | Entrada | Resultado esperado |
|---|---|---|---|
| E4 | Positivo | Correo registrado | Enlace enviado mensaje genérico |
| E5 | Negativo | Correo no registrado | Mismo mensaje genérico sin enviar nada |
| E6 | Alterno / límite | Enlace usado exactamente a los 30 minutos | Debe quedar definido por escrito si se acepta o se rechaza |
E6 es la clase de ambigüedad que una condición límite obliga a resolver antes de que el sistema decida algo que nadie definió a propósito
La fila de la matriz
Section titled “La fila de la matriz”| ID requisito | Descripción | ID caso de prueba | ¿Encontró defecto? |
|---|---|---|---|
| RF-02 | Enviar enlace de recuperación | ESC-04 | Pendiente de ejecutar |
| RN-02 | No revelar si el correo existe | ESC-05 | Pendiente de ejecutar |
| RNF-02 | Enlace expira en 30 minutos | ESC-06 | Pendiente de ejecutar |
Tercer ejemplo aplicado — resolviendo la contradicción del Bloque 1
Section titled “Tercer ejemplo aplicado — resolviendo la contradicción del Bloque 1”Al inicio de la unidad viste RF-01 y RF-02 contradecirse sobre cuándo
se puede cancelar una inscripción. Aquí está la versión corregida.
RN-03
El sistema deberá permitir cancelar una inscripción hasta 24 horas antes del inicio del curso.
Dado que faltan más de 24 horas para el inicio del curso, cuando el estudiante solicita cancelar, entonces el sistema cancela la inscripción y libera el lugar.
Dado que faltan menos de 24 horas, cuando el estudiante solicita cancelar, entonces el sistema rechaza la cancelación e informa el motivo.
Escenarios y matriz de la cancelación
Section titled “Escenarios y matriz de la cancelación”| Escenario | Tipo | Entrada | Resultado esperado |
|---|---|---|---|
| E13 | Positivo | Cancelación 48 h antes | Inscripción cancelada |
| E14 | Negativo | Cancelación 2 h antes | Cancelación rechazada |
| E15 | Alterno / límite | Cancelación exactamente a las 24 h | Debe quedar definido por escrito si se acepta o rechaza |
| ID requisito | Descripción | ID caso de prueba | ¿Encontró defecto? |
|---|---|---|---|
| RN-03 | Cancelar inscripción respetando la ventana de 24 horas | ESC-13, ESC-14, ESC-15 | Pendiente de ejecutar |
Una sola regla de negocio verificable, en vez de dos requisitos que se contradicen — y el mismo recorrido (requisito → criterio → escenario → matriz) que harás tú en los tres laboratorios.
Actividad integradora — recorre todo el pipeline
Section titled “Actividad integradora — recorre todo el pipeline”Elige una necesidad del proyecto base asignado a tu equipo y recorre todo el camino.
¿Qué necesita lograr el stakeholder?
¿Qué debe cumplir el sistema?
¿Cómo documentarás la interacción?
¿Cuándo se considera cumplida?
Positivo, negativo y alterno/límite.
¿Qué verificarías?
¿Qué requisito cubre cada prueba?
Ahora te toca a ti
Section titled “Ahora te toca a ti”Selecciona una funcionalidad del proyecto base asignado a tu equipo. No necesitas rehacer todo el sistema Construye únicamente un recorrido completo:
Debes poder explicar
Section titled “Debes poder explicar”- ¿Quién necesita algo?
- ¿Qué necesita?
- ¿Qué debe cumplir el sistema?
- ¿Quién es el actor?
- ¿Cuál es el flujo principal?
- ¿Qué puede salir diferente?
- ¿Cuándo consideramos cumplida la funcionalidad?
- ¿Qué escenarios la verifican?
- ¿Qué prueba queda relacionada con el requisito?
Cierre — volviendo a la situación inicial
Section titled “Cierre — volviendo a la situación inicial”Con lo aprendido en esta unidad, ahora puedes explicar con precisión:
- el problema del formulario de registro fue un requisito no verificable, no un desacuerdo sobre gustos
- un criterio de aceptación bien escrito hubiera evitado la discusión
- la matriz de trazabilidad muestra, de entrada, si “validar el correo” tenía siquiera un caso de prueba asociado.
En síntesis
Section titled “En síntesis”- Los requisitos (funcionales, no funcionales, reglas de negocio) deben redactarse de forma verificable.
- Casos de uso e historias de usuario son dos formas de describir una interacción. Ninguna sustituye a la otra.
- Los criterios de aceptación convierten un requisito en condiciones comprobables.
- Los escenarios (positivos, negativos, alternos/límite) traducen esos criterios en pruebas concretas.
- La matriz de trazabilidad conecta requisito → prueba, y deja prevista prueba → defecto.
Lo que sigue
Section titled “Lo que sigue”En la Unidad III vas a aplicar técnicas formales de diseño de casos de prueba (caja negra, caja blanca, partición de equivalencia, valores límite) sobre los escenarios que ya construiste aquí.
La misma matriz de trazabilidad que construiste hoy reaparece en la Unidad V — ahí la aplicarás también a pruebas de APIs y servicios.
Referencias
Section titled “Referencias”- Jorgensen — Software Testing: A Craftsman’s Approach (4.ª ed., 2013).
- Patton — Software Testing (2.ª ed., 2005).
- Myers, Sandler y Badgett — The Art of Software Testing (3.ª ed., 2011).
- Black, van Veenendaal y Graham — Foundations of Software Testing ISTQB Certification (2012).
- Crispin y Gregory — Agile Testing (2009).
- Toledo — Introducción a las pruebas de sistemas de información (2024).
- ISO/IEC 25010:2011, ISO/IEC/IEEE 29119.
Ficha completa de cada fuente en las referencias de la unidad (REF-U2-01 a REF-U2-10).