Un SSD mostra, per un particolare corso di eventi all'interno di un caso d'uso, gli attori esterni che interagiscono direttamente con il sistema. Il tempo avanza dall'alto verso il basso, e l'ordine temporale degli eventi dovrebbe seguire il proprio ordine nello scenario, la figura chiarirà questi dettagli:

• L'omino rappresenta, nell'operazione corrente descritta dal SSD sopra, un attore esterno al sistema.
• Il sistema è rappresentato a scatola nera. I due punti indicano che si tratta di un'istanza del sistema. Si faccia attenzione: si tratta di un'istanza concettuale (a livello di modello di business) del sistema, non di un'istanza progettuale, non l'istanza di una classe.
  I due attori si scambiano dei messaggi.
  I messaggi verso il sistema (o in generale, messaggi di richiesta) hanno una freccia piena e con linea continua, tali linee possono contenere il nome dell'operazione ed eventuali parametri che deve ricevere.

Mentre i messaggi inviati dal sistema (o in generale, messaggi di risposta) hanno una freccia senza riempimento e con linea tratteggiata, anche qui possono essere specificati dei valori di ritorno. Se non viene ritornato alcun valore, tale linea può essere omessa.

Vi sono diversi frame, in cui i messaggi possono essere inglobati, ad indicare una particolare condizione del messaggio, nella figura sopra per esempio abbiamo un frame che indica uno scambio di messaggi tra attore esterno e sistema attraverso un ciclo.

I casi d'uso descrivono il modo in cui gli attori esterni interagiscono con il sistema che si vuole creare. Durante questa iterazione un attore genera degli eventi di sistema, che costituiscono un input per il sistema, di solito per richiedere l'esecuzione di alcune operazioni di sistema, che sono operazioni che il sistema deve definire proprio per gestire tali eventi. Per esempio, quando un cassiere inserisce il codice identificativo di un articolo, egli richiede al sistema POS di registrare la vendita di quell'articolo (evento enterItem). Quell'evento dà inizio all'esecuzione di un'operazione nel sistema.

UML fornisce la notazione dei diagrammi di sequenza per illustrare interazioni tra attori e le operazioni iniziate da essi.

Un diagramma di sequenza di sistema è una figura che mostra, per un particolare scenario di un caso d'uso, gli eventi generati dagli attori esterni al sistema, il loro ordine e gli eventi inter-sistema (ovvero tra sistemi). Tutti i sistemi sono considerati a scatola nera.

É norma disegnare un SSD per uno scenario principale di successo di ciascun caso d'uso, nonché per gli scenari alternativi più frequenti o complessi.

UML non definisce qualcosa che è chiamato evento "di sistema", o operazione "di sistema", o ancora diagramma di sequenza "di sistema". Piuttosto definisce elementi o diagrammi chiamati semplicemente "evento", "operazione" e "diagramma di sequenza". La qualifica "di sistema" pone l'accento su l'uso che si fa di tali elementi, ovvero definire una comunicazione con un sistema, considerati a scatola nera.

Prima di passare alla progettazione dettagliata del funzionamento di un'applicazione software, è utile esaminare e definire le sue funzioni e il suo comportamento a scatola nera.
Le funzioni e il comportamento di un sistema sono una descrizione di che cosa fa un sistema, senza spiegare come lo fa.

Un SSD mostra gli eventi di sistema per un solo scenario di un caso d'uso, e può essere generato prendendo spunto (ispezionando) tale scenario. Un SSD mostra l'attore primario del caso d'uso, il sistema e i passi che rappresentano le interazioni tra il sistema e l'attore. Le interazioni iniziate dall'attore primario nei confronti del sistema sono mostrate come messaggi con parametri.

A sinistra lo scenario base del caso d'uso "elabora vendita con pagamento in contanti".
Gli attori coinvolti sono il cassiere (che comincia una nuova vendita, quando un cliente gli presenta gli articoli da comprare) e il sistema che esegue le operazioni richieste dal cassiere.
Il frame di loop indica che per ogni articolo presentato dal cliente, il cassiere inserisce il codice identificativo dell'oggetto e la quantità. Si noti che per esempio non è chiaro come questo avvenga: potrebbe avvenire mediante uno scanner di codici a barre, potrebbe venire inserita la quantità con una tastiera, o uno schermo touch screen, non è chiaro, e non lo deve essere in questa fase. Per ogni articolo inserito dal cassiere il sistema mostra la descrizione e il totale sino al quel momento. Anche qui, non è chiaro come questo avvenga. Dopo aver inserito gli articoli, il cassiere termina l'inserimento. Il sistema calcola il totale, applicando le tasse (mostrandolo) e il cassiere richiede al sistema un pagamento in contanti. Infine il sistema restituisce la ricevuta ed eventuale resto dovuto.

I tipi di dato passati come parametro ad un'operazione di sistema sono preferibilmente dei valori di un tipo di dato, per esempio, un numero o una data. Bisogna evitare invece parametri che sono degli oggetti o dei concetti complessi, come per esempio descrizione prodotto.

I diagrammi di sequenza di sistema possono ance essere utilizzati per illustrare collaborazioni tra sistemi, come tra il POS e il sistema esterno di autorizzazione ai pagamenti con carta di credito. Tuttavia questo aspetto viene rimandato, poiché in questa iterazione non vengono considerate interazioni con sistemi remoti.

Gli elementi mostrati negli SSD (nomi delle operazioni, parametri, dati di ritorno) sono concisi. Probabilmente è necessaria una spiegazione più appropriata di questi elementi, in modo che durante la progettazione risulti chiaro cosa entra e cosa esce. Il glossario rappresenta una collocazione ideale per questi dettagli.

Nella fase di ideazione gli SSD, solitamente non sono giustificati.
É proprio nella fase di elaborazione che la maggior parte degli SSD viene creata, quando è utile identificare i dettaglia degli eventi di sistema per chiarire quali sono le principali operazioni che il sistema deve essere in grado di gestire, scrivere i contratti delle operazioni e possibilmente supportare le stime.