Requisiti software

I requisiti software sono la descrizione delle caratteristiche e delle funzionalità del sistema di destinazione. I requisiti trasmettono le aspettative degli utenti dal prodotto software. I requisiti possono essere evidenti o nascosti, noti o sconosciuti, previsti o inattesi dal punto di vista del cliente.

Ingegneria dei requisiti

Il processo per raccogliere i requisiti software dal cliente, analizzarli e documentarli è noto come ingegneria dei requisiti.

L'obiettivo dell'ingegneria dei requisiti è quello di sviluppare e mantenere un documento "Specifiche dei requisiti di sistema" sofisticato e descrittivo.

Processo di ingegneria dei requisiti

È un processo in quattro fasi, che include:

  • Studio di fattibilità
  • Raccolta dei requisiti
  • Specifiche dei requisiti software
  • Convalida dei requisiti software

Vediamo brevemente il processo:

Studio di fattibilità

Quando il cliente si rivolge all'organizzazione per ottenere lo sviluppo del prodotto desiderato, gli viene in mente un'idea approssimativa di quali funzioni devono eseguire il software e quali sono le caratteristiche previste dal software.

Facendo riferimento a queste informazioni, gli analisti effettuano uno studio dettagliato sulla possibilità di sviluppare il sistema desiderato e la sua funzionalità.

Questo studio di fattibilità è focalizzato verso l'obiettivo dell'organizzazione. Questo studio analizza se il prodotto software può essere materializzato praticamente in termini di implementazione, contributo del progetto all'organizzazione, vincoli di costo e secondo i valori e gli obiettivi dell'organizzazione. Esplora gli aspetti tecnici del progetto e del prodotto come usabilità, manutenibilità, produttività e capacità di integrazione.

Il risultato di questa fase dovrebbe essere un rapporto di studio di fattibilità che dovrebbe contenere commenti e raccomandazioni adeguati per la direzione sull'opportunità o meno di intraprendere il progetto.

Raccolta dei requisiti

Se il rapporto di fattibilità è positivo per intraprendere il progetto, la fase successiva inizia con la raccolta dei requisiti da parte dell'utente. Analisti e ingegneri comunicano con il cliente e gli utenti finali per conoscere le loro idee su ciò che il software dovrebbe fornire e quali funzionalità desiderano che il software includa.

Specifiche dei requisiti software

SRS è un documento creato dall'analista di sistema dopo che i requisiti sono stati raccolti da varie parti interessate.

SRS definisce il modo in cui il software previsto interagirà con l'hardware, le interfacce esterne, la velocità di funzionamento, il tempo di risposta del sistema, la portabilità del software su varie piattaforme, la manutenibilità, la velocità di ripristino dopo l'arresto anomalo, la sicurezza, la qualità, i limiti ecc.

I requisiti ricevuti dal cliente sono scritti in linguaggio naturale. È responsabilità dell'analista di sistema documentare i requisiti in linguaggio tecnico in modo che possano essere compresi e utili dal team di sviluppo software.

SRS dovrebbe fornire le seguenti funzionalità:

  • I requisiti dell'utente sono espressi in linguaggio naturale.
  • I requisiti tecnici sono espressi in un linguaggio strutturato, utilizzato all'interno dell'organizzazione.
  • La descrizione del progetto dovrebbe essere scritta in pseudo codice.
  • Formato dei moduli e delle schermate della GUI.
  • Notazioni condizionali e matematiche per DFD ecc.

Convalida dei requisiti software

Dopo che le specifiche dei requisiti sono state sviluppate, i requisiti menzionati in questo documento vengono convalidati. L'utente potrebbe richiedere una soluzione illegale e poco pratica o gli esperti potrebbero interpretare i requisiti in modo errato. Ciò si traduce in un enorme aumento dei costi se non viene stroncato sul nascere. I requisiti possono essere verificati rispetto alle seguenti condizioni:

  • Se possono essere praticamente implementati
  • Se sono validi e secondo funzionalità e dominio del software
  • Se ci sono ambiguità
  • Se sono completi
  • Se possono essere dimostrati

Processo di Elicitazione dei Requisiti

Il processo di elicitazione dei requisiti può essere rappresentato utilizzando il seguente diagramma:

  • Requirements gathering - Gli sviluppatori discutono con il cliente e gli utenti finali e conoscono le loro aspettative dal software.
  • Organizing Requirements - Gli sviluppatori danno la priorità e organizzano i requisiti in ordine di importanza, urgenza e convenienza.

  • Negotiation & discussion - Se i requisiti sono ambigui o ci sono dei conflitti nei requisiti dei vari stakeholder, se lo sono, viene negoziato e discusso con gli stakeholder. I requisiti possono quindi essere prioritari e ragionevolmente compromessi.

    I requisiti provengono da diversi stakeholder. Per rimuovere ambiguità e conflitti, vengono discussi per chiarezza e correttezza. Requisiti irrealistici sono ragionevolmente compromessi.

  • Documentation - Tutti i requisiti formali e informali, funzionali e non funzionali sono documentati e resi disponibili per l'elaborazione della fase successiva.

