Fondamenti dell'Analisi dei Requisiti Software: Concetti Chiave e Metodologie

Introduzione all'Analisi dei Requisiti Software

Generalità

L'analisi è una tappa fondamentale nel ciclo di vita del software.

• L'analisi deriva dal sistema e dai requisiti.
• Per analizzare i requisiti, questi devono essere stati preventivamente ottenuti attraverso la determinazione dei requisiti (Requirements Engineering).

Definizione di Analisi

L'analisi è il processo di studio delle necessità dell'utente per arrivare a una definizione dei requisiti di sistema, hardware o software, e il processo di studio e perfezionamento di tali requisiti.

Ingegneria dei Requisiti

L'ingegneria dei requisiti è la prima fase del ciclo di vita del software in cui vi è una specifica.

• Dalle idee informali dovrebbero essere ottenuti e documentati:
• Requisiti funzionali
• Requisiti non funzionali, con i criteri per misurare il grado della loro realizzazione.

Il processo di sviluppo della specifica dei requisiti è chiamato Requirements Engineering, che ha una crescente importanza per:

• La corretta comprensione (appalti), documentazione (specifiche) e la convalida dei bisogni degli utenti e dei clienti.
• I sistemi di misurazione della qualità in base al grado di soddisfazione degli utenti.

Requisiti

Un requisito è una condizione o capacità necessaria all'utente per risolvere un problema o raggiungere un obiettivo. Il concetto è di apparente semplicità, ma il termine requisito è spesso qualificato con aggettivi che possono essere fonte di confusione.

Campo di Applicazione

Indica il contesto in cui si deve comprendere l'esigenza.

• Il campo di applicazione del sistema indica che il requisito deve essere raggiunto a livello di sistema, ovvero un insieme di hardware e software.
• Se il campo è un software, l'obbligo riguarda solo il software di sistema.
• Se è un livello di hardware, riguarda solo l'hardware.

Caratteristica Distintiva di un Requisito

La caratteristica distintiva è la quota per la quale i requisiti vengono classificati in base alla natura della proprietà specificata del sistema.

• La classificazione più comune è quella tra requisiti funzionali (quali funzioni dovrebbe rendere il sistema) e requisiti non funzionali (le altre caratteristiche del sistema).
• Questa classificazione a volte non è molto chiara perché in alcuni casi un requisito può essere classificato in diverse categorie contemporaneamente.

Pubblico

La quota indica a chi è rivolto il requisito, ovvero chi dovrebbe essere in grado di capirlo. In generale, ci sono due tipi di pubblico:

• Clienti e utenti che non devono essere formati in ingegneria del software.
• Sviluppatori di software.

In questa dimensione è spesso usata una nomenclatura in cui sono chiamati:

• Requisiti orientati al cliente (requisiti-C), dal punto di vista dei clienti e degli utenti.
• Requisiti orientati allo sviluppatore (requisiti-D), dal punto di vista degli sviluppatori.

Rappresentazione

La rappresentazione è la quota utilizzata per stabilire in che modo i requisiti sono definiti.

• Le categorie sono in genere formali, semiformale o formali.
• Le rappresentazioni formali hanno una semantica rigorosa e sintassi.
• Le rappresentazioni semi-formali sono modelli che facilitano la comprensione tra i partecipanti.
• Le rappresentazioni informali sono espressioni naturali nel testo, video, immagini, voce e suoni per limitare il sistema da costruire.

Obiettivo

L'obiettivo è costruire un'indicazione precisa dei requisiti software che descrivono ciò che il sistema dovrebbe fare, ma non indica in dettaglio come dovrebbe essere fatto.

• Requisiti Software Specification (ERS): questo documento deve includere sia le esigenze-requisiti-D che C.
• Tuttavia, ci sono metodologie che difendono la separazione di queste rappresentazioni in due diversi documenti:
• La DRS (Requisiti dei documenti sistema), conosciuto anche come catalogo di requisiti, stabilendo i requisiti-C.
• La stessa LRA, che identifica i requisiti-D.
• La realizzazione di un ERS coinvolge ingegneri del software (Analista), clienti e utenti.

Principi di Analisi

• È necessario rappresentare e comprendere la portata delle informazioni del problema.
• Si dovrebbero sviluppare modelli informativi che rappresentano la componente funzionale e il sistema di modelli.
• Le prestazioni devono essere suddivise in modo da scoprire i dettagli in modo gerarchico progressivo.
• Il processo di analisi deve passare dalle informazioni essenziali al dettaglio di implementazione.

Rappresentazione delle Informazioni

• Tre modi di rappresentazione delle informazioni:
• Flusso di informazioni
• Contenuto informativo
• Struttura informativa

Modello di Costruzione

• Obiettivo: combattere la complessità.
• Focus su ciò che rende il sistema.
• Rappresentazioni grafiche delle informazioni testuali per completare.
• Tipi:
• Logica
• Fisico

Perché Modellare?

• Nella vita reale, si costruiscono molti generi di modelli per vari scopi.
• Obiettivi della costruzione di modelli:
• Verifica di un'entità fisica prima di costruirla.
• Comunicazione con il cliente.
• Visualizzazione.
• Riduzione della complessità.
• Strutturare le proprie idee.