Risposta.

Storia della questione:

Con l'aumento delle dimensioni e della complessità dei progetti IT, si è ripetutamente verificata la situazione in cui i requisiti provenienti dal cliente aziendale arrivavano sotto forma di desideri astratti, che durante il passaggio al team di sviluppo si trasformavano in qualcos'altro. La causa è il divario nella terminologia, nelle aspettative e nel livello di astrazione tra il business e l'IT.

Problema:

Se non si pianifica attentamente la fase di scomposizione, i requisiti diventano incompleti (mancano dettagli critici), o eccessivamente sfumati (non è possibile valutare e realizzare), o addirittura distorti a causa di trappole lessicali, terminologie non considerate e ambiguità.

Soluzione:

L'analista di sistema scompone progressivamente ogni requisito: formalizza termini aziendali, traduce obiettivi aziendali in funzioni e compiti, descrive scenari utente e comportamento del sistema, collega a criteri di accettazione/casi di test. È importante utilizzare modelli (UML, BPMN), glossari, checklist e revisioni dirette tra i team.

Caratteristiche chiave:

Creazione di un glossario di termini congiuntamente con il cliente
Uso di diagrammi e formulazioni atomiche dei requisiti
Traduzione dei requisiti nel linguaggio dei criteri di accettazione e dei casi di test

Domande insidiose.

È possibile lasciare i desideri aziendali in forma libera con successivo perfezionamento nella fase di sviluppo?

No, c'è un alto rischio di malintesi e errori di realizzazione.

È necessario portare i dettagli di realizzazione (ad esempio, come memorizzare i dati) nella fase di analisi?

No, l'analisi riguarda "cosa" e "perché", non "come". Dettagli tecnici sono di competenza dell'architettura e dello sviluppo.

Un requisito = un modulo/funzione è sempre vero?

No, spesso è necessaria una scomposizione: requisiti grandi vengono divisi in sottofunzioni e user stories con criteri di accettazione separati.

Errori tipici e anti-pattern

Miscelazione del linguaggio aziendale e termini tecnici senza glossario
Descrizione dei requisiti sotto forma di "desideri sfumati"
Violazione dell'atomicità — un requisito contiene molte entità diverse

Esempio dalla vita

Caso negativo: Il cliente ha fornito un elenco di desideri "L'utente deve vedere tutta l'analisi delle vendite", e nel documento di requisiti è stato copiato tal quale.

Vantaggi:

Rapidità nella preparazione della documentazione

Svantaggi:

Non è chiaro quali metriche siano necessarie e in quale contesto
Rimandi continui

Caso positivo: L'analista ha interrogato il cliente, ha stilato un elenco di metriche necessarie, ha definito i ruoli degli utenti, ha sviluppato prototipi di report e ha concordato un glossario di termini.