Che cos'è l'analisi e la raccolta dei requisiti in SDLC?

what is requirement analysis

Questo tutorial spiega cos'è l'analisi dei requisiti, i passaggi dell'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 le esigenze del cliente. Per lo più, questo prodotto software è conforme a ciò che il cliente / utente finale si aspettava, mentre a volte questo prodotto non è completamente conforme a ciò che il cliente / utente finale si aspettava.

Cosa imparerai:

• Che cos'è l'analisi dei requisiti?
  • Fasi / passaggi dell'analisi dei requisiti
    • # 1) Raccolta dei requisiti
    • # 2) Analisi dei requisiti raccolti
    • # 3) Documentazione dei requisiti analizzati
  • Conversione dei requisiti aziendali in requisiti software
  • Comprensione dei casi di requisiti non funzionali
  • Differenza tra requisiti aziendali e requisiti software
• Conclusione
  • Lettura consigliata

Che cos'è l'analisi dei requisiti?

Cerchiamo di comprendere l'analisi dei requisiti con l'aiuto di un esempio.

Aspettative del cliente / utente finale:

Il cliente / utente finale riceve:

Come puoi analizzare dalle immagini sopra, c'è una mancata corrispondenza nel prodotto finale con le aspettative del cliente. Ciò 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 che si tratti di un motivo per la consegna errata del prodotto, il motivo principale va al requisito. Pertanto, se fossero stati eseguiti correttamente la comprensione, l'acquisizione, l'implementazione e il test dei requisiti, avrebbe contribuito a mitigare la consegna errata e incompleta del prodotto al cliente / utente finale.

Una buona consegna del prodotto richiede una corretta raccolta dei requisiti, un esame efficiente dei requisiti raccolti e infine una documentazione chiara dei requisiti, come condizione preliminare. L'intero processo è anche chiamato come Analisi dei requisiti nel ciclo di vita dello sviluppo software (SDLC)

Fasi / passaggi dell'analisi dei requisiti

Come puoi vedere, l'analisi dei requisiti è la prima attività in SDLC seguita dalla specifica funzionale e così via. L'analisi dei requisiti è un passaggio 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:

1. Raccolta dei requisiti che è anche chiamato come elicitazione.
2. Questo è seguito da analizzando i requisiti raccolti per comprendere la correttezza e la fattibilità di convertire questi requisiti in un possibile prodotto.
3. E infine, documentare i requisiti raccolti.

# 1) Raccolta dei requisiti

Per assicurarsi che tutti i passaggi sopra menzionati siano eseguiti in modo appropriato, è necessario raccogliere dal cliente requisiti chiari, concisi e corretti. 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 venga eseguita in modo efficiente dagli analisti aziendali del cliente. Ciò potrebbe essere dovuto alla dipendenza da molte persone in relazione al prodotto finale, agli strumenti, all'ambiente e così via previsti. 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 di terze parti che potrebbe fornire supporto nel progetto, utente finale a cui è destinato il prodotto, programmatori 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 (sistema di telecamere surround per un prestigioso OEM) che necessita Stack Autosar e Boot loader binari ricevuti da un altro fornitore.

Coinvolgere le 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 comunicare ai clienti quale prodotto si aspettano e come potrebbe apparire in seguito. Questo aiuta il cliente a visualizzare il prodotto che si aspetta e lo aiuta a trovare requisiti chiari.

La creazione di questo prototipo dipende da due tipi di prodotto:

1. Un prodotto simile a quello previsto dai clienti esiste all'interno dell'organizzazione.
2. Nuovo prodotto da sviluppare.

(io) Nel primo caso, è più facile mostrare al cliente come sarebbe il prodotto finale e come sarebbe sviluppato. Nell'ADAS automobilistico, è possibile mostrare ai clienti un altro prodotto che è già sul mercato ed è stato sviluppato all'interno dell'organizzazione.

Per esempio, Un sistema di telecamere con vista surround sviluppato per un OEM (GM, Volkswagen, BMW, ecc.) E può essere presentato a un altro OEM.

