La lección anterior fijó el alcance general del proyecto final de BiblioTech y su arquitectura elegida. Antes de tocar una sola línea de código, esta lección convierte ese alcance en algo mucho más concreto: una lista precisa de requisitos funcionales y no funcionales, y un plan de trabajo en iteraciones pequeñas que evite la tentación de intentar construirlo todo de golpe. Planificar antes de programar no es burocracia innecesaria: es lo que permite, en la Lección 3, saber exactamente qué construir primero y por qué, en vez de avanzar a ciegas ensamblando piezas en un orden arbitrario.

1. Requisitos funcionales: casos de uso concretos
2. Requisitos no funcionales
3. Planificación en fases: cuatro iteraciones
4. Estimación básica de tareas por iteración
5. Elección definitiva de tecnologías

Un requisito funcional describe algo que el sistema debe hacer: una acción concreta que un usuario (o un cliente de la API) puede solicitar y esperar un resultado. Para BiblioTech, la lista de requisitos funcionales del proyecto final es la siguiente:

Cada uno de estos siete requisitos corresponde, de forma casi directa, a un método ya existente en Biblioteca o a una combinación pequeña de ellos —la propia tabla es, en sí misma, un mapa de qué parte del código ya construido cubre cada requisito.

Un requisito no funcional no describe una acción, sino una cualidad que el sistema debe tener mientras hace lo que hace. Son más difíciles de verificar con un simple caso de uso, pero igual de importantes:

• Rendimiento razonable: las operaciones de consulta (RF3, listar el catálogo) deben responder en un tiempo aceptable incluso con un catálogo de tamaño moderado (cientos o pocos miles de materiales); no se persigue aquí ningún objetivo de rendimiento extremo, solo evitar operaciones evidentemente ineficientes (por ejemplo, cargar todo el catálogo en memoria en cada petición si una consulta a la base de datos bastaría).
• Seguridad básica: la API no debe exponer datos sensibles de forma innecesaria (por ejemplo, cadenas de conexión o detalles internos de la base de datos en los mensajes de error que devuelve al cliente); las cadenas de conexión de producción deben vivir fuera del código fuente (Lección 5, configuración por entorno), nunca escritas directamente en Program.cs.
• Mantenibilidad: gracias a la arquitectura del Módulo 8 (IRepositorioBiblioteca + inyección de dependencias + pruebas unitarias), cambiar el mecanismo de persistencia, añadir un nuevo endpoint, o corregir un error debe poder hacerse sin reescribir partes del sistema no relacionadas con el cambio.
• Fiabilidad ante fallos externos: la consulta de metadatos externos (RF7) depende de un servicio de terceros que puede fallar o no responder; ya se vio en el Módulo 5 que este caso se captura con try/catch sobre HttpRequestException, devolviendo null en vez de propagar el fallo a quien pidió los metadatos.

A diferencia de los requisitos funcionales, estos no se "marcan como completados" con una única prueba puntual: se verifican de forma continua a lo largo de todo el proyecto, y se revisan explícitamente en el checklist de calidad de la Lección 4.

Intentar construir las siete funcionalidades del apartado 1 a la vez, sin ningún orden, es la receta más directa para bloquearse a mitad de camino sin nada que funcione de principio a fin. En su lugar, el proyecto se organiza en cuatro iteraciones pequeñas, cada una entregando algo que funciona por sí mismo antes de pasar a la siguiente:

Esta división en iteraciones no es arbitraria: cada una depende exclusivamente de la anterior, y cada una es, por sí misma, algo verificable —una API que responde correctamente a curl, aunque no tenga cliente todavía, ya es un resultado tangible de la Iteración 2, no un trabajo a medias sin ningún valor propio.

Una estimación no necesita ser precisa al minuto para ser útil; basta con dar una idea relativa de esfuerzo que ayude a priorizar y a detectar de antemano en qué iteración es más probable atascarse:

La iteración con mayor esfuerzo relativo (la API) es, precisamente, la que más se apoya en trabajo ya hecho en el Módulo 8: la mayor parte de esa "carga" es ensamblaje y registro de servicios, no lógica nueva que inventar desde cero.

Con los requisitos ya claros, toca fijar, sin ambigüedad, qué tecnología concreta se usará en cada capa —resumiendo las decisiones ya presentadas o comparadas en módulos anteriores:

La elección de Entity Framework Core (en vez de texto, JSON o SQLite con ADO.NET puro) como persistencia de producción responde a un motivo concreto: es la única de las cuatro opciones del Módulo 5 pensada para escalar de forma cómoda a medida que el modelo de datos crezca, y se integra de forma natural con el contenedor de DI de ASP.NET Core mediante AddDbContext (ya visto en 08-03, apartado 7). Nada impide, sin embargo, sustituirla por cualquiera de las otras tres en cualquier momento: esa es, precisamente, la garantía que ofrece IRepositorioBiblioteca.

• Confundir requisitos funcionales con tareas de implementación: "usar Entity Framework Core" no es un requisito funcional (no describe qué hace el sistema para el usuario), es una decisión técnica del apartado 5; mantener ambas cosas separadas evita listas de requisitos confusas.
• Saltarse los requisitos no funcionales por parecer "menos concretos": son tan reales como los funcionales, solo que se verifican de otra forma (revisión continua, checklist) en vez de con un caso de uso puntual.
• Planificar iteraciones que dependen unas de otras de forma circular: si la Iteración 3 (Cliente) necesitara cambios en la Iteración 1 (Dominio) para funcionar, la planificación tiene un problema de orden; revisa que cada iteración solo dependa de las anteriores, nunca de las siguientes.
• Consejo: si una iteración parece "demasiado grande" al estimarla, es buena señal de que puede dividirse en dos iteraciones más pequeñas, cada una con su propio resultado verificable.

1. Para cada uno de los siete requisitos funcionales (RF1-RF7) de la tabla del apartado 1, indica en qué iteración del apartado 3 se cubre principalmente y qué endpoint HTTP (verbo + ruta) esperarías que lo implemente en la Iteración 2.

2. Un compañero de equipo propone añadir, a mitad de la Iteración 2, un requisito nuevo: "permitir reservar un libro que no está disponible, para que quede apartado cuando se devuelva". Explica por qué, según los criterios de planificación de esta lección, ese requisito debería anotarse para una futura iteración en vez de añadirse de inmediato a la Iteración 2 en curso.

Añadir un requisito nuevo a mitad de una iteración en curso rompe el principio central de la planificación por fases: cada iteración debe entregar un alcance cerrado y verificable antes de pasar a la siguiente. Aceptar el cambio de inmediato alargaría la Iteración 2 de forma impredecible y retrasaría el resto del plan; lo correcto es anotar la idea (por ejemplo, como "Iteración 5: reservas", fuera del alcance ya cerrado de este proyecto final) y continuar con lo ya planificado, igual que se haría con cualquier funcionalidad nueva propuesta durante el desarrollo, como ya se advirtió en la lección anterior.

Esta lección ha convertido el alcance general de la Lección 1 en algo mucho más concreto: siete requisitos funcionales trazables a código ya existente, un conjunto de requisitos no funcionales que se vigilan de forma continua, un plan en cuatro iteraciones pequeñas con dependencias claras entre ellas, una estimación relativa de esfuerzo, y la elección definitiva de tecnología en cada capa. Con este plan ya cerrado, la siguiente lección, Implementación, deja de planificar y empieza a ensamblar: construirá la estructura de solución con varios proyectos, registrará IRepositorioBiblioteca y Biblioteca en el contenedor de DI de ASP.NET Core, y expondrá los endpoints correspondientes a cada uno de los siete requisitos de esta lección.