Perché la cattura dei requisiti è una responsabilità architetturale

Nel ruolo di Power Platform Solution Architect non raccogli requisiti come una checklist da spuntare: li interpreti come vincoli di progettazione che determineranno l’intera topologia della soluzione. Un requisito mal classificato non è un errore documentale, è un debito architetturale che emerge in UAT o, peggio, in produzione. La disciplina qui è distinguere con precisione cosa deve fare il sistema da quanto bene deve farlo e entro quali limiti.

Le tre categorie che devi tenere separate

  • Requisiti funzionali: descrivono comportamenti osservabili — “l’agente deve poter approvare una richiesta di rimborso”. Guidano tabelle Dataverse, business process flow, Power Automate, model-driven/canvas app.
  • Requisiti non funzionali (NFR): definiscono qualità trasversali e sono spesso i veri driver architetturali.
    • Performance: volumi di righe, concorrenza, dimensione delle query → decidono strategia di indicizzazione, uso di elastic tables, virtual tables o offload verso Azure.
    • Security: modello di accesso, segregazione dei dati → business unit, security role, column-level security, hierarchy security, integrazione con Microsoft Entra ID e gruppi.
    • Compliance: residenza dati, retention, auditing → environment geo-localizzati, Microsoft Purview per DLP e classificazione, audit log Dataverse.
    • Availability/continuità: RPO/RTO, finestre di manutenzione → strategia di backup, environment routing, disaster recovery multi-region.
  • Vincoli (constraints): non negoziabili di contesto — budget di licenze, scadenza normativa, stack esistente, divieto di codice pro-code. Riducono lo spazio delle soluzioni prima ancora di progettare.

Mappare i requisiti sui processi di business

Il collante tra requisiti e architettura è il process mapping. Modella il processo end-to-end (as-is → to-be), poi appendi ogni requisito allo step che lo genera. Questo produce due deliverable critici: la fit-gap analysis (cosa copre la piattaforma out-of-the-box, cosa richiede configurazione, cosa richiede estensione custom o pro-code) e la tracciabilità requisito → capability → componente. Un gap classificato correttamente come “richiede plug-in C#” cambia stima, competenze del team e ALM: è una decisione di design, non un dettaglio.

MoSCoW come strumento di governance dello scope

MoSCoW non è priorità estetica: è il contratto che protegge il tuo MVP e allinea le aspettative dello sponsor.

  • Must have: senza questo, il rilascio non ha valore né è conforme. Definisce la baseline non negoziabile.
  • Should have: importante ma con workaround temporaneo accettabile.
  • Could have: valore incrementale, primo a saltare sotto pressione di tempo.
  • Won’t have (this time): esplicitamente fuori scope in questa release — la voce più preziosa, perché documenta ciò che non costruirai e blocca lo scope creep.

Trade-off chiave: mantieni i “Must” a una frazione contenuta dello sforzo totale (idealmente ≤60%), lasciando margine di contingenza nei “Should/Could”. Se il 90% è “Must”, non hai priorità: hai una lista dei desideri, e la prima slittanza travolgerà la timeline.

Dato il requisito, quale scelta raccomandi

  • Requisito: “reportistica su 5 anni di storico, 20M righe” → NFR di performance/volume. Raccomanda virtual tables o Azure Synapse Link for Dataverse, non tabelle standard interrogate da app: l’NFR, non la funzionalità, detta l’architettura dati. Pilastro Performance Efficiency del Well-Architected Framework.
  • Requisito: “dati sanitari, accesso solo al team clinico” → compliance + security. Environment dedicato con DLP Purview e column-level security; classifica come Must. Pilastro Security.
  • Requisito: “disponibile 24/7 per operatori globali” → availability. Strategia di service protection limits, retry idempotenti nei flow, environment routing. Pilastro Reliability.

Trappole tipiche d’esame

  • Scenario: lo sponsor marca ogni requisito come “Must have” per non perdere nulla → Soluzione raccomandata: rinegozia con MoSCoW forzando la categoria “Won’t have this time”, proteggi l’MVP e presenta un trade-off esplicito costo/tempo per ogni Must aggiuntivo. Priorità senza esclusioni non è priorità.
  • Scenario: il team ha catturato solo requisiti funzionali; performance e security sono impliciti → Soluzione raccomandata: conduci un workshop dedicato agli NFR prima del design, perché volumi, concorrenza e residenza dati determinano scelte (virtual tables, environment geo, Purview) difficili da rimediare a posteriori.
  • Scenario: requisito “il sistema deve essere veloce” senza metrica → Soluzione raccomandata: rifiuta requisiti non misurabili; trasforma in NFR quantificato (es. “caricamento < 3s al 95° percentile con 500 utenti concorrenti”), altrimenti non è verificabile in UAT.
  • Scenario: un vincolo di compliance (residenza dati UE) emerge tardi → Soluzione raccomandata: i vincoli vanno raccolti per primi perché restringono lo spazio delle soluzioni; qui impongono selezione dell’environment region a monte, non una patch di configurazione.
  • Scenario: gap funzionale coperto “con un po’ di codice custom” dato per scontato → Soluzione raccomandata: la fit-gap deve classificare esplicitamente config vs. extend vs. build; ogni estensione pro-code ha impatti su ALM, competenze e costo di manutenzione da valutare nel trade-off.