notare che , non è saggio mostrare il prodotto / prototipo al cliente che è in fase di sviluppo in quanto potrebbe violare l'accordo di riservatezza firmato con un altro cliente per il quale il prodotto è in fase di sviluppo. Potrebbe anche comportare una lotta legale non necessaria.

Un altro esempio potrebbe essere quello del sistema di infotainment, in fase di sviluppo da parte dell'organizzazione, ed è già presente sul mercato. Gli analisti aziendali e altre parti interessate all'interno di un'organizzazione possono pianificare una demo di workshop per il cliente, visualizzando i sistemi di infotainment con HMI tangibile, porte per connettori del dispositivo, sandbox, ecc.

Ciò aiuterà il cliente a capire come apparirà il prodotto finale e fornirà le sue esigenze in modo molto più chiaro.

(ii) Il secondo caso può essere ottenuto creando un modello di lavoro di base eseguendo una semplice codifica e assemblaggio (la maggior parte delle caratteristiche qui sono codificate in programmi software) o creando un diagramma di flusso o un diagramma che potrebbe convincere il cliente come sarebbe il prodotto.

In ogni caso, sarebbe un attimo di respiro per il processo di raccolta dei requisiti poiché il cliente ora sa cosa vuole.

L'analista aziendale può ora organizzare riunioni formali di sollecitazione dei requisiti, in cui tutti gli stakeholder potrebbero essere invitati e quindi può annotare i vari requisiti forniti dal cliente (in alcuni casi, se gli stakeholder sono più numerosi, potrebbe essere nominato uno scriba separato per annotare il cliente requisiti o storie degli utenti in modo che l'analista aziendale possa concentrarsi sulla moderazione della riunione).

