Specifica, raccolta e analisi dei requisiti

La specifica dei requisiti - Documentazione dei Casi d'uso

- Ogni caso d'uso è accompagnato da una descrizione chiara e comprensibile agli stakeholder non tecnici.
- Il linguaggio utilizzato è naturale e semplice per evitare ambiguità.
- La descrizione inizia con il "happy path" e può includere varie alternative e eccezioni.

Requisiti Software e Stakeholder

- I requisiti riflettono le esigenze degli utenti e il dominio del problema.
- I requisiti sono raccolti con la collaborazione tra stakeholder con diversi background.
- La definizione dei requisiti comprende funzionalità, servizi, modalità operative e gestione dei dati.
- L'errore nell'analisi dei requisiti può introdurre errori nel sistema finale.

Principali rischi nell'analisi dei requisiti

- Dimenticanza di funzionalità.
- Realizzazione di requisiti irrilevanti o inutili.
- Resistenza al cambiamento da parte degli stakeholder.
- Introduzione di errori sistematici nell'interpretazione dei requisiti.

Normative e Best Practices

- ISO 13407/Human-centred design process per l'analisi dei requisiti.
- Importanza di fondare il progetto sui reali bisogni degli utenti.

Stakeholder nel processo di analisi dei requisiti

- Ogni stakeholder può fornire descrizioni strategiche e operative per il sistema.
- Sono coinvolti nella definizione dei requisiti e nella definizione degli obiettivi del sistema.

Riassunto

Le pagine evidenziano l'importanza di una corretta analisi e documentazione dei requisiti software, enfatizzando la collaborazione tra stakeholder e l'approccio centrato sull'utente per garantire lo sviluppo di sistemi software che rispondano efficacemente alle esigenze reali e migliorino l'esperienza dell'utente.

Classificazione dei requisiti

- Requisiti software divisi in due categorie principali:
- Requisiti utente (user requirements): esigenze specifiche degli utenti finali.
- Requisiti di sistema (system requirements): dettagli tecnici per soddisfare i requisiti degli utenti.

Tipi di requisiti

- Requisiti funzionali: descrivono cosa fa il sistema.
- Requisiti non funzionali: spiegano come il sistema esegue le funzioni.
- Requisiti di dominio: specifici del dominio in cui il sistema opererà.

Livelli di dettaglio

- Diversi livelli di dettaglio per i requisiti, inclusi dettagli generici e soluzioni alternative (requisiti aperti).

Esempi

- Requisiti utente: esempio di un sistema che permette di visualizzare e stampare rapporti.
- Requisiti di sistema: esempio di rappresentare e visualizzare file esterni prodotti da altri pacchetti software.

Tipi di requisiti non funzionali

- Classificazione secondo il modello FURPS (Functionality, Usability, Reliability, Performance, Supportability).
- Altri requisiti non funzionali: comprendono manutenibilità, portabilità, efficienza, spazio, performance.

Requisiti di dominio

- Dipendenti dal dominio di operazione del sistema, come le leggi fisiche e/o della tecnologia.

Problemi nell'analisi dei requisiti

- Identificazione di errori potenziali nell'analisi dei requisiti, come la mancata comprensione delle esigenze degli stakeholder o la dimenticanza di requisiti critici.

Riassunto

Le pagine enfatizzano l'importanza di una corretta classificazione e documentazione dei requisiti per il successo dello sviluppo del software, garantendo che tutte le esigenze degli stakeholder siano considerate e che il sistema finale soddisfi sia le esigenze funzionali che quelle non funzionali.

I requisiti: l'anello debole dello sviluppo software

1. Fallimento nei Progetti di Sviluppo Software:
- Uno studio del Standish Group su 8000 progetti mostra un alto tasso di fallimenti parziali e cancellazioni.
- Le principali ragioni del fallimento includono requisiti incompleti, mancanza di coinvolgimento degli utenti, mancanza di risorse, aspettative irrealistiche, mancanza di supporto esecutivo, cambiamento dei requisiti, mancanza di pianificazione e il progetto che non è più necessario.

2. Gestione dei Requisiti e Conflitti:
- Ritardi nell'identificazione dei problemi a causa di azioni insufficienti tra le parti interessate, requisiti in conflitto, mancanza di coinvolgimento degli utenti, feedback inadeguati, rinvio dell'introduzione di nuovi requisiti e superamento dei costi/tempi durante la rinegoziazione.

3. Verifica e Validazione dei Requisiti:
- I requisiti funzionali sono semplici da verificare testando il sistema con gli utenti.
- La verifica dovrebbe assicurare che il sistema funzioni come previsto, considerando correttezza, completezza, coerenza, chiarezza e realismo.
- I requisiti non funzionali possono essere meno quantificabili e richiedere approcci diversi per la validazione.