Tecniche di sollecitazione dei requisiti

Requirements Elicitation è il processo per scoprire i requisiti per un sistema software previsto comunicando con il cliente, gli utenti finali, gli utenti del sistema e altri che hanno un interesse nello sviluppo del sistema software.

Esistono vari modi per scoprire i requisiti

Interviste

Le interviste sono un mezzo forte per raccogliere i requisiti. L'organizzazione può condurre diversi tipi di interviste come:

  • Interviste strutturate (chiuse), dove ogni singola informazione da raccogliere viene decisa in anticipo, seguono con fermezza gli schemi e gli argomenti di discussione.
  • Interviste non strutturate (aperte), in cui le informazioni da raccogliere non sono decise in anticipo, più flessibili e meno distorte.
  • Colloqui orali
  • Interviste scritte
  • Colloqui individuali che si svolgono tra due persone sul tavolo.
  • Colloqui di gruppo che si svolgono tra gruppi di partecipanti. Aiutano a scoprire qualsiasi requisito mancante poiché sono coinvolte numerose persone.

Sondaggi

L'organizzazione può condurre sondaggi tra le varie parti interessate interrogando le loro aspettative e requisiti dal sistema imminente.

Questionari

Un documento con una serie predefinita di domande oggettive e le rispettive opzioni viene consegnato a tutte le parti interessate per rispondere, che vengono raccolte e compilate.

Un difetto di questa tecnica è che, se un'opzione per qualche problema non è menzionata nel questionario, il problema potrebbe essere lasciato incustodito.

Analisi dei compiti

Un team di ingegneri e sviluppatori può analizzare l'operazione per la quale è richiesto il nuovo sistema. Se il cliente ha già un software per eseguire determinate operazioni, viene studiato e vengono raccolti i requisiti del sistema proposto.

Analisi del dominio

Ogni software rientra in una categoria di dominio. Le persone esperte nel dominio possono essere di grande aiuto per analizzare requisiti generali e specifici.

Brainstorming

Si tiene un dibattito informale tra i vari stakeholder e tutti i loro input vengono registrati per un'ulteriore analisi dei requisiti.

Prototipazione

La prototipazione sta costruendo un'interfaccia utente senza aggiungere funzionalità di dettaglio per consentire all'utente di interpretare le caratteristiche del prodotto software previsto. Aiuta a dare un'idea migliore dei requisiti. Se non è installato alcun software presso il cliente per riferimento dello sviluppatore e il cliente non è a conoscenza dei propri requisiti, lo sviluppatore crea un prototipo basato sui requisiti inizialmente menzionati. Il prototipo viene mostrato al cliente e il feedback viene annotato. Il feedback del cliente serve come input per la raccolta dei requisiti.

Osservazione

Un team di esperti visita l'organizzazione o il luogo di lavoro del cliente. Osservano l'effettivo funzionamento degli impianti esistenti installati. Osservano il flusso di lavoro alla fine del cliente e come vengono affrontati i problemi di esecuzione. Il team stesso trae alcune conclusioni che aiutano a formare i requisiti attesi dal software.

Caratteristiche dei requisiti software

La raccolta dei requisiti software è la base dell'intero progetto di sviluppo software. Quindi devono essere chiari, corretti e ben definiti.

Una specifica completa dei requisiti software deve essere:

  • Clear
  • Correct
  • Consistent
  • Coherent
  • Comprehensible
  • Modifiable
  • Verifiable
  • Prioritized
  • Unambiguous
  • Traceable
  • Fonte credibile

Requisiti software

Dovremmo cercare di capire che tipo di requisiti possono sorgere nella fase di elaborazione dei requisiti e quali tipi di requisiti ci si aspetta dal sistema software.

In generale, i requisiti software dovrebbero essere classificati in due categorie:

Richieste funzionali

I requisiti relativi all'aspetto funzionale del software rientrano in questa categoria.

Definiscono funzioni e funzionalità all'interno e dal sistema software.

Esempi -

  • Opzione di ricerca data all'utente per cercare da varie fatture.
  • L'utente dovrebbe essere in grado di inviare qualsiasi rapporto alla direzione.
  • Gli utenti possono essere divisi in gruppi e ai gruppi possono essere assegnati diritti separati.
  • Dovrebbe rispettare le regole aziendali e le funzioni amministrative.
  • Il software viene sviluppato mantenendo intatta la compatibilità con le versioni precedenti.

Requisiti non funzionali

I requisiti, che non sono correlati all'aspetto funzionale del software, rientrano in questa categoria. Sono caratteristiche implicite o previste del software, che gli utenti presumono.