I requisiti raccolti possono essere sotto forma di storie degli utenti (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 del 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'è nello specchietto retrovisore della mia auto'.

Potrebbero essere molti 'perché,' domande poste su ciascuna user story, che aiuteranno il cliente a fornire informazioni più dettagliate sul requisito.

Nella user story sopra, se un cliente dice 'Come utente, dovrei essere in grado di vedere cosa c'è nel retrovisore della mia auto', ponendo una domanda 'perché 'Potrebbe dare' Come utente, dovrei essere in grado di vedere cosa c'è nello specchietto retrovisore della mia macchina, in modo da poter parcheggiare l'auto in sicurezza '.

Facendo la domanda 'perché' aiuta anche a creare requisiti oggettivi e atomici da affermazioni in linguaggio naturale gigantesche fornite dal cliente. Questo può essere facilmente implementato più avanti nel codice.

oops concetti in c # con esempi per esperti

Un altro modo per 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 funzionerà il software sull'input dell'utente, piuttosto dice cosa ci si aspetta dagli input dell'utente.

Esempio:

# 2) Analisi dei requisiti raccolti

Dopo la raccolta dei requisiti, 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 di loro e ogni ambiguità viene risolta.

Questo passaggio è importante nel processo di analisi dei requisiti per i seguenti motivi principali:

(io) Il cliente può fornire alcuni requisiti che potrebbero essere impossibili da implementare a causa di varie dipendenze.

Esempio: Clientipotrebbe chiedere di visualizzare in surround il sistema di telecamere con una funzione di telecamera per la retromarcia che aiuterà parcheggio la macchina. Il cliente può anche richiedere il trailer funzione di intoppo che utilizza anche la fotocamera posteriore per funzionare.

Se il cliente afferma un requisito per la telecamera per la retromarcia parcheggio l'assistenza dovrebbe funzionare in ogni momento senza eccezioni, quindi il trailer caratteristica non funzionerebbe mai e viceversa.

(ii) Un analista aziendale potrebbe aver compreso il requisito del cliente diversamente da come a programmatore avrebbe interpretato.

Poiché i programmatori pensano come esperti tecnici, è sempre possibile che i requisiti del cliente vengano convertiti in modo errato in specifiche funzionali che verranno successivamente trasformate in modo errato in documenti di architettura e progettazione e successivamente in codice. L'impatto è esponenziale e quindi va verificato.

Una possibile misura correttiva potrebbe essere quella di seguire un metodo agile di sviluppo del software, seguire i casi d'uso forniti dal cliente, ecc.

# 3) Documentazione dei requisiti analizzati

Una volta completata l'analisi dei requisiti, inizia la documentazione dei requisiti. Dall'analisi dei requisiti emergono vari tipi di requisiti.

Alcuni di questi sono:

(io) Specifica dei requisiti del cliente.

(ii) Requisiti dell'architettura software.

Esempio:

(iii) Requisiti di progettazione del software.

Esempio:

(iv) Specifica dei requisiti funzionali (derivata direttamente dalle specifiche del cliente).

Esempio: 'Quando l'utente tocca l'icona Bluetooth sull'HMI di Infotainment, dovrebbe essere visualizzata la schermata Bluetooth'

(v) Specifica dei requisiti non funzionali (ovvero prestazioni, stress, carico, ecc.).

Esempio: 'Dovrebbe essere possibile accoppiare 15 dispositivi Bluetooth con il sistema di infotainment senza degrado delle prestazioni del sistema'.

(noi) Requisiti dell'interfaccia utente.

Esempio: 'Nella schermata Tuner FM, dovrebbe essere fornito 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 dispongono di strumenti di gestione dei requisiti personalizzati per ridurre i costi.

Esaminiamo ora il processo di conversione Requisiti aziendali per Requisiti software (funzionale e non funzionale).

Conversione dei requisiti aziendali in requisiti software

I 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. Non è possibile sviluppare l'intero sistema software sulla base di questi requisiti in quanto non viene menzionata una descrizione dettagliata di come verrà implementato il sistema o il componente software.

Pertanto, i requisiti aziendali devono essere suddivisi in requisiti software più dettagliati che saranno ulteriormente dettagliati in requisiti funzionali e non funzionali.

Per fare ciò, è possibile seguire i seguenti passaggi:

1. Suddividi i requisiti aziendali di alto livello in storie utente dettagliate.
2. Derivazione di un diagramma di flusso per definire il flusso delle attività.
3. Fornire la condizione che giustifica le storie utente derivate.
4. Diagrammi wireframe per spiegare il flusso di lavoro degli oggetti.
5. Definizione di requisiti non funzionali al di fuori dei requisiti aziendali.

Cominciamo prendendo un esempio di sistema di infotainment automobilistico.

Il requisito aziendale dice: 'L'utente finale dovrebbe essere in grado di accedere al riquadro del widget di navigazione dall'HMI del sistema Infotainment e dovrebbe essere in grado di impostare l'indirizzo di destinazione'.

Quindi, i passaggi sopra elencati possono essere implementati come:

# 1) Suddividi i requisiti aziendali di alto livello in storie utente dettagliate.

Trasformiamo questo requisito aziendale in una user story 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 user story racconta ciò di cui ha bisogno l'utente finale. Cercheremo di definire come implementare questo requisito.

Cominciamo ponendo possibili domande a questa visualizzazione della storia utente.

1. Chi sono gli utenti?
2. Come posso accedere alla navigazione, a bordo (da scheda SD) o da SmartPhone?
3. Che tipo di voci di destinazione posso inserire?
4. Devo essere autorizzato a inserire la destinazione anche quando l'auto è in parcheggio?

Queste sono user story di livello più dettagliate derivate da user story di alto livello e ci aiuterebbero a ottenere una visione più approfondita dei nostri requisiti aziendali.

A questo punto, possiamo riprendere una delle sottostorie degli utenti e iniziare a fare domande. Prendiamo (n. 3):

1. Posso inserire voci di destinazione come coordinate geografiche, indirizzo postale, tramite riconoscimento vocale, ecc.?
2. Ho bisogno del GPS per inserire le coordinate geografiche?
3. Posso inserire l'indirizzo di destinazione attuale effettuando una ricerca nella cronologia degli indirizzi?

# 2) Derivazione di un diagramma di flusso per definire il flusso delle attività.

Ora possiamo vedere che i requisiti aziendali sono suddivisi 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 stanno emergendo informazioni più dettagliate a causa della scomposizione dei requisiti aziendali di alto livello in storie utente dettagliate di basso livello e nel diagramma di flusso. Da questo diagramma di flusso, possiamo ottenere i dettagli tecnici necessari per l'implementazione.

• Il tempo di caricamento dello schermo per visualizzare l'immissione della destinazione dovrebbe essere di 1 secondo.
• La tastiera per l'inserimento della destinazione deve contenere caratteri alfanumerici e simboli speciali.
• Il pulsante di attivazione / disattivazione GPS dovrebbe essere presente nella schermata di immissione della destinazione di navigazione.

Le informazioni di cui sopra soddisfano le storie degli utenti e consentono di testare il requisito in modo discreto e misurabile evitando qualsiasi confusione con il requisito mentre vengono implementate come funzionalità.

# 4) Diagrammi wireframe per spiegare il flusso di lavoro degli oggetti.

Dal caso d'uso di cui sopra, deriveremo un diagramma wireframe che renderà più chiara l'interfaccia utente.

# 5) Definizione dei requisiti non funzionali 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 si comporterà un sistema a 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:

configurazione di c ++ in eclipse

a) Prenderemo l'esempio del sistema di infotainment automobilistico di cui sopra.

