This presentation talks about common errors that I found in my career in documents of specification of requirements. In the presentation are described common errors on use cases, use cases' diagrams and on requirements' specification. The presentation is took from the Software Engineering course I run in the bachelor-level informatics curriculum at the University of Padova.

1. ERRORI COMUNI REV. REQUISITI
INGEGNERIA DEL SOFTWARE
Università degli Studi di Padova
Dipartimento di Matematica
Corso di Laurea in Informatica, A.A. 2014 – 2015
rcardin@math.unipd.it

2. Ingegneria del software mod. B
RIFERIMENTI
 I riferimenti devono essere precisi
 Sempre presenti
 Inserire la versione dei documenti citati
 I documento vengono modificati da una versione all’altra
 Fornire indicazione completa delle fonti
 Libri, siti Internet
2Riccardo Cardin
Quale versione?

3. Ingegneria del software mod. B
GLOSSARIO
 Glossario
 Documento a se stante
 Non può essere inserito all’interno di un altro documento
 Indicare come i termini del glossario vegono
individuati
 Sottolineatura
 Utilizzo di lettere in pediceG
 Corsivo
3Riccardo Cardin
Non è indicato come
vengono individuati i
termini del Glossario

4. Ingegneria del software mod. B
ATTORI
 Definizione utenti
 «Sono considerati utenti tutti coloro i quali intendano
far uso del prodotto software»
 La definizione degli utenti è importante. Deve fornire
gli obiettivi che ogni tipologia di attore vuole
ottenere utilizzando l’applicazione.
 … e deve fornire una fotografia delle capacità degli attori.
 Utile utilizzare un diagramma dei casi d’uso per la
gerarchia degli attori
4Riccardo Cardin

5. Ingegneria del software mod. B
ATTORI
 Quali attori individuare?
5Riccardo Cardin

6. Ingegneria del software mod. B
ATTORI
 Quali attori individuare?
 Attore: ruolo dell’ utente nell’interazione con il
sistema
6Riccardo Cardin
Sono parte del sistema,
non possono essere definiti
attori!

7. Ingegneria del software mod. B
ATTORI
 Quali attori individuare?
 Attore: ruolo dell’ utente nell’interazione con il
sistema
 Gruppi di funzionalità offerte
dal sistema
7Riccardo Cardin
Se accedono alle
medesime funzionalità sono
lo stesso attore

8. Ingegneria del software mod. B
ATTORI
 L’attore può essere visto come un insieme di
funzionalità rese disponibili dal sistema
8Riccardo Cardin
Finché
l’amministratore non è
autenticato è un utente
comune

9. Ingegneria del software mod. B
ATTORI
 Relazioni fra attori
 Individuare sempre tutte le relazioni di ereditarietà
 Eventualmente dedicare un diagramma allo scopo
9
I casi d’uso non descrivono
trasformazioni degli attori
Riccardo Cardin

10. Ingegneria del software mod. B
PRE E POST CONDIZIONI
 Cosa devono descrivere?
 Le pre e post condizioni devono descrivere lo stato
del sistema prima e dopo l’esecuzione degli scenari.
 POSTCONDIZIONI: l'utente inizia a interagire con il
programma per creare la propria presentazione.
 POSTCONDIZIONI: è stata creata una presentazione vuota e il
sistema è pronto per la sua modifica.
10Riccardo Cardin

11. Ingegneria del software mod. B
SCOPO DEL DIAGRAMMA
 Utilizzare descrizioni non triviali
 UC_1: Primo avvio di MindSlide
 Illustrare ciò che avviene al primo avvio dell'applicazione.
11Riccardo Cardin
(segue)

12. Ingegneria del software mod. B
SCOPO DEL DIAGRAMMA
 Utilizzare descrizioni non triviali
 UC_1: Creazione di una nuova presentazione
 La creazione di una nuova presentazione (UC_1.1) da parte di
un utente scatena la creazione di una slide vuota (UC_1.2).
L’utente visualizzerà immediatamente la presentazione
appena creata (UC_1.3).
12Riccardo Cardin

13. Ingegneria del software mod. B
DESCRIZIONE
 Una descrizione per ogni caso d’uso individuato
 Non è possibile utilizzare descrizioni “cumulative”
 Possono differire per pre-condizioni e post-condizioni
13Riccardo Cardin
3.3.1 Inserimento e modifica di testo
DESCRIZIONE : l'utente può scrivere un nuovo campo di testo in una posizione qualsiasi
della slide. Sono presenti tre campi fissi: header, corpo e footer. Quando viene creato
un campo è possibile modificarlo, spostarlo o cancellarlo in un secondo momento, questo
però include che il campo venga selezionato.
PRECONDIZIONE : l'utente ha MindSlide caricato nel proprio browser e sta modificando
una slide in modalità SlideView.
POSTCONDIZIONE : le modifiche sono visibili sulla slide.

14. Ingegneria del software mod. B
DIDASCALIA FIGURE
 La didascalia deve essere parlante …
14Riccardo Cardin
“Diagramma dei casi d’uso che descrive le
funzionalità principali del sistema.”

15. Ingegneria del software mod. B
IDENTIFICAZIONE
 Codici identificativi …
15Riccardo Cardin
Dov’è il codice identificativo
del caso d’uso?

16. Ingegneria del software mod. B
ASSOCIAZIONI
 Esistono tre tipi di associazioni fra i casi d’uso
 Inclusione
 Estensione
 Ereditarietà
16Riccardo Cardin
Estensione?

17. Ingegneria del software mod. B
ASSOCIAZIONI
 Attenzione a non confondersi fra inclusione ed
