“La maggior parte dei manuali sull’ingegneria del software raccomanda di non iniziare la progettazione fino a quando tutti i requisiti non sono concordati. È un consiglio sbagliato, perché comunque non arriverete mai a conoscere tutti i requisiti, e iniziare presto la progettazione vi servirà probabilmente a scoprire nuovi requisiti.” (Alan Davis, “Just Enough Requirements Management”, 2005)

Il termine “analisi”, d’altra parte, può essere interpretato e declinato in diversi modi, e in organizzazioni diverse può assumere significati molto distanti tra loro.

L’etimologia greca, “analysis”, significa letteralmente “scomposizione”, la scomposizione dell’elemento studiato nei suoi elementi costitutivi, per poterlo comprendere e definire meglio.

Analisi dei processi di business, in questa accezione, è l’individuazione e la definizione dei processi; l’analisi dei requisiti individua e definisce i requisiti; l’analisi dei dati individua e definisce le informazioni da gestire negli archivi, e così via.

Nell’uso corrente dello sviluppo software, d’altra parte, il termine “analisi” viene per lo più usato  per la definizione delle caratteristiche fondamentali della soluzione, ad un livello indipendente dalle tecnologie di implementazione, mentre il design viene ad assumere la valenza di progettazione tecnica.

Nel caso di organizzazioni di sviluppo strutturate in silos, il confine tra i ruoli di analista e designer può diventare un ambito di discussione e conflitti; nel caso invece di progetti basati sulla collaborazione sistematica dei ruoli, il contributo delle diverse competenze risulta efficace ed efficiente: l’esperto di analisi pone una particolare attenzione alla comprensione del dominio (della materia) e delle esigenze degli stakeholder, mentre il progettista-designer individua il modo ottimale per implementare la soluzione nelle tecnologie date.