Se il conducente (utente finale) dell'auto riproduce musica da USB e la guida di navigazione è in corso, riceve anche una chiamata in arrivo tramite Bluetooth in modalità vivavoce, quindi il carico su CPU e RAM aumenta al livello massimo quando vengono eseguiti più processi in esecuzione in background.

A questo punto, se il conducente tocca l'interfaccia touchscreen di un sistema di infotainment per rifiutare una chiamata in arrivo tramite SMS di risposta automatica (allo stesso modo di come facciamo con i 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 noi testiamo disponibilità e affidabilità.

b) Un altro caso è lo scenario di stress.

Ad esempio, il sistema di infotainment riceve SMS consecutivi (forse 20 SMS entro 10 secondi) tramite il telefono Bluetooth connesso. 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 sull'HMI di Infotainment.

Gli esempi precedenti sono casi di requisiti non funzionali che non possono essere testati tramite i soli requisiti funzionali. Anche se a volte, i clienti non riescono a fornire questi requisiti non funzionali. È responsabilità dell'organizzazione fornire loro queste informazioni quando un prodotto viene consegnato al cliente.

Comprensione dei casi di requisiti non funzionali

La tabella seguente spiega i requisiti non funzionali:

I requisiti non funzionali, a differenza dei requisiti funzionali, richiedono l'intero ciclo di vita di un progetto per essere implementati, poiché vengono implementati in modo incrementale nei rispettivi Agile Sprint 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 del cliente 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.

Conclusione

L'analisi dei requisiti è la spina dorsale di qualsiasi modello SDLC.

Un problema perso durante l'analisi dei requisiti e rilevato 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 richiamo (nel 2017, il produttore di airbag addebitato dagli Stati Uniti, Takata a multa di $ 1 miliardo a causa dell'esplosione degli airbag).

L'organizzazione finirebbe per eseguire attività di controllo dei danni come l'analisi della causa principale, la preparazione di documenti 5 perché, l'analisi dell'albero dei guasti, il documento 8D, ecc. Invece di concentrarsi sullo sviluppo e sulla qualità del software.

Nel peggiore dei casi, l'organizzazione verrebbe trascinata in azioni legali intentate dal cliente se la funzionalità interessata è correlata alla sicurezza come accesso di sicurezza, airbag, ABS (sistema di frenatura Anti-Lock), ecc.

Lettura consigliata

• Fasi, metodologie, processi e modelli di SDLC (Software Development Life Cycle)
• Caratteristiche dei requisiti funzionali e dei requisiti non funzionali
• Come testare la specifica dei requisiti software (SRS)?
• 5 errori mortali nella gestione dei requisiti e come superarli
• Come testare un'applicazione senza requisiti?
• Misure per SSDLC (ciclo di vita dello sviluppo software sicuro)
• Modello a spirale: che cos'è il modello a spirale SDLC?
• Cos'è il modello a cascata SDLC?