Concetti Chiave
- Ogni caso d'uso è descritto in modo chiaro e comprensibile per stakeholder non tecnici, utilizzando un linguaggio semplice per evitare ambiguità.
- La corretta analisi dei requisiti è fondamentale per evitare errori nel sistema finale, incidendo su funzionalità, risorse e supporto esecutivo.
- I requisiti software sono classificati in requisiti utente e requisiti di sistema, con dettagli funzionali e non funzionali che garantiscono un'adeguata copertura delle esigenze.
- Le tecniche di raccolta dei requisiti, come interviste e focus group, sono essenziali per ottenere informazioni utili e coinvolgere gli stakeholder nel processo.
- I problemi di ambito e comprensione possono ostacolare la traduzione dei bisogni degli stakeholder in specifiche tecniche, rendendo necessario un linguaggio comune e una gestione dei conflitti.
Indice
Descrizione 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.
- 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.
Errori nell'analisi dei requisiti
- L'errore nell'analisi dei requisiti può introdurre errori nel sistema finale.
- Dimenticanza di funzionalità.
- Realizzazione di requisiti irrilevanti o inutili.
- Resistenza al cambiamento da parte degli stakeholder.
- Introduzione di errori sistematici nell'interpretazione dei requisiti.
- ISO 13407/Human-centred design process per l'analisi dei requisiti.
- Importanza di fondare il progetto sui reali bisogni degli utenti.
- Ogni stakeholder può fornire descrizioni strategiche e operative per il sistema.
- Sono coinvolti nella definizione dei requisiti e nella definizione degli obiettivi del sistema.
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.
- 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à.
- Diversi livelli di dettaglio per i requisiti, inclusi dettagli generici e soluzioni alternative (requisiti aperti).
- 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.
- Classificazione secondo il modello FURPS (Functionality, Usability, Reliability, Performance, Supportability).
- Altri requisiti non funzionali: comprendono manutenibilità, portabilità, efficienza, spazio, performance.
- Dipendenti dal dominio di operazione del sistema, come le leggi fisiche e/o della tecnologia.
- Identificazione di errori potenziali nell'analisi dei requisiti, come la mancata comprensione delle esigenze degli stakeholder o la dimenticanza di requisiti critici.
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.
1. Fallimento nei Progetti di Sviluppo Software:
Fallimento nei progetti 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:
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:
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.
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.
- 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 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.
- Coinvolgimento attivo degli stakeholder nel processo di definizione dei requisiti.
- La raccolta dei requisiti dagli stakeholder è chiamata anche requirements elicitation.
Tecniche di raccolta dei requisiti
- 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.
- 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.
Problemi di ambito e comprensione
- 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.
- Casi d'Uso: Descrizioni dettagliate di sequenze operative specifiche che il sistema deve essere in grado di eseguire.
Metafore e gestione dei requisiti
- 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.
- 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.
Domande da interrogazione
- Qual è l'importanza di una chiara descrizione dei casi d'uso per gli stakeholder?
- Quali sono le conseguenze di un'errata analisi dei requisiti?
- Come vengono classificati i requisiti software?
- Quali tecniche possono essere utilizzate per la raccolta dei requisiti?
- Quali problemi possono sorgere nella gestione dei requisiti?
Una chiara descrizione dei casi d'uso è fondamentale per garantire che anche gli stakeholder non tecnici comprendano le funzionalità del sistema, iniziando dal "happy path" e includendo alternative e eccezioni, come indicato nel testo.
L'errata analisi dei requisiti può portare a errori nel sistema finale, come la dimenticanza di funzionalità o la creazione di requisiti irrilevanti, evidenziando l'importanza di un'analisi accurata e centrata sugli utenti.
I requisiti software sono classificati in requisiti utente, requisiti di sistema, requisiti funzionali e non funzionali, con dettagli specifici per ciascuna categoria, come descritto nel testo.
Tecniche come interviste, focus group, osservazioni sul campo e questionari sono utilizzate per raccogliere requisiti, ognuna con i propri vantaggi e svantaggi, come indicato nel documento.
Problemi di ambito, comprensione, conflitto e volatilità possono influenzare la gestione dei requisiti, rendendo difficile tradurre i bisogni degli stakeholder in specifiche tecniche, come evidenziato nel testo.
Accedi a tutti gli appunti
Tutor AI: studia meglio e in meno tempo