4. Proprietà dei Requisiti Software:
- Vengono forniti esempi di indicatori quantificabili per proprietà come velocità, dimensione, facilità d'uso, affidabilità, robustezza e portabilità.
- È cruciale tracciare tutte le funzioni del sistema e testare per i cambiamenti per garantire i requisiti di dominio al fine di assicurare l'integrazione con il software aziendale esistente.

Raccolta e analisi dei requisiti

Premessa:
- L'ingegneria dei requisiti è suddivisa in quattro attività principali:
- Raccolta dei requisiti.
- Analisi dei requisiti.
- Stesura della documentazione dei requisiti SRS.
- Verifica e approvazione dei requisiti.

Tipi di raccolta dei requisiti

- Greenfield Engineering: Sviluppo da zero, raccolta dei requisiti presso l'azienda committente.
- Re-engineering: Aggiornamento di un sistema esistente, con focus sulle parti da migliorare o sostituire.
- Interface Engineering: Adattamento dell'interfaccia di un sistema legacy ai nuovi ambienti operativi senza sostituire completamente il software esistente.

La fase di esplorazione

- È la fase in cui si "scava" per raccogliere il maggior numero di informazioni possibili sul sistema da costruire.
- Si utilizzano termini come elicitation o discovery per descrivere il processo di scoperta dei requisiti.

Stakeholder Engagement

- Coinvolgimento attivo degli stakeholder nel processo di definizione dei requisiti.
- La raccolta dei requisiti dagli stakeholder è chiamata anche requirements elicitation.

Tecniche di esplorazione

- Interviste individuali: Per esplorare problemi e aspetti dei punti di vista.
- Focus group: Per focalizzare un argomento e ottenere consenso.
- Osservazioni sul campo: Per comprendere le attività dell'utente.
- Suggerimenti spontanei degli utenti: Per identificare necessità specifiche.
- Questionari: Per raccogliere risposte a domande specifiche.
- Analisi della concorrenza e delle best practice: Per trovare soluzioni migliori note.
- Scenari e casi d'uso: Per descrivere operazioni che il sistema deve effettuare.

Ogni tecnica presenta obiettivi specifici e vantaggi/svantaggi nell'impiego, come la capacità di raccogliere molte informazioni ma con il rischio di ricevere dati con bias, o la difficoltà nel raggiungere il consenso nel caso dei focus group.

Tecniche di esplorazione dei requisiti

- Questionari: Utile per raccogliere rapidamente basi di dati ampie; tuttavia, l'attendibilità delle risposte può essere bassa.
- Focus Group: Brainstorming di gruppo per generare idee; richiede un moderatore esperto e può portare a conflitti.
- Osservazioni sul Campo: Offrono uno sguardo diretto sulle operazioni quotidiane degli utenti, ma potrebbero non rivelare nuove funzioni utili.
- Suggerimenti Spontanei degli Utenti: Possono portare a scoperte inaspettate ma spesso sono basati su esperienze individuali e possono mancare di criticità.
- Analisi della Concorrenza e delle Best Practice: Consente di evitare di "reinventare la ruota" e di scoprire soluzioni migliori adottate nel settore.

Sfide nella fase di esplorazione

- Problemi di Ambito: Difficoltà nell'individuare il livello di dettaglio dei requisiti e nel tradurre i bisogni degli stakeholder in specifiche tecniche.
- Problemi di Comprensione: Difficoltà nell'utilizzare un linguaggio comune tra gli stakeholder e nel comprendere le best practice.
- Problemi di Conflitto: Conflitti tra stakeholder che vedono i requisiti in modo differente.
- Problemi di Volatilità: I requisiti possono cambiare durante il ciclo di vita del progetto, influenzati da fattori esterni come leggi, mercati e strategie aziendali.

Esempi e metafore

- Casi d'Uso: Descrizioni dettagliate di sequenze operative specifiche che il sistema deve essere in grado di eseguire.
- Metafora del Telefono Senza Fili: Illustra la difficoltà di comunicazione chiara e precisa nella trasmissione dei requisiti.
- Metafora della Catena: Analogia per descrivere la gestione dei requisiti come una catena di comprensione e comunicazione tra le varie parti interessate.

Conclusione

- La fase di esplorazione è delicata e vitale, dove non solo si raccolgono i requisiti, ma si devono anche gestire ambiguità, conflitti e cambiamenti, assicurando che i requisiti finali riflettano accuratamente le necessità degli utenti e le capacità del sistema da realizzare.