Non dimenticare di decidere 'in quanti secondi è abbastanza veloce' — Organizzare i requisiti non funzionali con il Non-Functional Requirements Grade dell'IPA

“Ci hanno detto che le transizioni di schermata sono troppo lente, ma né il contratto né il documento di specifica hanno alcun accordo sul tempo di risposta.”

“Il batch notturno non ha più finito entro mattina, ma nessuno aveva mai stimato quanto sarebbe cresciuto il volume di dati nel corso degli anni.”

“Solo dopo che un guasto al server ha fermato il sistema per mezza giornata ci siamo resi conto che, al momento dell’ordine, nessuno aveva confermato entro quante ore la configurazione fosse effettivamente in grado di ripristinarsi.”

Quando si pensa ai problemi nello sviluppo di sistemi, viene in mente una mancata corrispondenza funzionale, ma le dispute che esplodono una volta avviata l’operatività derivano spesso dal dimenticare di decidere questi requisiti non funzionali — i requisiti che non riguardano affatto la funzione.

Lo strumento pubblico creato per prevenire esattamente questo tipo di svista è il Non-Functional Requirements Grade dell’IPA (Information-technology Promotion Agency, istituzione amministrativa indipendente). Questo articolo spiega cosa contiene effettivamente e un modo realistico di usarlo per il sistema informativo di una PMI, con un linguaggio comprensibile anche per il committente.

1. La conclusione prima di tutto

• I requisiti non funzionali non riguardano “cosa fa il sistema” — riguardano “quanto bene e in quali condizioni opera”. Possono essere organizzati in sei aree: disponibilità, prestazioni, operazioni, migrazione, sicurezza e ambiente di installazione.
• Il Non-Functional Requirements Grade è un set di strumenti IPA (gratuito) che elenca in modo esaustivo gli item di requisito nelle sei aree e permette a committenti e sviluppatori di allinearsi a livelli per fasi.
• Non è necessario compilare ogni item. L’uso previsto è scegliere il “model system” più vicino al proprio, poi regolare prima gli item importanti in base alle circostanze reali.
• Più alto si imposta un livello non funzionale, più costa. Invece di “esigere vagamente un alto standard,” scegli il livello ragionando all’indietro dall’impatto sul business.
• Conserva le decisioni nel documento di definizione dei requisiti. Le assunzioni fissate lì permettono di confrontare i preventivi in modo equo ed evitano dispute “ha detto/ha detto” una volta in operatività.

2. Cosa sono i requisiti non funzionali — Ciò che sta tra “funziona” e “è utilizzabile”

I requisiti funzionali sono cose come “può registrare un ordine” o “può stampare un report” — requisiti su cosa fa il sistema. Le riunioni di sviluppo tendono naturalmente a gravitare su questo tipo di discussione.

Domande come le seguenti, invece, non compaiono mai in un elenco di funzioni.

• In quali orari il sistema deve essere attivo? E nei weekend? Durante il batch notturno?
• Se va giù, entro quante ore deve ripristinarsi prima che il business smetta di funzionare? Fino a quanto tempo fa possono accettabilmente risalire i dati ripristinati?
• Quante persone lo usano contemporaneamente, e quante transazioni elabora al giorno? Quanto sarà cresciuto il volume di dati tra cinque anni?
• Chi lo monitora, chi esegue i backup e chi riceve la prima segnalazione di un guasto?
• Quanti dati del sistema precedente vengono portati nel nuovo?

Questi sono i requisiti non funzionali. Ciò che li rende insidiosi è che il sistema più o meno “funzionerà” anche se non si decide nulla di essi. Il problema emerge solo quando inizia l’operatività, il carico cresce e si verifica un guasto effettivo — e a quel punto, poiché tocca i fondamenti della configurazione e del design del server, sistemarlo costa molto.

3. Cosa è il Non-Functional Requirements Grade

Il Non-Functional Requirements Grade è un set di strumenti che l’IPA pubblica con l’obiettivo di impedire che committenti e sviluppatori parlino senza intendersi sui requisiti non funzionali. La prima versione è uscita nell’aprile 2010, e l’ultima versione attuale, che riflette i cambiamenti attorno a sicurezza e virtualizzazione (cloud), è “Non-Functional Requirements Grade 2018,” pubblicata nell’aprile 2018. Ora si trova in una pagina archiviata del sito IPA, ma è ancora lo standard di riferimento usato in pratica per verificare che nessun requisito non funzionale sia caduto nel vuoto.

È composto dal seguente set di strumenti.

Ogni metrica ha un insieme definito di livelli per fasi tra cui scegliere, il che significa che un requisito può essere espresso come scelta di livello piuttosto che con una parola vaga come “alto” o “basso”.

I tre model systems

