Sergio Di Martino » 6.Il documento dei Requisiti Software

Obiettivi della lezione

• Capire cosa deve contenere un Documento dei Requisiti
• Comprendere le tecniche per la raccolta dei requisiti
  • Scenari → Use Cases
• Comprendere le tecniche per l’analisi / specifica dei requisiti
  • Use Cases
  • Diagrammi di Cockburn

Software Lifecycle Activities

Requirement Elicitation

Il primo passo è la Raccolta dei Requisiti.

La raccolta dei requisiti da inserire nel Documento dei Requisiti si focalizza sul punto di vista dell’utente e definisce i “boundary” (confini) del Sistema da Sviluppare (System under Development, o SuD).

Vengono specificati:

1. funzionalità del sistema;
2. interazione tra utente e sistema;
3. errori che il sistema deve individuare e gestire;
4. vincoli e condizioni di utilizzo del sistema.

Non fanno parte dell’attività di raccolta dei requisiti:

1. la selezione delle tecnologie da usare per lo sviluppo;
2. il progetto del sistema e le metodologie da usare;
3. …. in generale tutto quello che non è direttamente visibile all’utente.

Come raccogliere i requisiti

L’elicitation dei requisiti avviene attraverso un processo di raccolta delle informazioni, coinvolgendo tutti gli stakeholders.
Interviste

• Chiuse: lo stakeholder risponde ad un insieme predefinito di domande.
• Aperte (Brainstorming): dialogo a ruota libera.

Le interviste non sempre sono una tecnica efficace per raccogliere requisiti, perché non sempre gli stakeholder sono in grado/vogliono descrivere il loro dominio.
Utilizzare gli “scenari”.

• Descrizioni di esempi tipici di interazione col sistema che si intende sviluppare.
• Descrizioni di esempi reali invece che di descrizioni astratte.
• L’astrazione va fatta dall’analista dei requisiti.

L’Elicitation è la parte più difficile

Problemi sugli obiettivi

• I boundaries del sistema non sono chiari.
• Gli Stakeholders forniscono moltissime informazioni irrilevanti.

Problemi di comprensione

• Gli StakeHolders non sanno mai esattamente cosa vogliono.
• Gli StakeHolders non hanno una visione chiara di possibilità e limiti dei sistemi informativi.
• Gli StakeHolders hanno difficoltà a comunicare tutte le loro esigenze.
• Il linguaggio naturale è intrinsecamente ambiguo.

Problemi di volatilità

• I requisiti possono cambiare di continuo (stima reale: almeno il 25% dei requisiti cambierà durante il progetto).

Fasi della Requirement Analysis

Dopo aver raccolto i requisiti insieme con il cliente, si passa alla fase di Analisi dei Requisiti

1. Identificare gli Attori: gli sviluppatori individuano i differenti utenti che il sistema dovrà supportare.
2. Identificare gli Scenari: gli sviluppatori realizzano scenari dettagliati che descrivono le funzionalità fornite dal sistema. Gli scenari sono esempi concreti di utilizzo del sistema, descritti in termini di interazione tra utente e sistema, e servono per comprendere il dominio di applicazione.
3. Identificare gli Use Case: gli sviluppatori derivano dagli scenari un insieme di use case che rappresentano in modo completo il sistema software da sviluppare. Uno use case è un’astrazione che descrive una classe di scenari.
4. Dettagliare gli use case: gli sviluppatori si assicurano che le funzionalità del sistema siano completamente specificate, dettagliando ogni use case e descrivendo il comportamento del sistema in situazioni di errore, e condizione limite.
5. Identificare i requisiti non funzionali: tutti gli stakeholders si accordano sugli aspetti visibili all’utente finale ma che non sono direttamente relati alle funzionalità del sistema: vincoli sulle prestazioni; utilizzo delle risorse; sicurezza e qualità.

1- Euristiche per Identificare gli Attori

Per identificare gli attori, esistono alcune linee guida

• Tracciare i Boundaries del SuD.
• Quali gruppi di utenti sono supportati dal sistema per svolgere il loro lavoro?
• Quali gruppi di utenti eseguono le principali funzioni del sistema?
• Quali gruppi di utenti eseguono le funzioni secondarie, come il mantenimento e l’amministrazione?
• Con quale sistema hardware o software esterni il sistema interagisce? Ogni sw già esistente con cui il SuD interagirà, è un attore. Es: In POS NextGEN, il sw di una banca, pre-esistente, che ci autorizza al prelievo dalla carta di credito è un attore.

Un attore non corrisponde ad una persona fisica, ma ad un ruolo.

• Una persona può svolgere diversi ruoli nello stesso sistema. Es: sono l’Administrator di un sito, ma se non mi loggo sono un Utente non Registrato.

2- Identificare gli Scenari

Uno scenario è “una descrizione narrativa di cosa le persone fanno e sperimentano mentre provano ad usare i sistemi di elaborazione e le applicazioni” [M. Carrol, Scenario-based Design, Wiley, 1995].

