In generale, i casi d'uso non devono riguardare dettagli di implementazione come link, home page o banner pubblicitari. Se hai un caso d'uso per consegnare un rapporto, allora quel caso d'uso dovrebbe essere ugualmente soddisfatto se il rapporto è scritto a mano e consegnato da un impiegato, se si tratta di un documento PDF multipagina o se è una raccolta di web pagine con collegamenti di navigazione.
L'unico posto in cui un buon caso d'uso si riferirebbe alla tecnologia consiste nel descrivere gli scenari alternativi di ciò che potrebbe andare storto. E anche lì non vorrei menzionare link non funzionanti, in quanto possono verificarsi ovunque. Tali errori sono meglio trattati con requisiti generici al di fuori del contesto di un caso d'uso.
Oltre ai requisiti relativi al comportamento che possono essere descritti molto bene con i casi d'uso, ogni progetto avrà invariabilmente alcuni requisiti che non si adattano perfettamente al modello di un caso d'uso, come i requisiti non funzionali e i requisiti funzionali che si applicano a una gran parte dei casi d'uso. Dovresti non cercare di forzare questi requisiti nel modello di un caso d'uso, ma piuttosto lasciarli soli come requisiti dei casi non utilizzati.