I requisiti non funzionali includono:

  • Security
  • Logging
  • Storage
  • Configuration
  • Performance
  • Cost
  • Interoperability
  • Flexibility
  • Ripristino di emergenza
  • Accessibility

I requisiti sono classificati logicamente come

  • Must Have : Non si può dire che il software sia operativo senza di loro.
  • Should have : Miglioramento della funzionalità del software.
  • Could have : Il software può ancora funzionare correttamente con questi requisiti.
  • Wish list : Questi requisiti non sono associati ad alcun obiettivo del software.

Durante lo sviluppo del software, "Must have" deve essere implementato, "Should have" è oggetto di dibattito con le parti interessate e negazione, mentre "could have" e "wish list" possono essere conservati per gli aggiornamenti software.

Requisiti dell'interfaccia utente

L'interfaccia utente è una parte importante di qualsiasi software, hardware o sistema ibrido. Un software è ampiamente accettato se è:

  • facile da usare
  • veloce in risposta
  • gestire efficacemente gli errori operativi
  • fornendo un'interfaccia utente semplice ma coerente

L'accettazione da parte dell'utente dipende principalmente da come l'utente può utilizzare il software. L'interfaccia utente è l'unico modo per gli utenti di percepire il sistema. Un sistema software ben funzionante deve anche essere dotato di un'interfaccia utente attraente, chiara, coerente e reattiva. In caso contrario, le funzionalità del sistema software non possono essere utilizzate in modo conveniente. Si dice che un sistema sia buono se fornisce i mezzi per usarlo in modo efficiente. I requisiti dell'interfaccia utente sono brevemente menzionati di seguito:

  • Presentazione dei contenuti
  • Navigazione facile
  • Interfaccia semplice
  • Responsive
  • Elementi dell'interfaccia utente coerenti
  • Meccanismo di feedback
  • Impostazioni predefinite
  • Layout mirato
  • Uso strategico del colore e della consistenza.
  • Fornisci informazioni di aiuto
  • Approccio incentrato sull'utente
  • Impostazioni di visualizzazione basate sul gruppo.

Analista di sistema software

L'analista di sistema in un'organizzazione IT è una persona che analizza i requisiti del sistema proposto e garantisce che i requisiti siano concepiti e documentati adeguatamente e correttamente. Il ruolo di un analista inizia durante la fase di analisi del software di SDLC. È responsabilità dell'analista assicurarsi che il software sviluppato soddisfi i requisiti del cliente.

Gli analisti di sistema hanno le seguenti responsabilità:

  • Analisi e comprensione dei requisiti del software previsto
  • Capire come il progetto contribuirà agli obiettivi dell'organizzazione
  • Identifica le fonti del fabbisogno
  • Convalida del requisito
  • Sviluppare e implementare un piano di gestione dei requisiti
  • Documentazione dei requisiti aziendali, tecnici, di processo e di prodotto
  • Coordinamento con i clienti per dare priorità ai requisiti e rimuovere e ambiguità
  • Finalizzare i criteri di accettazione con il cliente e altri stakeholder

Metriche e misure del software

Le misure software possono essere intese come un processo di quantificazione e simbolizzazione di vari attributi e aspetti del software.

Le metriche software forniscono misure per vari aspetti del processo software e del prodotto software.

Le misure del software sono un requisito fondamentale dell'ingegneria del software. Non solo aiutano a controllare il processo di sviluppo del software, ma aiutano anche a mantenere eccellente la qualità del prodotto finale.

Secondo Tom DeMarco, un (ingegnere del software), "Non puoi controllare ciò che non puoi misurare". Dal suo detto, è molto chiaro quanto siano importanti le misure del software.

Vediamo alcune metriche del software:

  • Size Metrics - LOC (righe di codice), per lo più calcolate in migliaia di righe di codice sorgente fornite, indicate come KLOC.

    Function Point Count è la misura della funzionalità fornita dal software. Il conteggio dei punti funzione definisce la dimensione dell'aspetto funzionale del software.

  • Complexity Metrics - La complessità ciclomatica di McCabe quantifica il limite superiore del numero di percorsi indipendenti in un programma, che viene percepito come complessità del programma o dei suoi moduli. È rappresentato in termini di concetti di teoria dei grafi utilizzando il grafico del flusso di controllo.

  • Quality Metrics - I difetti, i loro tipi e cause, le conseguenze, l'intensità della gravità e le loro implicazioni definiscono la qualità del prodotto.

    Il numero di difetti riscontrati nel processo di sviluppo e il numero di difetti segnalati dal cliente dopo che il prodotto è stato installato o consegnato presso il cliente definiscono la qualità del prodotto.

  • Process Metrics - In varie fasi dell'SDLC, i metodi e gli strumenti utilizzati, gli standard aziendali e le prestazioni di sviluppo sono metriche di processo del software.
  • Resource Metrics - L'impegno, il tempo e le varie risorse utilizzate rappresentano le metriche per la misurazione delle risorse.