Uno scenario è una descrizione concreta, focalizzata, e informale di una singola caratteristica di un sistema utilizzata da un singolo attore.
Gli scenari possono essere utilizzati in diversi modi durante il ciclo di vita del software.

Esempio di Scenario:
Gestisci Restituzione
Scenario principale di successo:

• Un cliente arriva alla cassa con alcuni articoli da restituire. Il cassiere usa il sistema POS per registrare ciascun articolo restituito …

Scenari alternativi:

• Se il cliente aveva pagato con la carta di credito, e la transazione di rimborso sul relativo conto di credito è stata respinta, allora il cliente viene informato e viene rimborsato in contanti.

Se …

Euristiche per trovare gli Scenari

Chiedersi o chiedere al cliente le seguenti domande:

• Quali sono i compiti primari che l’attore vuole che esegua il sistema?
• Quali informazioni saranno create, memorizzate, modificate, cancellate, o aggiunte dall’utente nel sistema?
• Di quali cambiamenti esterni l’attore deve informare il sistema?
• Di quali cambiamenti o eventi del sistema deve essere informato l’attore?

Euristiche per l’individuazione dei Casi d’Uso

Per ogni attore, definirne gli obiettivi.
Creare una tabella Attore-Obiettivi.

“Il test del Capo”

• Immaginare che il vostro capo vi chieda “Cosa hai fatto tutto il giorno?” e voi rispondete col nome di un caso d’uso. Se il capo è contento, è un buon caso d’uso. Es: “Seleziona Stampa dal menù”.

“Il test EBP”

• Un Processo di Business Elementare è un’attività svolta da una persona in un determinato tempo e luogo. Es: “Gestisci contratto con fornitore”.

“Il test della dimensione”

• Errore comune: fare UC di un singolo passo, all’interno di una sequenza di passi correlati. Es: “Preme bottone Salva”.

Diagramma dei Casi d’Uso

Contiene

• Attori
• Casi d’uso
• Relazioni di associazione, dipendenza e generalizzazione

Usato per modellare il contesto di un sistema

• Gli attori sono esterni al sistema
• I casi d’uso sono all’interno del sistema

Usato per modellare (visualmente) i requisiti funzionali

• Ogni caso d’uso corrisponde a uno o più requisiti funzionali
• Ogni caso d’uso è coinvolto in una qualche relazione

Diversi livelli di dettaglio

• Decomposizione gerarchica

Descrizione testuale degli UC

Per ogni Use Case nel diagramma ci vuole una descrizione testuale dettagliata, presente successivamente nel Documento dei Requisiti Software.
Obiettivo è specificare in ogni aspetto l’interazione attore(i)/sistema, dettagliando la funzionalità dal punto di vista dell’Attore.
Esistono molte rappresentazioni, concettualmente simili tra loro.
Useremo nel prosieguo del corso il cosiddetto “Template di A. Cockburn”.

Il Template di Cockburn

Il Template di Cockburn (segue)

Guida alla scrittura di Casi d’Uso

I nomi dei casi d’uso dovrebbero includere verbi.
I nomi di Attori dovrebbero essere sostantivi.
I casi d’uso devo iniziare con un’azione di un attore (trigger).
Le relazioni causali tra passi successivi dovrebbero essere chiare.
Un caso d’uso dovrebbe descrivere una transazione utente completa.
Le eccezioni dovrebbero essere descritte nelle sezioni apposite.
Un caso d’uso non dovrebbe descrivere un’interfaccia del sistema (utilizzare prototipi mock-up!).
Un caso d’uso non dovrebbe superare due o tre pagine.

Gli errori più comuni

1. Modellare operazioni che non coinvolgono il sistema. Ad esempio, se il sistema è il software di un videonoleggio e il cliente deve consegnare un modulo cartaceo all’impiegato, questa operazione non coinvolge il sistema, e pertanto non va modellata.
2. Introdurre generalizzazioni improprie fra attori. Ogni attore deve avere use cases, e l’attore sottotipo può dare inizio a tutte gli use case del padre. Se un attore figlio non ha use case propri la generalizzazione è inutile, oppure nel diagramma mancano degli use case. Tutti gli attori figli hanno use case propri?
3. Il diagramma è troppo complesso. Bisogna fare un uso moderato delle relazioni fra use case e delle generalizzazioni fra attori. La modellazione delle deve avvenire ad un grado di astrazione sufficientemente elevato; non è questo il diagramma da usare per esprimere tutti i dettagli contenuti nelle specifiche in linguaggio naturale. Occorre essere ordinati (evitare linee che si intersecano, ecc…). Un diagramma complesso è indice di un cattivo analista.
4. Relazioni errate. L’include non è la via corretta per rappresentare relazioni temporali tra Use Case. Es. di errore: Includere un caso d’uso Login in un caso d’uso “Effettua acquisto” per un sito di commercio elettronico. Non devo rifare il login se effettuo due acquisti di seguito! In tali casi si usano le precondizioni nella descrizione testuale.