Non esiste un ordine fisso. Tutto si basa su ciò che pensi sia più utile per te / la tua squadra.
Inizialmente, ci dovrebbe essere una serie di requisiti. Se inizi con l'architettura SW una volta che qualcuno ti dice di fare un software per X, allora hai già perso il passaggio più importante.
Durante la fase di ingegnerizzazione dei requisiti, non tutti i diagrammi UML hanno ancora senso. Ma alcuni hanno molto senso, in particolare i diagrammi dei casi d'uso. Ho spesso visto diagrammi del caso d'uso come base per le discussioni da cui sono poi stati determinati i requisiti.
Allo stesso modo, le macchine a stati sono già popolari anche a livello di requisiti.
Una volta che hai una serie di requisiti e in effetti inizi a pensare alla tua architettura e successivamente al design, sempre più diagrammi cominceranno a dare un senso. Ovviamente, il diagramma di classe è utile su livelli di dettaglio più bassi, ma altri, come i diagrammi di sequenza, possono avere senso se si hanno sequenze complesse nella propria architettura.
Stai sviluppando un sistema distribuito o qualcosa in cui i componenti devono comunicare molto tra loro? Prova il diagramma di comunicazione.
A meno che il tuo processo non richieda in qualche modo di utilizzare uno specifico diagramma UML, non c'è nessuno che ti obblighi a farlo. Ricorda sempre di non modellare il tuo software in UML per il suo stesso interesse. Se non hai voglia ti aiuterà, allora semplicemente non farlo.
Ovviamente, ci vuole un po 'di esperienza per decidere questo. Vi suggerisco di investire almeno del tempo per provare i diagrammi di stato, di classe, di attività e di sequenza, poiché sono quelli più popolari. Se hai abbastanza tempo, dai uno sguardo anche agli altri.