Un’altra caratteristica sono i tre model systems, divisi per quanto grande sia l’impatto sociale che un downtime del sistema causerebbe.

• Sistemi con impatto sociale quasi nullo
• Sistemi con impatto sociale limitato (come i sistemi core business di un’azienda)
• Sistemi con impatto sociale estremamente grande (come infrastrutture sociali)

La grade table ha già un livello di baseline compilato per ogni model. In altre parole, invece di iniziare la discussione da zero, si può prima identificare “ci avviciniamo a questo model,” e poi regolare i livelli su o giù per adattarsi alle proprie circostanze.

4. Le sei categorie principali — Tradotte nel linguaggio del committente

Riformulate come domande a cui un committente può effettivamente rispondere, le sei categorie principali del Non-Functional Requirements Grade appaiono così.

Viste così, è chiaro che la maggior parte delle sei categorie principali sono domande di business, non tecniche. Chi può rispondere a “cosa succede se il batch di fatturazione di fine mese viene ritardato di mezza giornata” è il committente, non la società di sviluppo. L’iniziativa sui requisiti non funzionali appartiene in realtà al committente.

5. Un modo realistico di usarlo — Non cercare di compilare tutti i 238 item

L’item list ha 238 metriche, ma discuterne ognuna non è realistico per un progetto di PMI, e nemmeno la guida all’uso presuppone di usarla così. Il flusso previsto è questo.

1. Scegli un model system
   (a quale livello di impatto è più vicino il tuo sistema?)
        ↓
2. Per gli item importanti nella grade table,
   regola dal livello di baseline del model in base alle tue circostanze
        ↓
3. Approfondisci l'item list solo per le parti che lo necessitano

Per un’applicazione business di una PMI, anche solo lo Step 2 — concordare gli item importanti — offre già molto valore. Dalla mia esperienza, consiglio di documentare almeno i seguenti punti durante la definizione dei requisiti.

• Orari di operatività e impatto sul business se il sistema va giù (disponibilità)
• Intervallo di backup e, in caso di guasto, “dati ripristinati fino a che punto nel tempo” e “entro quante ore” (disponibilità / operazioni)
• Volume di dati/numero di record attuale e proiezione tra qualche anno (prestazioni / scalabilità)
• Valori target per tempi di risposta ed elaborazione batch. Anche “almeno veloce come il sistema attuale” va bene, purché venga fissata una baseline (prestazioni)
• Chi è responsabile del monitoraggio, dei backup e della prima risposta a un guasto (operazioni / manutenibilità)

La cosa da non dimenticare qui è il trade-off tra livello e costo. Mirare a “un sistema che non va mai assolutamente giù” fa schizzare i costi a causa della ridondanza dei server e dell’infrastruttura di monitoraggio. Se invece si può giudicare che “purché il business possa aspettare fino al giorno dopo, ripristinare entro fine giornata basta,” si possono indirizzare quei fondi altrove. Il modo corretto di usare i livelli del Non-Functional Requirements Grade non è come strumento per esigere di più, ma come linguaggio condiviso per discutere il bilanciamento tra impatto sul business e costo.

6. Il rapporto con contratti e preventivi

I requisiti non funzionali si collegano direttamente anche al contratto.

Primo, il confronto dei preventivi. Se si richiedono preventivi a più aziende senza essersi allineati sulle assunzioni non funzionali, la Società A potrebbe prezzare una configurazione ridondante mentre la Società B prezza un singolo server. Il committente perde la capacità di capire se una differenza di prezzo riflette una differenza di configurazione o solo una stima troppo ottimistica.

Poi arrivano i test di accettazione e la vita dopo l’avvio. Con tempi di risposta e disposizioni di backup scritti, un battibecco “è lento” contro “non ce lo aspettavamo” diventa semplicemente una verifica dei fatti rispetto a uno standard concordato.

Anche il Model Transaction and Contract per sistemi informativi dell’IPA presuppone che i requisiti non funzionali siano documentati come deliverable della fase di definizione dei requisiti. Il Non-Functional Requirements Grade si inserisce naturalmente in un flusso contrattuale a più fasi in cui la definizione dei requisiti avviene in contratto di quasi-mandato e, una volta stabilito il contenuto, lo sviluppo procede in contratto d’opera. Per approfondire questa struttura contrattuale, vedi il nostro articolo sul Model Contract IPA.

Riassunto

Ecco un riepilogo dei punti chiave sul Non-Functional Requirements Grade dell’IPA.