estensione
17Riccardo Cardin
La funzionalità di help rappresenta il
caso classico dell’estensione, perché
è accedibile da più scenari in modo
condizionale

18. Ingegneria del software mod. B
ASSOCIAZIONI
 Attenzione a non confondersi fra inclusione ed
estensione
18Riccardo Cardin
La verifica del CAPTCHA viene
effettuata ogni volta che si
confermano i dati

19. Ingegneria del software mod. B
ASSOCIAZIONI
 Non usare l’estensione per modellare post e pre
condizioni
19Riccardo Cardin
Eliminazione della cronologia
ha come precondizione lo
stato del sistema indotto dalla
visualizzazione

20. Ingegneria del software mod. B
ASSOCIAZIONI
 La direzione della relazione di estensione è dal
caso d’uso che estende al caso d’uso esteso.
20Riccardo Cardin
L’unico caso d’uso collegato
all’attore non può essere
condizionale

21. Ingegneria del software mod. B
ASSOCIAZIONI
 Attenzione ai punti di ESTENSIONE
 Devono sempre essere riportati anche nella
descrizione del diagramma
21Riccardo Cardin

22. Ingegneria del software mod. B
ASSOCIAZIONI
 Estensione o generalizzazione?
 Estensione: funzionalità condizionali
 Durante l’esecuzione di un’altra funzionalità
 Raffinamento: dettaglio di una particolare
funzionalità
22Riccardo Cardin

23. Ingegneria del software mod. B
ASSOCIAZIONI
 Inclusione o generalizzazione?
 Inclusione: fattorizzazione funzionalità
23Riccardo Cardin
Il caso d’uso di login è
costituito nel suo
scenario principale
dall’immissione di
username e password

24. Ingegneria del software mod. B
ASSOCIAZIONI
 Ereditarietà o generalizzazione?
 La prima modella un caso d’uso che differisce per
particolari o aggiunge funzionalità
24Riccardo Cardin
Si stanno descrivendo
le funzionalità che
compongono la
macro-funzionalità

25. Ingegneria del software mod. B
ASSOCIAZIONI
 Ereditarietà o generalizzazione?
25Riccardo Cardin
Ottimo! Si vogliono
descrivere varie
tipologie di
comunicazione con
altri utenti

26. Ingegneria del software mod. B
RAPPRESENTAZIONE
 Nessun dettaglio implementativo sui modi di
interazione attore – sistema
26Riccardo Cardin
Dettaglio dell’algoritmo di
registrazione

27. Ingegneria del software mod. B
RAPPRESENTAZIONE
 Quale livello di dettaglio?
27Riccardo Cardin
Scopo e definizione:
Permette all'utente di effettuare connessioni logiche tra le slide oggetto
della presentazione. Sono possibili collegamenti parent/child oppure
sibling.

28. Ingegneria del software mod. B
RAPPRESENTAZIONE
 Mantenere un livello di astrazione omogeneo
 Autenticazione è ad un livello maggiore degli altri casi
d’uso
28Riccardo Cardin
Rappresenta il
diagramma
stesso

29. Ingegneria del software mod. B
RAPPRESENTAZIONE
 Quale livello di dettaglio?
29Riccardo Cardin
Slideshow (UC 5)
Attori coinvolti:
Utente, tipologia unica descritta nella Sezione 2.4.
Scopo e definizione:
Permette all'utente di visualizzare la presentazione creata secondo un ordine pressato, o
comunque, avendo la possibilità di velocizzare la visualizzazione evitando gli
approfondimenti o, viceversa, esplorando i sottoargomenti di una particolare slide.
Precondizioni:
L'utente ha creato una nuova presentazione oppure ne ha caricata una preesistente.
Postcondizioni:
La presentazione corrente e stata visualizzata nelle modalita desiderate dall'utente.
Flusso base degli eventi:
1. L'utente decide di avviare la presentazione tramite l'interfaccia
2. Il sistema avvia lo slideshow
3. L'utente effettua la presentazione, gestendola a suo piacimento tramite l'interfaccia
messa a sua disposizione

30. Ingegneria del software mod. B
RAPPRESENTAZIONE
 Quale livello di dettaglio?
30Riccardo Cardin
Slideshow (UC 5)
Attori coinvolti:
Utente, tipologia unica descritta nella Sezione 2.4.
Scopo e definizione:
Permette all'utente di visualizzare la presentazione creata secondo un ordine pressato, o
comunque, avendo la possibilità di velocizzare la visualizzazione evitando gli
approfondimenti o, viceversa, esplorando i sottoargomenti di una particolare slide.
Precondizioni:
L'utente ha creato una nuova presentazione oppure ne ha caricata una preesistente.
Postcondizioni:
La presentazione corrente e stata visualizzata nelle modalita desiderate dall'utente.
Flusso base degli eventi:
1. L'utente decide di avviare la presentazione tramite l'interfaccia
2. Il sistema avvia lo slideshow
3. L'utente effettua la presentazione, gestendola a suo piacimento tramite l'interfaccia
messa a sua disposizione
Quali sono le funzionalità offerte
dallo slideshow?
Come può gestire l’utente a suo
piacimento la presentazione?

31. Ingegneria del software mod. B
ERRORI ORTOGRAFICI
 Da evitare assolutamente nei diagramma
 … da evitare in assoluto …
31Riccardo Cardin

32. Ingegneria del software mod. B
REQUISITI
 Atomici
 Verificabili
 Non basati su principi qualitativi, ma misurabili
 Attenzione ai vincoli!
32Riccardo Cardin