La lliçó anterior va fixar l'abast general del projecte final de BiblioTech i la seva arquitectura triada. Abans de tocar una sola línia de codi, aquesta lliçó converteix aquest abast en quelcom molt més concret: una llista precisa de requisits funcionals i no funcionals, i un pla de treball en iteracions petites que eviti la temptació d'intentar construir-ho tot de cop. Planificar abans de programar no és burocràcia innecessària: és el que permet, a la Lliçó 3, saber exactament què construir primer i per què, en comptes d'avançar a cegues ensamblant peces en un ordre arbitrari.

1. Requisits funcionals: casos d'ús concrets
2. Requisits no funcionals
3. Planificació en fases: quatre iteracions
4. Estimació bàsica de tasques per iteració
5. Elecció definitiva de tecnologies

Un requisit funcional descriu quelcom que el sistema ha de fer: una acció concreta que un usuari (o un client de l'API) pot sol·licitar i esperar-ne un resultat. Per a BiblioTech, la llista de requisits funcionals del projecte final és la següent:

Cadascun d'aquests set requisits correspon, de forma gairebé directa, a un mètode ja existent a Biblioteca o a una combinació petita d'ells —la mateixa taula és, en si mateixa, un mapa de quina part del codi ja construït cobreix cada requisit.

Un requisit no funcional no descriu una acció, sinó una qualitat que el sistema ha de tenir mentre fa el que fa. Són més difícils de verificar amb un simple cas d'ús, però igual d'importants:

• Rendiment raonable: les operacions de consulta (RF3, llistar el catàleg) han de respondre en un temps acceptable fins i tot amb un catàleg de mida moderada (centenars o pocs milers de materials); no es persegueix aquí cap objectiu de rendiment extrem, només evitar operacions evidentment ineficients (per exemple, carregar tot el catàleg en memòria a cada petició si una consulta a la base de dades ja n'hi hauria prou).
• Seguretat bàsica: l'API no ha d'exposar dades sensibles de forma innecessària (per exemple, cadenes de connexió o detalls interns de la base de dades en els missatges d'error que retorna al client); les cadenes de connexió de producció han de viure fora del codi font (Lliçó 5, configuració per entorn), mai escrites directament a Program.cs.
• Mantenibilitat: gràcies a l'arquitectura del Mòdul 8 (IRepositoriBiblioteca + injecció de dependències + proves unitàries), canviar el mecanisme de persistència, afegir un nou endpoint, o corregir un error ha de poder fer-se sense reescriure parts del sistema no relacionades amb el canvi.
• Fiabilitat davant de fallades externes: la consulta de metadades externes (RF7) depèn d'un servei de tercers que pot fallar o no respondre; ja es va veure al Mòdul 5 que aquest cas es captura amb try/catch sobre HttpRequestException, retornant null en comptes de propagar la fallada a qui va demanar les metadades.

A diferència dels requisits funcionals, aquests no es "marquen com a completats" amb una única prova puntual: es verifiquen de forma contínua al llarg de tot el projecte, i es revisen explícitament al checklist de qualitat de la Lliçó 4.

Intentar construir les set funcionalitats de l'apartat 1 alhora, sense cap ordre, és la recepta més directa per quedar-se encallat a mig camí sense res que funcioni de cap a cap. En comptes d'això, el projecte s'organitza en quatre iteracions petites, cadascuna lliurant quelcom que funciona per si mateix abans de passar a la següent:

Aquesta divisió en iteracions no és arbitrària: cadascuna depèn exclusivament de l'anterior, i cadascuna és, per si mateixa, quelcom verificable —una API que respon correctament a curl, encara que no tingui client encara, ja és un resultat tangible de la Iteració 2, no una feina a mitges sense cap valor propi.

Una estimació no necessita ser precisa al minut per ser útil; n'hi ha prou de donar una idea relativa d'esforç que ajudi a prioritzar i a detectar per endavant en quina iteració és més probable encallar-se:

La iteració amb més esforç relatiu (l'API) és, precisament, la que més es recolza en la feina ja feta al Mòdul 8: la major part d'aquesta "càrrega" és ensamblatge i registre de serveis, no lògica nova per inventar des de zero.

Amb els requisits ja clars, toca fixar, sense ambigüitat, quina tecnologia concreta es farà servir a cada capa —resumint les decisions ja presentades o comparades en mòduls anteriors:

L'elecció d'Entity Framework Core (en comptes de text, JSON o SQLite amb ADO.NET pur) com a persistència de producció respon a un motiu concret: és l'única de les quatre opcions del Mòdul 5 pensada per escalar còmodament a mesura que el model de dades creixi, i s'integra de forma natural amb el contenidor de DI d'ASP.NET Core mitjançant AddDbContext (ja vist a 08-03, apartat 7). Res no impedeix, però, substituir-la per qualsevol de les altres tres en qualsevol moment: aquesta és, precisament, la garantia que ofereix IRepositoriBiblioteca.

• Confondre requisits funcionals amb tasques d'implementació: "fer servir Entity Framework Core" no és un requisit funcional (no descriu què fa el sistema per a l'usuari), és una decisió tècnica de l'apartat 5; mantenir les dues coses separades evita llistes de requisits confuses.
• Saltar-se els requisits no funcionals per semblar "menys concrets": són tan reals com els funcionals, només que es verifiquen d'una altra manera (revisió contínua, checklist) en comptes d'amb un cas d'ús puntual.
• Planificar iteracions que depenen les unes de les altres de forma circular: si la Iteració 3 (Client) necessités canvis a la Iteració 1 (Domini) per funcionar, la planificació té un problema d'ordre; revisa que cada iteració només depengui de les anteriors, mai de les següents.
• Consell: si una iteració sembla "massa gran" en estimar-la, és bon senyal que es pot dividir en dues iteracions més petites, cadascuna amb el seu propi resultat verificable.

1. Per a cadascun dels set requisits funcionals (RF1-RF7) de la taula de l'apartat 1, indica en quina iteració de l'apartat 3 es cobreix principalment i quin endpoint HTTP (verb + ruta) esperaries que l'implementi a la Iteració 2.

2. Un company d'equip proposa afegir, a mig fer la Iteració 2, un requisit nou: "permetre reservar un llibre que no està disponible, perquè quedi apartat quan es retorni". Explica per què, segons els criteris de planificació d'aquesta lliçó, aquest requisit s'hauria d'anotar per a una futura iteració en comptes d'afegir-se immediatament a la Iteració 2 en curs.

Afegir un requisit nou a mig fer una iteració en curs trenca el principi central de la planificació per fases: cada iteració ha de lliurar un abast tancat i verificable abans de passar a la següent. Acceptar el canvi immediatament allargaria la Iteració 2 de forma impredictible i retardaria la resta del pla; el correcte és anotar la idea (per exemple, com a "Iteració 5: reserves", fora de l'abast ja tancat d'aquest projecte final) i continuar amb el que ja estava planificat, igual que es faria amb qualsevol funcionalitat nova proposada durant el desenvolupament, tal com ja s'ha advertit a la lliçó anterior.

Aquesta lliçó ha convertit l'abast general de la Lliçó 1 en quelcom molt més concret: set requisits funcionals traçables a codi ja existent, un conjunt de requisits no funcionals que es vigilen de forma contínua, un pla en quatre iteracions petites amb dependències clares entre elles, una estimació relativa d'esforç, i l'elecció definitiva de tecnologia a cada capa. Amb aquest pla ja tancat, la lliçó següent, Implementació, deixa de planificar i comença a ensamblar: construirà l'estructura de solució amb diversos projectes, registrarà IRepositoriBiblioteca i Biblioteca al contenidor de DI d'ASP.NET Core, i exposarà els endpoints corresponents a cadascun dels set requisits d'aquesta lliçó.