• I requisiti non funzionali riguardano quanto bene e in quali condizioni opera un sistema. Funziona anche senza deciderli, ma le lacune emergono come dispute una volta in operatività
• Il Non-Functional Requirements Grade è il set gratuito di strumenti IPA per allinearsi a livelli per fasi su sei categorie principali — disponibilità, prestazioni/scalabilità, operazioni/manutenibilità, migrabilità, sicurezza e ambiente di sistema — che coprono 238 metriche
• Parti dai livelli di baseline dei tre model systems e regola prima gli item importanti. Non è necessario compilare ogni item
• Il contenuto delle sei categorie principali sono per lo più domande di business. Chi detiene le risposte è il committente
• Più alto è il livello, più alto è il costo. Scegli il bilanciamento ragionando all’indietro dall’impatto sul business, e registra il risultato nel documento di definizione dei requisiti

Decidi in anticipo “a quale qualità deve continuare a funzionare” tanto quanto “cosa costruire.” Questo è il modo più economico per prevenire sia un sistema che funziona ma non è utilizzabile, sia le dispute che ne seguono.

Se fai fatica a organizzare i requisiti per un sistema business

Conciliare i requisiti non funzionali richiede di andare avanti e indietro tra lo stato reale del business (picchi, volume di dati, impatto del downtime) e la configurazione del sistema che deve soddisfarlo.

Komura Software LLC, quando consulenza per lo sviluppo su commissione o la modifica di applicazioni business Windows e sistemi web, lavora con i clienti per organizzare prestazioni, operazioni e comportamento in caso di guasto già in fase di definizione dei requisiti, seguendo il modo di pensare introdotto in questo articolo. Siamo disponibili a parlarne anche se siete nella fase “il nostro sistema attuale sta gradualmente rallentando” o “vorremmo rivedere le modalità operative mentre aggiorniamo.”

Articoli correlati

Articoli recenti con gli stessi tag per approfondire argomenti vicini.

Argomenti correlati

Queste pagine collocano l’argomento in un contesto più ampio di servizi e decisioni.

Servizi collegati all’argomento

L’articolo è direttamente collegato ai servizi seguenti.

Domande frequenti

Domande che ricorrono nelle consulenze sull’argomento dell’articolo.

Cosa sono i requisiti non funzionali?

Sono i requisiti su quanto bene e in quali condizioni un sistema opera, a differenza dei requisiti funzionali, che riguardano cosa fa il sistema. Esempi includono quando il sistema deve essere disponibile (disponibilità), quanti utenti contemporanei deve supportare e quanto velocemente deve rispondere (prestazioni e scalabilità), chi lo opera e lo mantiene e come (operabilità e manutenibilità), come vengono portati i dati dal sistema precedente (migrabilità), quali difese necessita (sicurezza), e in quale ambiente viene installato (ambiente di sistema). Se si dimentica di deciderli, si finisce spesso con un sistema che funziona ma non è davvero utilizzabile.

Posso usare il Non-Functional Requirements Grade gratuitamente? Dove lo trovo?

Sì, si può scaricare gratuitamente dal sito dell'IPA. È fornito come un set: grade table, elenco degli item, diagramma ad albero, worksheet e guida all'uso (in volumi di spiegazione, uso e applicazione). La versione attuale è 'Non-Functional Requirements Grade 2018,' pubblicata nell'aprile 2018. Ora si trova in una pagina archiviata del sito IPA, ma è ancora ampiamente usata in pratica come standard per verificare che nessun requisito non funzionale sia stato trascurato.

Devo decidere tutti i 238 item?

No. Anche la guida all'uso non presuppone di discutere ogni metrica uno per uno. L'approccio per fasi che propone è: prima scegli il model system più vicino al proprio per impostare una linea di base generale, poi regola gli item importanti nella grade table in base alle proprie circostanze reali, e approfondisci l'item list solo per le parti che necessitano. Per il sistema informativo di una PMI, concordare anche solo gli item importanti basta a evitare la maggior parte delle dispute derivanti dal dimenticare di decidere qualcosa.

Quando vanno decisi i requisiti non funzionali?

Nella fase di definizione dei requisiti. Gli obiettivi di disponibilità e prestazioni toccano i fondamenti della configurazione e del design del server, quindi modificarli una volta iniziato lo sviluppo ha un impatto maggiore su costi e tempi. Anche il Model Transaction and Contract per sistemi informativi dell'IPA presuppone che i requisiti non funzionali, non solo quelli funzionali, siano documentati come deliverable della fase di definizione dei requisiti. Se non si allineano le assunzioni non funzionali prima di confrontare i preventivi, non si riesce più a capire se una differenza di prezzo riflette una differenza di configurazione o solo una stima troppo ottimistica.

Profilo dell’autore

Pagina di presentazione dell’autore dell’articolo.

Go Komura

Rappresentante di KomuraSoft LLC

Specializzato nello sviluppo di software Windows, nella consulenza tecnica e nell’analisi dei malfunzionamenti, soprattutto nei progetti con sistemi esistenti e guasti difficili da riprodurre.