Le principali attività e il processo dell’ingegneria dei requisiti

Le principali attività e il processo dell’ingegneria dei requisiti

L’ingegneria dei requisiti è una sezione fondamentale del System Engineering e, come tale, è rappresentata da un vasto insieme di attività volte al trattamento sistematico dei requisiti.
Tale disciplina non rappresenta un processo a sé stante, bensì è parte integrante del processo di sviluppo; essa vede la sua esplicazione nella Gestione dei requisiti, che si espanderà a sua volta nelle attività di studio di fattibilità, elicitazione, analisi, specifica e validazione.

Prima di procedere ad una definizione più dettagliata delle attività coinvolte nell’ingegneria dei requisiti, si esprimerà breve considerazione sul modello mostrato nella figura seguente.

La spirale indica la ciclicità delle attività svolte, in cui le risorse impiegate (in termini di lavoro e tempo profusi) in ciascuna azione sono commisurati al particolare sistema su cui si sta lavorando ed allo stato di avanzamento del processo. Pertanto:

  • Nello stadio iniziale del processo, rappresentato dalla parte più interna della spirale, sarà impiegato uno sforzo maggiore per la deduzione dei requisiti di alto livello aziendali, non funzionali ed i requisiti utente.
  • Nello stadio finale del processo, rappresentato dalla parte più esterna della spirale, i maggiori sforzi saranno indirizzati alle azioni peculiari dell’ingegneria dei requisiti e, chiaramente alla modellazione del sistema.

Si noti che il modello mostrato risulta flessibile per diversi contesti e, in particolar modo, laddove i requisiti vengono definiti a mano a mano con un livello di dettaglio maggiore, ovvero attraverso livelli di astrazione differenti.

Le principali attività e il processo dell'ingegneria dei requisiti

A questo punto, è necesario descrivere brevemente ognuna di tali attività, al fine di meglio comprendere in cosa consista una adeguata gestione dei requisiti da parte dell’ingegneria dei requisiti.

Lo studio di fattibilità consiste nel valutare se le necessità del cliente possano essere soddisfatte con le risorse disponibili.

La Requirements Elicitation (elicitazione) consiste nella fase di comprensione e raccolta dei requisiti provenienti dagli stakeholder principali del sistema. In questa fase bisognerà tener conto delle esigenze mutevoli del customer, il quale, durante la vita del prodotto, potrebbe richiedere modifiche a requisiti precedentemente valutati oppure chiederne di nuovi.

Nella System Requirements Analysis si effettua una trasformazione dei requisiti richiesti dagli stakeholder in requisiti tecnici del sistema, i quali fungeranno da guida per il progetto del sistema stesso. Tale fase, dunque, consiste nello stabilire quali requisiti debbano essere soddisfatti, nell’assegnazione di una priorità ad essi, nonchè nella definizione di una strategia generale che ne consenta il soddisfacimento.

L’attività di Requirements Specification consiste nel documentare in maniera adeguata i requisiti derivanti dalle fasi precedenti, così da comunicarli agli stakeholder ed ai progettisti.

L’ultima fase consta delle attività di Verifica e Validazione: la prima riguarda la valutazione della qualità dei requisiti, la seconda consiste nell’accertarsi che i requisiti specificati rispecchino effettivamente i bisogni degli stakeholder.

Le attività svolte dall’ingegneria dei requisiti

Lo spettro delle attività svolte nell’ambito dell’ingegneria dei requisiti è molto ampio e ciò rende difficile fornire una definizione precisa di tale disciplina. Certamente, la definizione dei requisiti di un sistema parte dal concetto di “obiettivo”, mentre l’attività cardine è il modo in cui si passa dall’obiettivo alla specifica del corrispondente sistema software.

