Due delle attività più importanti nell’ambito dell’ingegneria dei sistemi sono comprendere verosimilmente le esigenze degli stakeholder e tradurle in requisiti di sistema. Questo white paper tratta dell’applicazione precoce della modellazione per svolgere queste attività, dimostrando tecniche di modellazione sempre più sofisticate ed efficaci che vanno da modelli puramente descrittivi a prove formali. La qualità aumentata dei requisiti di sistema è sufficiente a giustificare l’investimento in queste tecniche, ma i modelli che ne derivano possono anche essere utilizzati nelle fasi avanzate del progetto per rappresentare le esigenze degli stakeholder in modo più efficace. Mostreremo come riutilizzare i modelli di requisiti per ottenere requisiti di sistema completi e coerenti. La Figura 1 mostra la procedura adottata in questo articolo per ottenere tali benefici.
Figura 1. Processo di affinamento delle esigenze degli stakeholder in requisiti di sistema per giungere a requisiti dettagliati.
Per questo case study, verranno derivati i requisiti per un sistema di raffreddamento macchine sulla base delle esigenze degli stakeholder descritte di seguito:
Fornire un sistema in grado di mantenere una determinata temperatura di esercizio di una macchina, evitando di danneggiare la macchina per via del surriscaldamento.
- [vincolo] Il sistema di raffreddamento deve mantenere la temperatura di esercizio al di sotto di 40 ˚C.
- [vincolo] Il raffreddamento deve essere efficace entro un tempo predeterminato.
- [ipotesi] La temperatura ambiente è maggiore di -10 ˚C e minore di 80 ˚C.
Le esigenze di questi stakeholder sono ambigue e potrebbero essere facilmente fraintese, il che potrebbe portare a requisiti di sistema incompleti e/o scorretti, fino all’ottenimento di un progetto incapace di soddisfare le aspettative degli stakeholder. Per evitare tutto questo è essenziale accertarsi di aver compreso le esigenze degli stakeholder.
Esistono delle tecniche di modellazione che possono aiutare ad accertarsi di aver compreso appieno le richieste degli stakeholder e a individuare un set di requisiti di sistema ideale per tutti. Questi metodi includono l’uso di:
Nelle prossime sezioni descriveremo ciascuno di questi metodi, per poi terminare con un dibattito sull’uso dei thread digitali per stabilire la tracciabilità tra le esigenze degli stakeholder e i vari livelli di requisiti derivati.
La prima fase di esplorazione delle esigenze degli stakeholder consiste nel descrivere le varie situazioni a cui il sistema di raffreddamento deve saper far fronte. Ad esempio, cosa deve succedere se la temperatura è troppo alta o nei casi in cui il raffreddamento sembra non essere efficace?
I modelli di requisiti descrittivi sono un passo avanti rispetto ai requisiti tradizionali basati sul linguaggio naturale in quanto forniscono una rappresentazione grafica e strutturata del requisito, il che migliora la collaborazione tra i team coinvolti. Un buon esempio di una rappresentazione di questo tipo potrebbe essere un diagramma di sequenza.
Che cosa sono i modelli descrittivi?
Un modello descrittivo è una specifica grafica di un sistema che descrive cos’è o cosa fa il sistema in un modo leggibile dall’uomo.
La Figura 2 descrive il seguente scenario: se la temperatura (T) è troppo alta (T>=40), il raffreddamento è necessario; se il raffreddamento è efficace (T<40), il raffreddamento dovrebbe essere disattivato; ma se il raffreddamento non è efficace (ritardo>=30), la macchina deve essere spenta.
Figura 2. Diagramma di sequenza che descrive il nostro scenario.
I diagrammi di sequenza mettono a disposizione delle descrizioni grafiche delle modalità di interazione tra i componenti modellati del sistema di raffreddamento in scenari diversi. Tuttavia, questi modelli di requisiti descrittivi rientrano ancora fermamente nel dominio ingegneristico, mentre i modelli di requisiti simulabili (o eseguibili) possono portare a osservazioni e approfondimenti nel dominio dei sistemi, consentendo agli stakeholder di avere una comprensione diretta dei requisiti nel contesto specifico al loro dominio. Un buon esempio di formalismo eseguibile in grado di produrre questi risultati è un diagramma di stato (cfr. Figura 3).
Che cosa sono i modelli di simulazione?
Un modello di simulazione è una specifica di un sistema per l’interpretazione tramite macchina, dove gli esiti dell’interpretazione vengono sottoposti all’interpretazione dell’uomo affinché ne tragga delle conclusioni.
Figura 3. Componente di architettura simulabile (macchina a stati) e relativi output.
Ciò è importante perché la simulazione fornisce un’interpretazione non ambigua di ogni scenario descritto nei diagrammi di sequenza precedenti. Inoltre fornisce un mezzo per comunicare questa interpretazione agli stakeholder, esplorare scenari diversi e comprendere quali sono le loro esigenze specifiche, in modo tale da poter descrivere queste informazioni nei requisiti di sistema.
Ora che disponiamo di un modello in grado di simulare i comportamenti specificati nei diagrammi di sequenza, possiamo osservare e discutere con gli stakeholder dei risultati generati dalla macchina a stati. In più, possiamo confermare se il comportamento della macchina a stati è coerente con gli scenari descritti nel diagramma di sequenza. Nella Figura 4, i segni di spunta verdi nel diagramma di sequenza indicano che gli eventi giusti si sono verificati nell’ordine corretto durante la simulazione. Ciò conferma che il comportamento del modello funzionale è corretto. Questi risultati possono essere utilizzati anche per la convalida con lo stakeholder.
Figura 4. Convalida tramite simulazione.
Sebbene le tecniche di simulazione offrano una buona copertura dei comportamenti del sistema, in genere la simulazione è dedicata a scenari chiave a supporto del lavoro collaborativo. I modelli di requisiti formali, d’altra parte, contengono formalismi che consentono di eseguire una valutazione più sistematica della qualità del modello.
Uno di questi formalismi è la tabella dei requisiti, utilizzabile per provare formalmente la coerenza e la completezza di un set di requisiti. I requisiti coerenti non creano conflitti mentre quelli completi non hanno funzionalità mancanti. Le colonne delle precondizioni (A) nella Figura 5 descrivono gli input del sistema (valori di temperatura) e se un requisito è valido o “attivo”. Le colonne delle postcondizioni (B) descrivono il comportamento atteso quando il requisito specificato è attivo.
Che cosa sono i modelli formali?
Un modello formale è una specifica di un sistema per l’interpretazione tramite macchina, dove gli esiti dell’interpretazione vengono ulteriormente elaborati per presentare conclusioni definitive di cui si possa servire l’uomo.
Figura 5. Modello formale per descrivere i requisiti.
Ad esempio, il requisito n. 1 afferma che quando T è inferiore a 40 ˚C (T<40), il sistema di raffreddamento dovrebbe essere disattivato (Turn_off_cooling == true).
Un’analisi che usa le funzionalità dei metodi formali di Simulink Design Verifier™ ora può determinare se i requisiti sono coerenti e completi. Nella Figura 6, non è stato incluso lo scenario in cui la temperatura è pari a 40 ˚C, pertanto questo set di requisiti non è completo.
Figura 6. L’analisi formale ha individuato un problema di incompletezza (T=40 manca).
Test di modelli di progettazione
I modelli di requisiti formali offrono un buon punto di partenza per i team a valle, sia perché la qualità dei requisiti è maggiore sia perché gli elementi del modello di requisiti possono essere riutilizzati in fase di progettazione, generazione di test automatici e verifica. I modelli di requisiti possono essere utilizzati nell’ambito di test unitari a garanzia del fatto che i modelli funzionali vengano sviluppati per soddisfare i requisiti. Tali test unitari possono essere eseguiti in modalità interattiva ma anche all’interno di un framework CI/CD. La Figura 7 mostra che i requisiti 1 e 2.2 superano il test e che gli altri requisiti non sono stati testati.
Figura 7. Uso dei requisiti formali come test per convalidare i modelli di progettazione.
Thread digitale e non solo
Molti artefatti vengono creati e/o generati lungo le varie fasi del ciclo di sviluppo prodotti. Questi artefatti digitali includono requisiti, architettura, modelli di progettazione, file di codice e file di verifica e convalida. È essenziale stabilire un collegamento tracciabile tra questi artefatti per capire l’impatto dei requisiti su altri requisiti, modelli o sulle attività di verifica e convalida. Questo collegamento funge da thread digitale.
Ad esempio, i diagrammi di tracciabilità dei requisiti possono essere generati in automatico a partire dai modelli di requisiti e architetture, per contribuire a fornire informazioni sulle modalità con cui tali requisiti, modelli e artefatti di verifica sono graficamente collegati tra loro.
La Figura 8 mostra il thread digitale in cui l’esigenza di uno stakeholder è soddisfatta da un altro stakeholder. In realtà, vari stakeholder saranno distribuiti nell’organizzazione, a coprire aree funzionali diverse a vari livelli di astrazione. È proprio qui che il thread digitale diventa indispensabile. Per di più, un thread digitale facilita l’uso di infrastrutture e processi automatizzati, agili e iterativi (DevOps). Ad esempio, la Figura 8 mostra in che modo lo stato di verifica di un test viene automaticamente ritrasmesso all’ingegnere responsabile.
Figura 8. Diagramma di tracciabilità che mostra il thread digitale per il sistema di raffreddamento.
Man mano che le organizzazioni intraprendono il loro percorso di trasformazione digitale, i concetti di thread digitale, gemello digitale e DevOps acquisiscono ruoli complementari nello stabilire le fondamenta dell’ingegneria digitale. Tali concetti agiscono di concerto per creare un’infrastruttura che supporti la transizione dalle pratiche ingegneristiche tradizionali a quelle orientate al digitale.
In questo articolo, abbiamo descritto un processo in cui, sulla base delle esigenze degli stakeholder, abbiamo individuato i requisiti di sistema (simulabili/eseguibili) migliori per tutti usando la simulazione e metodi formali. Per farlo, abbiamo fatto uso di modelli di requisiti in grado di simulare (macchine a stati), valutare (diagrammi di sequenza) ed essere analizzati da un punto di vista formale (tabella dei requisiti).
L’impiego dei modelli di requisiti ha permesso di automatizzare le attività di verifica e convalida per poi ottenere dei requisiti di sistema completi, coerenti e convalidati. In più, migliora la collaborazione tra i vari team, in quanto tali modelli offrono più informazioni rispetto ai requisiti puramente descrittivi o basati su testo.
Di Alan Moore, Becky Petteys e Stephan van Beek
