Questo tutorial spiega cos’è l’analisi dei requisiti, le fasi di analisi dei requisiti, gli esempi e gli obiettivi della raccolta dei requisiti in SDLC:
Lo sviluppo del software è un compito enorme che crea un prodotto software funzionante.
Il prodotto software è costruito secondo il requisito del cliente. Principalmente, questo prodotto software è conforme a ciò che il cliente/utente finale si aspettava, mentre a volte questo prodotto non è pienamente conforme a ciò che il cliente/utente finale si aspettava.
Che cos’è l’analisi dei requisiti?
Cerchiamo di capire l’analisi dei requisiti con l’aiuto di un esempio.
Aspettativa cliente / utente finale:
Ricezione cliente/utente finale:
Come è possibile analizzare dalle immagini di cui sopra che c’è una mancata corrispondenza nel prodotto finale alle aspettative del cliente. Questo potrebbe essere dovuto a una miriade di motivi, vale a dire. implementazione errata dei requisiti del cliente, progettazione difettosa, comprensione errata dei requisiti del cliente da parte dei programmatori e del team di qualità, ecc.
Tuttavia, come puoi vedere, sia per qualsiasi motivo di consegna errata del prodotto, il motivo principale va al requisito. Quindi, se fosse stata eseguita una corretta comprensione, acquisizione, implementazione e test dei requisiti, avrebbe contribuito a mitigare la consegna errata e incompleta del prodotto al cliente/utente finale.
Una buona consegna del prodotto richiede la corretta raccolta dei requisiti, l’esame efficiente dei requisiti raccolti e, infine, la documentazione dei requisiti chiari, come condizione preliminare. Questo intero processo è anche chiamato come analisi dei requisiti nel ciclo di vita dello sviluppo software (SDLC)
Fasi/fasi di analisi dei requisiti
Come si può vedere, l’analisi dei requisiti è la prima attività in SDLC seguita da specifiche funzionali e così via. L’analisi dei requisiti è un passo fondamentale in SDLC in quanto risuona con i test di accettazione che sono fondamentali per l’accettazione del prodotto da parte dei clienti.
In questo tutorial, spiegheremo come viene eseguita l’analisi dei requisiti in SDLC. Vedremo anche i vari passaggi coinvolti, i risultati, le sfide e le misure correttive nell’analisi dei requisiti.
L’analisi dei requisiti inizia con:
- Requisito di raccolta che è anche chiamato come elicitazione.
- Questo è seguito dall’analisi dei requisiti raccolti per comprendere la correttezza e la fattibilità della conversione di questi requisiti in un possibile prodotto.
- E, infine, documentare i requisiti raccolti.
#1) Raccolta dei requisiti
Per assicurarsi che tutti i passaggi sopra menzionati siano eseguiti in modo appropriato, i requisiti chiari, concisi e corretti devono essere raccolti dal cliente. Il cliente dovrebbe essere in grado di definire correttamente i propri requisiti e l’analista aziendale dovrebbe essere in grado di raccoglierli nello stesso modo in cui il cliente intende trasmetterli.
Molte volte non è possibile che la raccolta dei requisiti sia eseguita in modo efficiente dagli analisti aziendali del cliente. Ciò potrebbe essere dovuto alla dipendenza da molte persone relative al prodotto finale previsto, agli strumenti, all’ambiente, ecc. Pertanto, è sempre una buona idea coinvolgere tutti gli stakeholder che potrebbero influenzare o potrebbero essere influenzati dal prodotto finale.
Il possibile gruppo di stakeholder potrebbe essere ingegneri della qualità del software (sia QC che QA), qualsiasi fornitore terzo che potrebbe fornire supporto nel progetto, utente finale per il quale il prodotto è destinato, programmatori di software, un altro team all’interno dell’organizzazione che potrebbe fornire un modulo o una piattaforma software, librerie software, ecc. per lo sviluppo del prodotto.
Esempio: In un’organizzazione, sviluppano un prodotto ADAS (surround-view camera system per un prestigioso OEM) che necessita di stack Autosar e Bootloader binari ricevuti da un altro fornitore.
Coinvolgere varie parti interessate nella fase di raccolta dei requisiti aiuta a comprendere le varie dipendenze l’una dall’altra e ogni possibile conflitto futuro potrebbe essere evitato.
A volte, è una buona idea creare un modello prototipo del prodotto previsto pianificato e mostrarlo al cliente. Questo è un ottimo modo per trasmettere ai clienti quale prodotto si aspettano e come potrebbe apparire in seguito. Questo aiuta il cliente a visualizzare il prodotto che si aspettano e li aiuta a venire con requisiti chiari.
La creazione di questo prototipo dipende da due tipi di prodotto:
- Un prodotto simile che i clienti intendevano, esiste all’interno dell’organizzazione.
- Nuovo prodotto da sviluppare.
(i) Nel primo caso, è più facile mostrare al cliente come sarebbe il prodotto finale e come sarebbe stato sviluppato. In ADAS automotive, è possibile mostrare ai clienti un altro prodotto che è già sul mercato ed è stato sviluppato all’interno dell’organizzazione.
Ad esempio, un sistema di telecamere surround-view sviluppato per un OEM (GM, Volkswagen, BMW, ecc.) e può essere montrato ad un altro OEM.
Si prega di notare, non è saggio mostrare il prodotto / prodotto proto al cliente che è in fase di sviluppo in quanto potrebbe violare l’Accordo di non divulgazione firmato con un altro cliente per il quale tale prodotto è in fase di sviluppo. Può anche provocare una rissa legale inutile.
Un altro esempio potrebbe essere quello del sistema di infotainment, in fase di sviluppo da parte dell’organizzazione, ed è già sul mercato. Gli analisti aziendali e le altre parti interessate all’interno di un’organizzazione possono pianificare una demo del workshop per il cliente, visualizzando sistemi di infotainment con HMI tangibile, porte del connettore del dispositivo, sandbox, ecc.
Ciò aiuterà il cliente a capire come apparirebbe il prodotto finale e a fornire le proprie esigenze in modo molto più chiaro.
(ii) Il secondo caso può essere ottenuto creando un modello di lavoro di base eseguendo semplici codifiche e assemblaggi (per lo più le caratteristiche qui sono codificate nei programmi software), o creando un diagramma di flusso o un diagramma che potrebbe convincere il cliente come apparirebbe il prodotto.
In ogni caso, sarebbe una pausa per il processo di raccolta dei requisiti in quanto il cliente ora sa cosa vuole.
L’analista aziendale può ora organizzare riunioni formali di elicitazione dei requisiti, in cui tutti gli stakeholder potrebbero essere invitati e quindi annotare i vari requisiti forniti dal cliente (in alcuni casi, se gli stakeholder sono più numerosi, potrebbe essere nominato uno scriba separato per annotare i requisiti dei clienti o le storie degli utenti in modo che l’analista aziendale possa concentrarsi
I requisiti raccolti possono essere sotto forma di storie utente (nello sviluppo agile), casi d’uso, documenti in linguaggio naturale del cliente, diagrammi, diagrammi di flusso, ecc. Le storie degli utenti stanno diventando popolari nel ciclo di vita dello sviluppo software moderno. Le storie degli utenti sono fondamentalmente un insieme di input dei clienti nel loro linguaggio naturale.
Esempio di raccolta dei requisiti: Nel sistema di telecamere surround ADAS, una possibile storia utente potrebbe essere:”Come utente, dovrei essere in grado di vedere cosa c’è nel retrovisore della mia auto”.
Potrebbero esserci molte domande” perché ” poste su ogni storia utente, che aiuteranno il cliente a fornire informazioni più dettagliate sul requisito.
l’utente sopra indicato storia, se un cliente dice “Come utente, dovrei essere in grado di vedere cosa c’è nello specchietto retrovisore della mia auto”, che chiede la domanda “perché” potrebbe dare “Come utente, dovrei essere in grado di vedere cosa c’è nello specchietto retrovisore della mia auto, in modo che posso parcheggiare la mia auto in modo sicuro”.
Porre la domanda “perché” aiuta anche a creare requisiti oggettivi e atomici da dichiarazioni di linguaggio naturale humongous fornite dal cliente. Questo può essere facilmente implementato più avanti nel codice.
Un altro modo di raccogliere il requisito è sotto forma di casi d’uso. Un caso d’uso è un approccio graduale per ottenere un determinato risultato. Questo non dice come il software funzionerà sull’input dell’utente piuttosto dice, cosa ci si aspetta dagli input dell’utente.
Esempio:
#2) Analizzando i requisiti raccolti
Raccolta dei requisiti post, inizia l’analisi dei requisiti. In questa fase, varie parti interessate si siedono e fanno una sessione di brainstorming. Analizzano i requisiti raccolti e cercano la fattibilità per implementarli. Discutono tra loro e ogni ambiguità viene risolta.
Questo passaggio è importante nel processo di analisi dei requisiti a causa dei seguenti motivi principali:
(i) Il cliente può fornire alcuni requisiti che potrebbero essere impossibili da implementare a causa di varie dipendenze.
Esempio: I clienti possono chiedere di surround-view il sistema di telecamere con una funzione di telecamera per la retromarcia che vi aiuterà a parcheggiare l’auto. Il cliente può anche chiedere la funzione di aggancio del rimorchio che utilizza anche la fotocamera posteriore per funzionare.
Se il cliente dichiara un requisito che la telecamera per la retromarcia per l’assistenza al parcheggio dovrebbe funzionare in ogni momento senza eccezioni, la funzione Trailer non funzionerebbe mai e viceversa.
(ii) Un analista aziendale potrebbe aver compreso il requisito del cliente in modo diverso da come un programmatore avrebbe interpretato.
Poiché i programmatori pensano come esperti tecnici, è sempre possibile che i requisiti del cliente siano convertiti in modo errato in specifiche funzionali che verranno successivamente erroneamente apportate ai documenti di architettura e design e successivamente al codice. L’impatto è esponenziale e quindi dovrebbe essere controllato.
Una possibile misura correttiva potrebbe essere seguendo un metodo agile di sviluppo del software, seguendo i casi d’uso forniti dal cliente, ecc.
#3) Documentare i requisiti analizzati
Una volta eseguita l’analisi dei requisiti, inizia la documentazione dei requisiti. Dall’analisi dei requisiti emergono vari tipi di requisiti.
Alcuni di questi sono:
(i) Specifica dei requisiti del cliente.
(ii) Requisito dell’architettura software.
Esempio:
(iii) Requisito di progettazione del software.
Esempio:
(iv) Specificazione funzionale di requisito (direttamente derivata dalle specifiche del cliente.)
Esempio: “Quando l’utente tocca l’icona Bluetooth sull’HMI di Infotainment, deve essere visualizzata la schermata Bluetooth”
(v) Non-Functional Requirement specification (viz. prestazioni, stress, carico, ecc.).
Esempio: “Dovrebbe essere possibile accoppiare 15 dispositivi Bluetooth con il sistema di infotainment senza degradare le prestazioni del sistema”.
(vi) Requisiti dell’interfaccia utente.
Esempio: “Sulla schermata del sintonizzatore FM, è necessario fornire un pulsante per selezionare diverse stazioni”
I requisiti di cui sopra sono registrati e documentati in strumenti di gestione dei requisiti, come IBM DOORS, HP QC. A volte le organizzazioni hanno i loro strumenti di gestione dei requisiti su misura per ridurre i costi.
Esaminiamo ora il processo di conversione dei requisiti aziendali in requisiti software (funzionali e non funzionali).
Conversione dei requisiti aziendali in requisiti software
Requisiti aziendali, come discusso sopra, sono requisiti di alto livello che parlano di ciò che l’utente finale desidera da un’azione definita sul sistema software. Lo sviluppo dell’intero sistema software basato su questi requisiti non è possibile in quanto non viene menzionata una descrizione dettagliata di come il sistema software o il componente verrà implementato.
Pertanto, i requisiti aziendali devono essere suddivisi in requisiti software più dettagliati che saranno ulteriormente dettagliati in base a requisiti funzionali e non funzionali.
Per fare ciò, è possibile seguire i seguenti passaggi:
- Abbattere i requisiti di business di alto livello per storie utente dettagliate.
- Derivare un diagramma di flusso per definire il flusso di attività.
- Fornire la condizione che giustifica le storie utente derivate.
- Diagrammi wireframe per spiegare il flusso di lavoro degli oggetti.
- Definizione di requisiti non funzionali fuori dai requisiti aziendali.
Iniziamo prendendo un esempio di sistema di infotainment automobilistico.
Il requisito aziendale dice: “L’utente finale dovrebbe essere in grado di accedere alla casella widget di navigazione dal sistema di infotainment HMI e dovrebbe essere in grado di impostare l’indirizzo di destinazione”.
Quindi, i passaggi sopra elencati possono essere implementati come:
#1) Abbattere i requisiti di business di alto livello per storie utente dettagliate.
Convertiamo questo requisito aziendale in una storia utente di alto livello, “Come utente, dovrei essere in grado di accedere alla casella del widget di navigazione in modo da poter inserire l’indirizzo di destinazione”. Questa storia utente racconta ciò che è necessario per l’utente finale. Cercheremo di definire come implementare questo requisito.
Iniziamo ponendo possibili domande a questa storia utente cioè.
- Chi sono gli utenti?
- Come posso accedere alla navigazione, a bordo (da scheda SD) o da SmartPhone?
- Che tipo di voci di destinazione posso inserire?
- Devo essere autorizzato a entrare nella destinazione anche quando l’auto è in parcheggio?
Queste sono storie utente di livello più dettagliate derivate da storie utente di alto livello e ci aiuterebbero a ottenere maggiori informazioni sui nostri requisiti aziendali.
A questo punto, possiamo prendere una delle sotto-storie degli utenti e iniziare a mettere in discussione. Prendiamo (no. 3):
- Posso inserire voci di destinazione come coordinate geografiche,indirizzo postale, tramite riconoscimento vocale, ecc.?
- Ho bisogno del GPS per inserire le coordinate geografiche?
- È possibile inserire l’indirizzo di destinazione corrente effettuando una ricerca dalla cronologia degli indirizzi?
#2) Derivazione di un diagramma di flusso per definire il flusso di attività.
Ora possiamo vedere che il requisito aziendale è suddiviso in casi d’uso molto dettagliati che possono essere contrassegnati nel diagramma di flusso come di seguito:
#3) Fornire condizioni che giustificano storie utente derivate.
Possiamo vedere che informazioni più dettagliate stanno emergendo a causa della scomposizione del requisito di business di alto livello in storie utente dettagliate di basso livello e al diagramma di flusso. Da questo diagramma di flusso, possiamo ottenere i dettagli tecnici necessari per l’implementazione vale a dire.
- Il tempo di caricamento dello schermo per visualizzare la voce di destinazione dovrebbe essere di 1 sec.
- La tastiera di immissione di destinazione dovrebbe avere caratteri alfanumerici e simboli speciali.
- Il pulsante di attivazione/disattivazione GPS deve essere presente nella schermata di immissione della destinazione di navigazione.
Le informazioni di cui sopra soddisfano le storie degli utenti e rendono possibile che il requisito sia testato in modo discreto e misurabile evitando qualsiasi confusione con il requisito mentre viene implementato come funzionalità.
#4) Diagrammi wireframe per spiegare il flusso di lavoro degli oggetti.
Dal caso d’uso di cui sopra, ricaveremo un diagramma wireframe che renderà l’interfaccia utente più chiara.
#5) Definizione di requisiti non funzionali fuori dai requisiti aziendali.
È imperativo che i requisiti software dettagliati derivino da requisiti aziendali di alto livello, ma molte volte vengono identificati solo requisiti funzionali che indicano come un sistema si comporterà con un particolare input/azione dell’utente.
Tuttavia, i requisiti funzionali non chiariscono le prestazioni dei sistemi e altri parametri qualitativi come disponibilità,affidabilità, ecc.
Esempi:
a) Prenderemo l’esempio del sistema di infotainment automobilistico di cui sopra.
Se il conducente (utente finale) della vettura riproduce musica da USB e guida di navigazione è in corso, ottiene anche una chiamata in arrivo via Bluetooth in modalità vivavoce quindi caricare su CPU e RAM consumo aumenta ad un livello massimo come più processi sono in esecuzione in background.
A questo punto, se il conducente tocca un’interfaccia touchscreen del sistema di infotainment per rifiutare la chiamata in arrivo tramite SMS di risposta automatica (come facciamo nei nostri telefoni cellulari), il sistema dovrebbe essere in grado di eseguire questa operazione e non dovrebbe bloccarsi o bloccarsi. Questa è la prestazione del sistema quando il carico è elevato e testiamo disponibilità e affidabilità.
b) Un altro caso è lo scenario di stress.
Prendiamo un esempio, il sistema di infotainment riceve back to back SMS (forse 20 SMS entro 10 sec) tramite telefono Bluetooth collegato. Il sistema di infotainment dovrebbe essere in grado di gestire tutti gli SMS in arrivo e in nessun momento dovrebbe perdere nessuna delle notifiche SMS in arrivo su Infotainment HMI.
Gli esempi sopra riportati sono casi di requisiti non funzionali che non possono essere testati tramite i soli requisiti funzionali. Anche se a volte, i clienti mancano di fornire questi requisiti non funzionali. È responsabilità dell’organizzazione fornire loro queste informazioni, quando un prodotto viene consegnato al cliente.
Comprendere i Requisiti Non funzionali Casi
La seguente tabella illustra i requisiti non funzionali:
| SL N | Funzione/caso d’uso | il carico della CPU(max) | utilizzo di RAM(il massimo di 512MB) | Parametri di Performance |
|---|---|---|---|---|
| 1 | Max no. di dispositivi Bluetooth che può essere abbinato al sistema di Infotainment | 75% | 300 MB | 10 dispositivi Bluetooth |
| 2 | il Tempo di scaricare 2000 contatti del Telefono nel sistema di Infotainment dopo l’accoppiamento Bluetooth e connessione | 90% | 315 MB | 120 Secondi |
| 3 | Tempo per eseguire la Scansione di tutte disponibili le stazioni FM Tuner nel sistema di infotainment | 50% | 200 MB | 30 Secondi |
i requisiti Non funzionali, a differenza di requisiti funzionali, prendi il ciclo di vita completo di un progetto per essere implementato, poiché vengono implementati in modo incrementale nei rispettivi sprint Agili o in diverse iterazioni.
Quindi, questo è il modo in cui deriviamo i requisiti software dai requisiti aziendali.
Differenza tra requisiti aziendali e requisiti software
Abbiamo visto sopra come derivare i requisiti software da requisiti aziendali di alto livello. I requisiti software consentono al programmatore e all’ingegnere di test di sviluppare il sistema e testarlo in modo efficiente. Quindi, ora sappiamo che i requisiti aziendali sono requisiti di linguaggio naturale dei clienti di alto livello mentre i requisiti software sono requisiti dettagliati di basso livello che aiutano nell’implementazione del sistema software.
Esaminiamo la differenza dettagliata tra i due tipi di requisiti.
| Requisiti aziendali | Requisiti software |
|---|---|
| Sono requisiti di alto livello da parte di un cliente che dice “cosa” dovrebbe fare il sistema. Questi requisiti non dicono “come” i requisiti dovrebbero funzionare. | Si concentrano sull’aspetto “come” delle esigenze del cliente. Questi requisiti spiegano come il sistema funzionerebbe / implementerebbe. |
| Questi requisiti riguardano l’obiettivo aziendale di un’organizzazione. Esempio: L’utente dovrebbe essere in grado di impostare la destinazione di navigazione. |
Questi requisiti spiegano il know-how tecnico dei requisiti. Esempio: quando l’utente fa clic sull’icona della destinazione di navigazione, il database deve caricare i dettagli della destinazione da inserire. |
| I requisiti aziendali si concentrano sul vantaggio dell’organizzazione. Esempio: Se la navigazione non è presente sul sistema e l’utente tocca l’icona di navigazione, l’utente deve ricevere informazioni per l’aggiornamento della funzione di navigazione dal rivenditore nel sistema di infotainment. |
I requisiti software trattano i dettagli di implementazione dei requisiti aziendali nel sistema. Esempio: quando l’utente fa clic sull’icona di navigazione sul sistema di infotainment, deve essere avviata una chiamata API per la visualizzazione di un messaggio all’utente per l’aggiornamento del sistema. |
| I requisiti aziendali sono normalmente scritti in linguaggio naturale o storie di utenti di alto livello. | I requisiti software sono funzionali e non funzionali. Esempio: di requisiti non funzionali sono prestazioni, stress, portabilità, usabilità, ottimizzazione della memoria, aspetto grafico, ecc. |
Conclusione
L’analisi dei requisiti è la spina dorsale di qualsiasi modello SDLC.
Un problema mancato durante l’analisi dei requisiti e catturato durante i test unitari potrebbe costare decine di migliaia di dollari a un’organizzazione e questo costo potrebbe portare a milioni di dollari se proviene dal mercato come richiamata (in 2017, USA ha addebitato al produttore di airbag, Takata una multa di $1 miliardo a causa dell’esplosione degli airbag).
L’organizzazione finirebbe per eseguire attività di controllo dei danni come l’analisi delle cause principali, la preparazione di documenti 5 why, analisi dell’albero dei guasti, documento 8D, ecc. invece di concentrarsi sullo sviluppo del software e sulla qualità.
Nel peggiore dei casi, l’organizzazione verrebbe trascinata in cause legali presentate dal cliente se la funzione interessata è correlata alla sicurezza/sicurezza come accesso di sicurezza, airbag, ABS (sistema di frenatura antibloccaggio), ecc.