Quanto detto è suffragato da una seconda e più tecnica definizione della disciplina: “Requirements engineering is concerned with the identification of the goals to be achieved by the envisioned system, the operationalization of such goals into services and constraints, and the assignment of responsibilities for the resulting requirements to agents such as humans, devices and software”.
Questo sposta l’interesse sulla definizione ed analisi delle motivazione e degli obiettivi della specifica dei requisiti stessa; da qui la definizione di approccio “goal-oriented”.
Per adottare questo approccio vi saranno delle azioni prelimiari da compiere e che riguardano l’individuazione degli obiettivi che il sistema dovrà raggiungere. Naturalmente, la definizione formale dei goal prende vita solo dopo una serie di raffinamenti degli aspetti considerati in prima battuta e, darà luogo ad obiettivi di natura e priorità differenti.
Sulla scorta di quanto appena detto, gli obiettivi rappresentano sia il punto di partenza che di arrivo delle attività svolte, fungendo da meccanismo per l’individuazione, l’organizzazione dei requisiti e, chiaramente, un mezzo per giustificare la presenza degli specifici requisiti in un sistema software.
In linea con questo approccio:

  • La fase di acquisizione dei requisiti partirà dalla comprensione degli obiettivi che lo stakeholder richiederà per il sistema: ciascuno di essi dovrà essere motivato, così come dovranno essere definite e valutate le modalità alternative per raggiungerlo.
  • Una volta stabiliti i requisiti, essi dovranno essere messi in relazione al contesto organizzativo, cioè il sistema reale in cui essi dovranno essere calati per soddisfare le esigenze e vincoli (ovvero obiettivi ) di contesto.

Si noti che l’analisi basata sugli obiettivi apporta benefici anche in termini di chiarezza dei requisiti che potrebbero mancare di tale caratteristica.

  • La tracciabilità dei requisiti evidenzierà chi li ha definiti e le motivazioni, i collegamenti tra i requisiti in relazione tra loro;
  • La gestione dei conflitti consisterà nell’ individuare e gestire gli obiettivi che hanno dato luogo ai requisiti discordanti già nella fase iniziale del processo (e prima dell’attività di design).

A partire dagli obiettivi degli stakeholder, si potranno esplorare soluzioni alternative di design per il loro soddisfacimento: esse dovranno essere valutate in base all’importanza, ai costi ed all’efficacia.

  • Già prima che l’applicazione venga sviluppata sarà possibile valutarne la qualità della specifica, verificando che soddisfi gli obiettivi determinati nella fase di analisi.
  • Il cambiamento dei requisiti degli utenti e degli stakeholder può essere gestito definendo nuovi obiettivi o modificando quelli esistenti. Si noti che la gestione dei cambiamenti al livello degli obiettivi consente una più agevole gestione dei cambiamenti dei requisiti.
  • Definire gli obiettivi, la tracciabilità tra essi ed i requisiti e con il design offre una maggiore spinta verso il riuso. Infatti, lo sforzo iniziale profuso per la comprensione e la formalizzazione degli obiettivi di un prodotto, potrebbe essere capitalizzato, sfruttando gli aspetti comuni a prodotti simili. Naturalmente, ciò sarà possibile a patto che gli obiettivi siano adeguatamente formalizzati, scomposti in sotto-obiettivi e tradotti in requisiti.

Nonostante la gestione dei requisiti sia decisiva nelle fasi di vita iniziali di un progetto, essa rappresenta un processo che accompagna il progetto durante tutta la sua durata.

Del resto, mano a mano che ci si addentra nel ciclo di vita, anche i requisiti subiscono un’evoluzione, arricchendosi e specializzandosi fino, talvolta, ad indirizzarsi verso strade non valutate inizialmente. Essi potranno affiancarsi a nuovi requisiti, potranno essere modificati od eliminati.
Dunque, i requisiti rappresentano il fattore che maggiormente potrà incidere sulle risorse necessarie allo sviluppo del progetto, ed è per questo motivo che potremmo pensare al Requirements Management come ad un processo con carattere sia tecnico che gestionale.

Infatti, se è vero che la modifica dei requisiti comporti, tipicamente, una modifica degli aspetti tecnici legati al sistema, presumibilmente, affinchè il progetto venga portato a termine, dovrà essere rivista anche l’assegnazione delle risorse da stanziare.
Riguardo la redazione della documentazione dei requisiti, può rilevarsi utile l’utilizzo di tool software capaci di automatizzare le parti più ripetitive dell’attività, consentendo raggruppamenti, estrazioni ed analisi di tracciabilità dei requisiti e di impatto dei cambiamenti.

Questi ultimi aspetti, infatti, mostrando le interrelazioni tra requisiti, consentiranno inizialmente l’individuazione di eventuali inconsistenze e ridondanze, poi la loro risoluzione, così da evitarne l’influenza nella fase di realizzazione del prodotto.
In definitiva, un’adeguata gestione dei requisiti da parte dell’ingegneria dei requisiti è la base per abbattere la probabilità di rischio associati ad un progetto, favorendo il riuso e la qualità.

Le fasi del processo di ingegneria dei requisiti
Le fasi del processo di ingegneria dei requisiti
Precedente Cosa è il rischio in un progetto software? Successivo Definizione e ruolo della tracciabilità dei requisiti software

Lascia un commento

*