Che cos’è e a cosa serve l’Ingegneria dei Requisiti (Requirements Engineering)?

Che cos’è e a cosa serve l’Ingegneria dei Requisiti (Requirements Engineering)?

Nel corso degli ultimi decenni il software ha vissuto una rapida evoluzione, fornendo tecnologie sempre più intelligenti e, di conseguenza, prodotti sempre più complessi.
Le esperienze pregresse relative a tali sistemi hanno mostrato che lo sviluppo informale del software non sia l’approccio più idoneo: si pensi, infatti, ai progetti di grandi dimensioni ed alle difficoltà ad essi correlate di presentare il lavoro in tempo congruo, di non sforare il budget iniziale, alle caratteristiche di performance ed affidabilità richiesti, nonché alla loro manutenzione.
Per poter ottenere un buon prodotto software è indispensabile gestire il relativo progetto in maniera adeguata.
A tal riguardo, è necessario introdurre un’importante figura, quella del Gestore del Progetto (Project Manager), il cui compito è attuare, durante il processo di sviluppo del prodotto, la pianificazione, il monitoraggio ed il controllo di persone, processi ed eventi.
Indubbiamente, il primo passo da compiere in tal senso è quello della raccolta delle informazioni concernenti le funzionalità che il committente richiede al prodotto che si intende sviluppare, cioè dei requisiti.

Che cos'è e a cosa serve l'Ingegneria dei Requisiti (Requirements Engineering)?
Che cos’è e a cosa serve l’Ingegneria dei Requisiti (Requirements Engineering)?

 

L’ingegneria dei Requisiti

L’ingegneria dei Requisiti rappresenta una delle attività più critiche del processo software, poichè racchiude in sé il processo di comprensione e definizione dei servizi richiesti al sistema in esame e l’individuazione dei vincoli operativi e di sviluppo del prodotto. Naturalmente, un errore commesso in questa fase si riverbera nelle fasi susseguenti di progettazione ed implementazione del sistema: da ciò se ne evince la criticità.
L’approccio adeguato per comprendere l’utilizzo di un artefatto consiste nell’individuare gli obiettivi che esso ci consentirà di raggiungere, affinchè il sistema risulti adeguato alle aspettative del cliente.
Molto spesso, però, le tecniche di Requirements Engineering sono adoperate solo nella fase finale di analisi per ottemperare all’esigenza di completezza, consistenza ed, eventualmente, per garantire una verifica automatica dei requisiti stessi, ignorandone gli obiettivi iniziali.
La letteratura riporta una molteplicità di metodi e tecniche volti alla raccolta ed alla strutturazione dei requisiti e la scelta dell’approccio da adottare dipende dal particolare contesto nel quale si opera.
In generale, l’Ingegneria dei Requisiti ha come obiettivo quello di sviluppare tecniche e modelli che siano di aiuto all’analista per capire in profondità il contesto organizzativo nel quale è inserito il sistema software ed a sviluppare soluzioni che siano quanto più possibile aderenti alle esigenze riscontrate.
Pertanto, nell’ottica di dover adoperare un approccio diverso a seconda del particolare contesto in esame, si rende ancor più indispensabile individuare gli obiettivi che il sistema deve raggiungere, capire le motivazioni, le funzioni che dovranno essere progettate ed implementate, nonchè i vincoli ai quali la realizzazione del sistema dovrà sottostare.
Tutto ciò è ancor più vero in un contesto nel quale i sistemi si trovano in stretta relazione con l’ambiente in cui operano, perchè pensati per applicazioni specifiche, come i sistemi embedded (cioè dedicati ad un’applicazione od una classe specifica di applicazioni) la cui presenza massiva sul mercato è fonte, principalmente, di innovazione.

L’ applicazione dei principi del Requirements Engineering richiede, a partire dal concetto di “obiettivo”, lo sviluppo di un’idea di “componente attivo” dotato di capacità di reazione che dipendano dal contesto in cui opera, nonchè quella di “componente strategico”, con caratteristiche di indipendenza rispetto all’ambiente in cui il prodotto viene immesso.
Questa considerazone renderà possibile, nell’ambito dell’Ingegneria dei Requisiti, separare gli aspetti troppo vincolati allo specifico progetto in esame da quelli più generici e, quindi, adattabili ai membri di una stessa famiglia di prodotti.

Pertanto, ad un sistema embedded potrebbe essere conferito il requisito mancante della versatilità e, di conseguenza, porre le basi per il riuso delle parti che godono di questa caratteristica.
Un approccio sistematico delle pratiche suggerite dall’Ingegneria del Software risulta di grande interesse in coloro i quali abbiano intenzione di migliorare i processi già acquisiti, così da renderli standard e minimizzare la differenza tra i processi aziendali adottati.
In effetti, la tendenza che va via via affermandosi è quella di abbandonare l’approccio legato alle azioni correttive sulle “non conformità” riscontrate, a favore di uno basato sulla prevenzione dei difetti sul prodotto finale, spostando l’attenzione dal prodotto al processo software.

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: https://vitolavecchia.altervista.org

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *