Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Errori comuni nei documenti di Analisi dei Requisiti

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.

  • Login to see the comments

Errori comuni nei documenti di Analisi dei Requisiti

  1. 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. 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. 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. 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. 5. Ingegneria del software mod. B ATTORI  Quali attori individuare? 5Riccardo Cardin
  6. 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. 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. 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. 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. 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. 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. 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. 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. 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. 15. Ingegneria del software mod. B IDENTIFICAZIONE  Codici identificativi … 15Riccardo Cardin Dov’è il codice identificativo del caso d’uso?
  16. 16. Ingegneria del software mod. B ASSOCIAZIONI  Esistono tre tipi di associazioni fra i casi d’uso  Inclusione  Estensione  Ereditarietà 16Riccardo Cardin Estensione?
  17. 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. 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. 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. 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. 21. Ingegneria del software mod. B ASSOCIAZIONI  Attenzione ai punti di ESTENSIONE  Devono sempre essere riportati anche nella descrizione del diagramma 21Riccardo Cardin
  22. 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. 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. 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. 25. Ingegneria del software mod. B ASSOCIAZIONI  Ereditarietà o generalizzazione? 25Riccardo Cardin Ottimo! Si vogliono descrivere varie tipologie di comunicazione con altri utenti
  26. 26. Ingegneria del software mod. B RAPPRESENTAZIONE  Nessun dettaglio implementativo sui modi di interazione attore – sistema 26Riccardo Cardin Dettaglio dell’algoritmo di registrazione
  27. 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. 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. 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. 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. 31. Ingegneria del software mod. B ERRORI ORTOGRAFICI  Da evitare assolutamente nei diagramma  … da evitare in assoluto … 31Riccardo Cardin
  32. 32. Ingegneria del software mod. B REQUISITI  Atomici  Verificabili  Non basati su principi qualitativi, ma misurabili  Attenzione ai vincoli! 32Riccardo Cardin

×